From asanso@adobe.com Thu Mar 1 04:42:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BA321F8691 for ; Thu, 1 Mar 2012 04:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9Y+zQ7bJfag for ; Thu, 1 Mar 2012 04:42:09 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id D6C2821F8686 for ; Thu, 1 Mar 2012 04:42:06 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKT09unQm6oIiwl/wsdXA5CmXYGqVVjOX3@postini.com; Thu, 01 Mar 2012 04:42:07 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q21Cg4N3023881; Thu, 1 Mar 2012 04:42:04 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q21Cg3Pl007932; Thu, 1 Mar 2012 04:42:04 -0800 (PST) Received: from eurhub01.eur.adobe.com (10.128.4.30) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 1 Mar 2012 04:42:03 -0800 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurhub01.eur.adobe.com ([10.128.4.30]) with mapi; Thu, 1 Mar 2012 12:42:01 +0000 From: Antonio Sanso To: Pete Clark Date: Thu, 1 Mar 2012 12:41:59 +0000 Thread-Topic: [OAUTH-WG] Securing APIs with OAuth 2.0 Thread-Index: Acz3qLJzG3trYP/ERxqdPfVJmkQZbA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 12:42:09 -0000 Hi Pete On Mar 1, 2012, at 3:44 AM, Pete Clark wrote: > 2) Point me to an implementation of this flow (in any language) that I co= uld use or port to PHP? I've found some libraries for php but can't really= tell, being new, if they offer the "client credentials" flow In Apache Amber (OAuth protocol implementation in Java) [0] you might find = something you can reuse. Regards Antonio [0] http://incubator.apache.org/amber/= From aaron@geoloqi.com Wed Feb 29 20:20:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBB921F856F for ; Wed, 29 Feb 2012 20:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QmM7CP4kRrL for ; Wed, 29 Feb 2012 20:20:44 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43A1921F8568 for ; Wed, 29 Feb 2012 20:20:42 -0800 (PST) Received: by ghbg16 with SMTP id g16so63014ghb.31 for ; Wed, 29 Feb 2012 20:20:42 -0800 (PST) Received-SPF: pass (google.com: domain of aaron@geoloqi.com designates 10.236.72.167 as permitted sender) client-ip=10.236.72.167; Authentication-Results: mr.google.com; spf=pass (google.com: domain of aaron@geoloqi.com designates 10.236.72.167 as permitted sender) smtp.mail=aaron@geoloqi.com Received: from mr.google.com ([10.236.72.167]) by 10.236.72.167 with SMTP id t27mr4537187yhd.79.1330575642751 (num_hops = 1); Wed, 29 Feb 2012 20:20:42 -0800 (PST) Received: by 10.236.72.167 with SMTP id t27mr3551108yhd.79.1330575642618; Wed, 29 Feb 2012 20:20:42 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id b4sm1078094anb.22.2012.02.29.20.20.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 20:20:41 -0800 (PST) Received: by yenm5 with SMTP id m5so62425yen.31 for ; Wed, 29 Feb 2012 20:20:39 -0800 (PST) Received-SPF: pass (google.com: domain of aaron@geoloqi.com designates 10.236.181.74 as permitted sender) client-ip=10.236.181.74; Received: from mr.google.com ([10.236.181.74]) by 10.236.181.74 with SMTP id k50mr4671444yhm.62.1330575639969 (num_hops = 1); Wed, 29 Feb 2012 20:20:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.181.74 with SMTP id k50mr3652108yhm.62.1330575639935; Wed, 29 Feb 2012 20:20:39 -0800 (PST) Received: by 10.146.88.11 with HTTP; Wed, 29 Feb 2012 20:20:39 -0800 (PST) In-Reply-To: References: Date: Thu, 1 Mar 2012 04:20:39 +0000 Message-ID: From: Aaron Parecki To: Pete Clark Content-Type: multipart/alternative; boundary=20cf305b127e5d79c404ba26c8a5 X-Gm-Message-State: ALoCoQkKQe0R97/zVev2yvfF/6sRl8+FOiUeys30NIZtGBiJTUUj8CUV0RbY/eDJKcVGDDVe2d/E X-Mailman-Approved-At: Thu, 01 Mar 2012 05:38:18 -0800 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 04:24:50 -0000 --20cf305b127e5d79c404ba26c8a5 Content-Type: text/plain; charset=UTF-8 I believe this one https://github.com/quizlet/oauth2-php is the most up-to-date PHP library, although you might check around for forks of it since I haven't checked up on it in a month or so. Aaron Parecki On Wednesday, February 29, 2012, Pete Clark wrote: > Hey all, I've joined the list because I'd like to use OAuth 2 to implement > security for a new set of REST APIs I'm developing for a client. I'm > coding with PHP, but my questions are more general. Right now, there will > be only one web site that uses the APIs, in a server-to-server fashion, and > currently we don't have a need for a third party application to gain access > to user data, such that a user would need to authorize that app. We do, > however, want to have that ability down the road. My question is, can I > still use OAuth 2 in some way to implement our first phase? From what I've > read, it seems like the "client credentials" flow is the one I want to use > for now. Can someone: > > 1) Confirm that that's what I should use for this first phase? > 2) Point me to an implementation of this flow (in any language) that I > could use or port to PHP? I've found some libraries for php but can't > really tell, being new, if they offer the "client credentials" flow > 3) Answer one more question.. Will using the client credentials flow now > allow me to move to one of the user-authorizes-external-app flows down the > road without having to reimplement or throw away the client credentials > flow code? > > I apologize for all the questions, but these would really help point me in > the right direction.. Thank you for reading! > > Sincerely, > Pete > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --20cf305b127e5d79c404ba26c8a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe this one https:= //github.com/quizlet/oauth2-php is the most up-to-date PHP library, alt= hough you might check around for forks of it since I haven't checked up= on it in a month or so.

Aaron Parecki


On Wednesday, February 29, 2= 012, Pete Clark wrote:
Hey all, I've= joined the list because I'd like to use OAuth 2 to implement security = for a new set of REST APIs I'm developing for a client. =C2=A0I'm c= oding with PHP, but my questions are more general. =C2=A0Right now, there w= ill be only one web site that uses the APIs, in a server-to-server fashion,= and currently we don't have a need for a third party application to ga= in access to user data, such that a user would need to authorize that app. = =C2=A0We do, however, want to have that ability down the road. =C2=A0My que= stion is, can I still use OAuth 2 in some way to implement our first phase?= =C2=A0From what I've read, it seems like the "client credentials&= quot; flow is the one I want to use for now. =C2=A0Can someone:

1) Confirm that that's what I should use for this first phase?
2) Point me to an implementation of this flow (in any language) that I coul= d use or port to PHP? =C2=A0I've found some libraries for php but can&#= 39;t really tell, being new, if they offer the "client credentials&quo= t; flow
3) Answer one more question.. Will using the client credentials flow now al= low me to move to one of the user-authorizes-external-app flows down the ro= ad without having to reimplement or throw away the client credentials flow = code?

I apologize for all the questions, but these would really help point me in = the right direction.. Thank you for reading!

Sincerely,
Pete



_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--20cf305b127e5d79c404ba26c8a5-- From aaron@parecki.com Thu Mar 1 07:19:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E42021E81BE for ; Thu, 1 Mar 2012 07:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Nvy++827qfI for ; Thu, 1 Mar 2012 07:19:20 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFA3221E81B5 for ; Thu, 1 Mar 2012 07:19:20 -0800 (PST) Received: by yenm5 with SMTP id m5so298588yen.31 for ; Thu, 01 Mar 2012 07:19:20 -0800 (PST) Received-SPF: pass (google.com: domain of aaron@parecki.com designates 10.236.143.40 as permitted sender) client-ip=10.236.143.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of aaron@parecki.com designates 10.236.143.40 as permitted sender) smtp.mail=aaron@parecki.com Received: from mr.google.com ([10.236.143.40]) by 10.236.143.40 with SMTP id k28mr7557398yhj.112.1330615160406 (num_hops = 1); Thu, 01 Mar 2012 07:19:20 -0800 (PST) Received: by 10.236.143.40 with SMTP id k28mr5898307yhj.112.1330615160332; Thu, 01 Mar 2012 07:19:20 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id l2sm3521398anq.12.2012.03.01.07.19.19 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 07:19:19 -0800 (PST) Received: by yhpp34 with SMTP id p34so299478yhp.31 for ; Thu, 01 Mar 2012 07:19:18 -0800 (PST) Received-SPF: pass (google.com: domain of aaron@parecki.com designates 10.236.72.230 as permitted sender) client-ip=10.236.72.230; Received: from mr.google.com ([10.236.72.230]) by 10.236.72.230 with SMTP id t66mr7589200yhd.45.1330615158877 (num_hops = 1); Thu, 01 Mar 2012 07:19:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.72.230 with SMTP id t66mr5926756yhd.45.1330615158837; Thu, 01 Mar 2012 07:19:18 -0800 (PST) Received: by 10.146.88.11 with HTTP; Thu, 1 Mar 2012 07:19:18 -0800 (PST) In-Reply-To: References: Date: Thu, 1 Mar 2012 15:19:18 +0000 Message-ID: From: Aaron Parecki To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=20cf300512c0e0101104ba2ffb12 X-Gm-Message-State: ALoCoQkEeL8LVb0TfoQ4DeStySLMFJF8ElFkQm889eU3N0aadVvocoVJjSF4SaTCzQ308BKaK8Jj Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:19:22 -0000 --20cf300512c0e0101104ba2ffb12 Content-Type: text/plain; charset=UTF-8 I believe this one https://github.com/quizlet/oauth2-php is the most up-to-date PHP library, although you might check around for forks of it since I haven't checked up on it in a month or so. Aaron Parecki On Thu, Mar 1, 2012 at 2:44 AM, Pete Clark wrote: > Hey all, I've joined the list because I'd like to use OAuth 2 to implement > security for a new set of REST APIs I'm developing for a client. I'm > coding with PHP, but my questions are more general. Right now, there will > be only one web site that uses the APIs, in a server-to-server fashion, and > currently we don't have a need for a third party application to gain access > to user data, such that a user would need to authorize that app. We do, > however, want to have that ability down the road. My question is, can I > still use OAuth 2 in some way to implement our first phase? From what I've > read, it seems like the "client credentials" flow is the one I want to use > for now. Can someone: > > 1) Confirm that that's what I should use for this first phase? > 2) Point me to an implementation of this flow (in any language) that I > could use or port to PHP? I've found some libraries for php but can't > really tell, being new, if they offer the "client credentials" flow > 3) Answer one more question.. Will using the client credentials flow now > allow me to move to one of the user-authorizes-external-app flows down the > road without having to reimplement or throw away the client credentials > flow code? > > I apologize for all the questions, but these would really help point me in > the right direction.. Thank you for reading! > > Sincerely, > Pete > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --20cf300512c0e0101104ba2ffb12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe this one=C2=A0https://github.com/quizlet/oauth2= -php=C2=A0is the most up-to-date PHP library, although you = might check around for forks of it since I haven't checked up on it in = a month or so.

Aaron Parecki
=


On Thu, Mar 1, 2012 at 2:44 AM, Pete Clark <pete@appmuscle.com> wrote:
Hey all, I've joined the list because I'd like to use OAuth 2 to im= plement security for a new set of REST APIs I'm developing for a client= . =C2=A0I'm coding with PHP, but my questions are more general. =C2=A0R= ight now, there will be only one web site that uses the APIs, in a server-t= o-server fashion, and currently we don't have a need for a third party = application to gain access to user data, such that a user would need to aut= horize that app. =C2=A0We do, however, want to have that ability down the r= oad. =C2=A0My question is, can I still use OAuth 2 in some way to implement= our first phase? =C2=A0From what I've read, it seems like the "cl= ient credentials" flow is the one I want to use for now. =C2=A0Can som= eone:

1) Confirm that that's what I should use for this first phase?
2) Point me to an implementation of this flow (in any language) that I coul= d use or port to PHP? =C2=A0I've found some libraries for php but can&#= 39;t really tell, being new, if they offer the "client credentials&quo= t; flow
3) Answer one more question.. Will using the client credentials flow now al= low me to move to one of the user-authorizes-external-app flows down the ro= ad without having to reimplement or throw away the client credentials flow = code?

I apologize for all the questions, but these would really help point me in = the right direction.. Thank you for reading!

Sincerely,
Pete



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

--20cf300512c0e0101104ba2ffb12-- From sberyozkin@gmail.com Thu Mar 1 08:39:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6213B21E8133 for ; Thu, 1 Mar 2012 08:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7FF+xOSM-gU for ; Thu, 1 Mar 2012 08:39:16 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83BFE21E80B8 for ; Thu, 1 Mar 2012 08:39:16 -0800 (PST) Received: by bkuw5 with SMTP id w5so810608bku.31 for ; Thu, 01 Mar 2012 08:39:15 -0800 (PST) Received-SPF: pass (google.com: domain of sberyozkin@gmail.com designates 10.204.152.7 as permitted sender) client-ip=10.204.152.7; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sberyozkin@gmail.com designates 10.204.152.7 as permitted sender) smtp.mail=sberyozkin@gmail.com; dkim=pass header.i=sberyozkin@gmail.com Received: from mr.google.com ([10.204.152.7]) by 10.204.152.7 with SMTP id e7mr3169135bkw.70.1330619955735 (num_hops = 1); Thu, 01 Mar 2012 08:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BLUP0AdEbn+KDQdBvo7VReKCKhXPvGMG3BhqJNp1fxU=; b=EgBYp84BHBhEOWmC496FkK/b+MEDAD8i3DYHiF3WtSCBWnLqVw7xEBIXdWasaXKFeT jFF469lz3ikqzSBePb67af2e1tZqmZW6DcfQ1DD9gMcT1GCdq+0U5H7BBk3r2ZXsnbpe JeZJvbSDIzrrNJG/7rUv62rHLjoUOanDzMukI= Received: by 10.204.152.7 with SMTP id e7mr2548796bkw.70.1330619955646; Thu, 01 Mar 2012 08:39:15 -0800 (PST) Received: from [10.36.226.4] ([217.173.99.61]) by mx.google.com with ESMTPS id t17sm4618806bke.6.2012.03.01.08.39.12 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 08:39:12 -0800 (PST) Message-ID: <4F4FA62F.7010404@gmail.com> Date: Thu, 01 Mar 2012 16:39:11 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <4F3BB6B8.1030501@mitre.org> In-Reply-To: <4F3BB6B8.1030501@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Few questions about client_credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 16:39:17 -0000 Hi, I have few questions about the client_credentials grant type. Section 4.4 [1] says: "...client is requesting access to the protected resources under its control, or those of another resource owner..." What I do not understand is the latter part of the above statement, how to establish a link between the client authentication (which is an actual grant in this case) and different resource owners given that the only thing we have is the client authentication. As far as I can see it is only possible to get a one to one link with the end user in this case. Can someone please clarify what is meant by "those of another resource owner" phrase ? The other question is about an optional scope parameter. It has to be ignored in case of the client requesting a token for accessing its own resources, right ? Thanks, Sergey [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4 From jricher@mitre.org Thu Mar 1 09:00:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C77121F8849 for ; Thu, 1 Mar 2012 09:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS04I+hcAEe9 for ; Thu, 1 Mar 2012 09:00:45 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BBC4F21E82A6 for ; Thu, 1 Mar 2012 09:00:44 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4AD1F21B1541; Thu, 1 Mar 2012 12:00:43 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id F0DDA21B19A1; Thu, 1 Mar 2012 12:00:42 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Thu, 1 Mar 2012 12:00:42 -0500 From: "Richer, Justin P." To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] Few questions about client_credentials Thread-Index: AQHM98nrRaaDgg3Qr0KgBitLVeQMQJZV/ekA Date: Thu, 1 Mar 2012 17:00:42 +0000 Message-ID: <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> References: <4F3BB6B8.1030501@mitre.org> <4F4FA62F.7010404@gmail.com> In-Reply-To: <4F4FA62F.7010404@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.37.217] Content-Type: text/plain; charset="us-ascii" Content-ID: <005F171DA65C334D825C10E51B0B46E0@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] Few questions about client_credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:00:48 -0000 If there's a fully trusted relationship between the client and the server, = then the client may in fact be accessing data on behalf of another resource= owner. It's a useful pattern when a three-legged flow like the Auth Code i= s not available. But it's kind of splitting hairs because the client has be= en granted a blanket access to the resource ahead of time, by virtue of its= registration. Showing up to get a token is a method of limiting exposure a= nd power of the client credentials, and making it easier to support both di= rect-client access and delegated-client access simultaneously with most of = the same tooling. To your second question, no -- scopes do not have to be ignored in this cas= e. In fact, a well-designed client and server can make use of scopes to let= the client request an access token that's only good for whatever the curre= nt transaction is, as opposed to something that's representative of all of = the client's capabilities. This is a method known as "downscoping" and it's= a very powerful pattern that OAuth enables. Of course, if you want, you ar= e fully allowed to leave the scope out entirely, then it's up to the Author= ization Server alone to figure out what the token is really good for. Hope this clears things up, -- Justin On Mar 1, 2012, at 11:39 AM, Sergey Beryozkin wrote: > Hi, >=20 > I have few questions about the client_credentials grant type. > Section 4.4 [1] says: "...client is requesting access to the protected re= sources under its control, or those of another resource owner..." >=20 > What I do not understand is the latter part of the above statement, how t= o establish a link between the client authentication (which is an actual gr= ant in this case) and different resource owners given that the only thing w= e have is the client authentication. As far as I can see it is only possibl= e to get a one to one link with the end user in this case. >=20 > Can someone please clarify what is meant by "those of another resource ow= ner" phrase ? >=20 > The other question is about an optional scope parameter. It has to be ign= ored in case of the client requesting a token for accessing its own resourc= es, right ? >=20 > Thanks, Sergey >=20 >=20 >=20 > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Thu Mar 1 11:23:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76F521E8093 for ; Thu, 1 Mar 2012 11:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwJHLsEXGr6S for ; Thu, 1 Mar 2012 11:23:51 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id CB7D521E829C for ; Thu, 1 Mar 2012 11:23:51 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q21JNmcd015782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 13:23:48 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q21JNlHp013207 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Mar 2012 13:23:47 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 1 Mar 2012 13:23:47 -0600 From: "Zeltsan, Zachary (Zachary)" To: "'Richer, Justin P.'" , "'Sergey Beryozkin'" Date: Thu, 1 Mar 2012 13:23:45 -0600 Thread-Topic: [OAUTH-WG] Few questions about client_credentials Thread-Index: AQHM98nrRaaDgg3Qr0KgBitLVeQMQJZV/ekA///TDwA= Message-ID: <5710F82C0E73B04FA559560098BF95B1250DBA5E89@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4F3BB6B8.1030501@mitre.org> <4F4FA62F.7010404@gmail.com> <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> In-Reply-To: <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "''" Subject: Re: [OAUTH-WG] Few questions about client_credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 19:23:52 -0000 In the case of the Client Credentials Grant, an authorization servers knows= what resources the client is authorized to access (this includes the resou= rces that are not owned by the client). The specification explains that aut= horization of access to the resources "has been previously arranged with th= e authorization server (the method of which is beyond the scope of this specification)". I have nothing to add to Justin's answer to the second question. Zachary Zachary=20 =20 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of R= icher, Justin P. Sent: Thursday, March 01, 2012 12:01 PM To: Sergey Beryozkin Cc: Subject: Re: [OAUTH-WG] Few questions about client_credentials If there's a fully trusted relationship between the client and the server, = then the client may in fact be accessing data on behalf of another resource= owner. It's a useful pattern when a three-legged flow like the Auth Code i= s not available. But it's kind of splitting hairs because the client has be= en granted a blanket access to the resource ahead of time, by virtue of its= registration. Showing up to get a token is a method of limiting exposure a= nd power of the client credentials, and making it easier to support both di= rect-client access and delegated-client access simultaneously with most of = the same tooling. To your second question, no -- scopes do not have to be ignored in this cas= e. In fact, a well-designed client and server can make use of scopes to let= the client request an access token that's only good for whatever the curre= nt transaction is, as opposed to something that's representative of all of = the client's capabilities. This is a method known as "downscoping" and it's= a very powerful pattern that OAuth enables. Of course, if you want, you ar= e fully allowed to leave the scope out entirely, then it's up to the Author= ization Server alone to figure out what the token is really good for. Hope this clears things up, -- Justin On Mar 1, 2012, at 11:39 AM, Sergey Beryozkin wrote: > Hi, >=20 > I have few questions about the client_credentials grant type. > Section 4.4 [1] says: "...client is requesting access to the protected re= sources under its control, or those of another resource owner..." >=20 > What I do not understand is the latter part of the above statement, how t= o establish a link between the client authentication (which is an actual gr= ant in this case) and different resource owners given that the only thing w= e have is the client authentication. As far as I can see it is only possibl= e to get a one to one link with the end user in this case. >=20 > Can someone please clarify what is meant by "those of another resource ow= ner" phrase ? >=20 > The other question is about an optional scope parameter. It has to be ign= ored in case of the client requesting a token for accessing its own resourc= es, right ? >=20 > Thanks, Sergey >=20 >=20 >=20 > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4 > _______________________________________________ > 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 sberyozkin@gmail.com Thu Mar 1 14:14:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F5321E835C for ; Thu, 1 Mar 2012 14:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uvkNOvOpRrv for ; Thu, 1 Mar 2012 14:14:10 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8ACF21E8352 for ; Thu, 1 Mar 2012 14:14:09 -0800 (PST) Received: by wicr5 with SMTP id r5so330239wic.31 for ; Thu, 01 Mar 2012 14:14:09 -0800 (PST) Received-SPF: pass (google.com: domain of sberyozkin@gmail.com designates 10.180.7.231 as permitted sender) client-ip=10.180.7.231; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sberyozkin@gmail.com designates 10.180.7.231 as permitted sender) smtp.mail=sberyozkin@gmail.com; dkim=pass header.i=sberyozkin@gmail.com Received: from mr.google.com ([10.180.7.231]) by 10.180.7.231 with SMTP id m7mr7857880wia.3.1330640049055 (num_hops = 1); Thu, 01 Mar 2012 14:14:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hPwUnhmXyX39piNmAjkAPMeOEJoqdrjPnZrqYhKfRxQ=; b=OilFospVPcUzYIb9UlXMOeEZm2hOAHiLdSSjpvz9GAtV97gVMhnt1gc+z5fRRAV+uX 6GPsrJ9t1TUTf5pDZ7mur9hsH3mme6NWkU3faQbCTjLVQGDFZS/W/E6pwfDOlRBxoCeM r1LMxgB7n/3dqNDvQ1RSBU7enFtkbWuB97kpFIiosoz6F4JruFzwRrOmwjEDzQqgbssI rzKK31zFXerD1JoXxK8bCcuHISdTdi86egMWYcWMgG53sf5+ySWyZvY7GGkV8iMzxn43 C5J3hcbsCrvgrEkAvhTkmAH7yteIuqbVmhMIDDD8/A49VnZXgpago4MjkXSOFEF8MWZg cHcw== Received: by 10.180.7.231 with SMTP id m7mr6348586wia.3.1330640048985; Thu, 01 Mar 2012 14:14:08 -0800 (PST) Received: from [192.168.2.3] ([89.100.23.77]) by mx.google.com with ESMTPS id df3sm44612074wib.1.2012.03.01.14.14.08 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 14:14:08 -0800 (PST) Message-ID: <4F4FF4AF.10509@gmail.com> Date: Thu, 01 Mar 2012 22:14:07 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Richer, Justin P." References: <4F3BB6B8.1030501@mitre.org> <4F4FA62F.7010404@gmail.com> <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> In-Reply-To: <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [OAUTH-WG] Few questions about client_credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:14:10 -0000 Thanks for the comments, On 01/03/12 17:00, Richer, Justin P. wrote: > If there's a fully trusted relationship between the client and the server, then the client may in fact be accessing data on behalf of another resource owner. It's a useful pattern when a three-legged flow like the Auth Code is not available. But it's kind of splitting hairs because the client has been granted a blanket access to the resource ahead of time, by virtue of its registration. Showing up to get a token is a method of limiting exposure and power of the client credentials, and making it easier to support both direct-client access and delegated-client access simultaneously with most of the same tooling. It does make sense. What I'm still missing is how an access token returned as part of the client_credentials flow can 'link' to more than a single resource owner. The authorization server can establish the fact that a specific end user pre-authorized the client, but how to manage the case where many end users have pre-authorized the same client ? The returned access token won't uniquely identify the end user which have pre-authorized this client... > > To your second question, no -- scopes do not have to be ignored in this case. In fact, a well-designed client and server can make use of scopes to let the client request an access token that's only good for whatever the current transaction is, as opposed to something that's representative of all of the client's capabilities. This is a method known as "downscoping" and it's a very powerful pattern that OAuth enables. Of course, if you want, you are fully allowed to leave the scope out entirely, then it's up to the Authorization Server alone to figure out what the token is really good for. > Sure - I can see why it is very useful for an authorization code flow. Still a bit unclear why the scope can be needed in case where a client is accessing its own resources, but do see it can be useful when the access to the end user's resources is also thought... many thanks Sergey > Hope this clears things up, > > -- Justin > > > > On Mar 1, 2012, at 11:39 AM, Sergey Beryozkin wrote: > >> Hi, >> >> I have few questions about the client_credentials grant type. >> Section 4.4 [1] says: "...client is requesting access to the protected resources under its control, or those of another resource owner..." >> >> What I do not understand is the latter part of the above statement, how to establish a link between the client authentication (which is an actual grant in this case) and different resource owners given that the only thing we have is the client authentication. As far as I can see it is only possible to get a one to one link with the end user in this case. >> >> Can someone please clarify what is meant by "those of another resource owner" phrase ? >> >> The other question is about an optional scope parameter. It has to be ignored in case of the client requesting a token for accessing its own resources, right ? >> >> Thanks, Sergey >> >> >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From sberyozkin@gmail.com Thu Mar 1 14:17:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA3F21E8373 for ; Thu, 1 Mar 2012 14:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il8NaHVWMFWZ for ; Thu, 1 Mar 2012 14:17:10 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9F721E8374 for ; Thu, 1 Mar 2012 14:17:09 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so702042wgb.13 for ; Thu, 01 Mar 2012 14:17:08 -0800 (PST) Received-SPF: pass (google.com: domain of sberyozkin@gmail.com designates 10.180.83.70 as permitted sender) client-ip=10.180.83.70; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sberyozkin@gmail.com designates 10.180.83.70 as permitted sender) smtp.mail=sberyozkin@gmail.com; dkim=pass header.i=sberyozkin@gmail.com Received: from mr.google.com ([10.180.83.70]) by 10.180.83.70 with SMTP id o6mr6418345wiy.19.1330640228773 (num_hops = 1); Thu, 01 Mar 2012 14:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=v3QV1ZRSZBBTkXYFhOIfZ2s5yqpDB2WZQ993OJP7jLg=; b=s0+wJ9NGQB1XGMzQUC+lHdj+E1bIO+byV5zioQCLAjBwGvTM+FfFazyfxRVqLTat1b w+jU16yW4E/bRLNSIF5jsdNS/UwjioekRRYVt60RBXSh3FVkhxDx/YRDJjdo/85t7EJy lVNcDq8dqP8aO0PLrnHVLjluNKwCPb5h+gBmHny8t7ZrQdDuMWx/8iXbGxWBsJ2tBoR5 CEEP4QuRG2/gHIof9orILV0mwDFPuVVwNyWMVYZVTl+VO8verNtgmFYN+0aGxYekxMdn nQdB+UGSYVbXWElvCIwpHdBGUe8FgwWJc9Hqtu9J4P2Bx40q3w/c3WbkGzI1BqzEbyo3 hvXg== Received: by 10.180.83.70 with SMTP id o6mr5185563wiy.19.1330640228714; Thu, 01 Mar 2012 14:17:08 -0800 (PST) Received: from [192.168.2.3] ([89.100.23.77]) by mx.google.com with ESMTPS id hb10sm16351564wib.10.2012.03.01.14.17.07 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 14:17:08 -0800 (PST) Message-ID: <4F4FF563.3070806@gmail.com> Date: Thu, 01 Mar 2012 22:17:07 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Zeltsan, Zachary (Zachary)" References: <4F3BB6B8.1030501@mitre.org> <4F4FA62F.7010404@gmail.com> <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> <5710F82C0E73B04FA559560098BF95B1250DBA5E89@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B1250DBA5E89@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "''" Subject: Re: [OAUTH-WG] Few questions about client_credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:17:11 -0000 Hi, On 01/03/12 19:23, Zeltsan, Zachary (Zachary) wrote: > In the case of the Client Credentials Grant, an authorization servers knows what resources the client is authorized to access (this includes the resources that are not owned by the client). The specification explains that authorization of access to the resources "has been previously arranged with the authorization server (the method of which is beyond > the scope of this specification)". > Are you saying that this can include the resources of possibly different end users ? Or only of a specific single end-user ? > I have nothing to add to Justin's answer to the second question. OK Thanks Sergey > > Zachary > > > Zachary > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P. > Sent: Thursday, March 01, 2012 12:01 PM > To: Sergey Beryozkin > Cc: > Subject: Re: [OAUTH-WG] Few questions about client_credentials > > If there's a fully trusted relationship between the client and the server, then the client may in fact be accessing data on behalf of another resource owner. It's a useful pattern when a three-legged flow like the Auth Code is not available. But it's kind of splitting hairs because the client has been granted a blanket access to the resource ahead of time, by virtue of its registration. Showing up to get a token is a method of limiting exposure and power of the client credentials, and making it easier to support both direct-client access and delegated-client access simultaneously with most of the same tooling. > > To your second question, no -- scopes do not have to be ignored in this case. In fact, a well-designed client and server can make use of scopes to let the client request an access token that's only good for whatever the current transaction is, as opposed to something that's representative of all of the client's capabilities. This is a method known as "downscoping" and it's a very powerful pattern that OAuth enables. Of course, if you want, you are fully allowed to leave the scope out entirely, then it's up to the Authorization Server alone to figure out what the token is really good for. > > Hope this clears things up, > > -- Justin > > > > On Mar 1, 2012, at 11:39 AM, Sergey Beryozkin wrote: > >> Hi, >> >> I have few questions about the client_credentials grant type. >> Section 4.4 [1] says: "...client is requesting access to the protected resources under its control, or those of another resource owner..." >> >> What I do not understand is the latter part of the above statement, how to establish a link between the client authentication (which is an actual grant in this case) and different resource owners given that the only thing we have is the client authentication. As far as I can see it is only possible to get a one to one link with the end user in this case. >> >> Can someone please clarify what is meant by "those of another resource owner" phrase ? >> >> The other question is about an optional scope parameter. It has to be ignored in case of the client requesting a token for accessing its own resources, right ? >> >> Thanks, Sergey >> >> >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4 >> _______________________________________________ >> 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 andredemarre@gmail.com Thu Mar 1 14:24:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D083921E836D for ; Thu, 1 Mar 2012 14:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.039 X-Spam-Level: X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x-34iaVxspR for ; Thu, 1 Mar 2012 14:24:44 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D78CA21E809C for ; Thu, 1 Mar 2012 14:24:36 -0800 (PST) Received: by dakl33 with SMTP id l33so1460110dak.31 for ; Thu, 01 Mar 2012 14:24:36 -0800 (PST) Received-SPF: pass (google.com: domain of andredemarre@gmail.com designates 10.68.132.198 as permitted sender) client-ip=10.68.132.198; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andredemarre@gmail.com designates 10.68.132.198 as permitted sender) smtp.mail=andredemarre@gmail.com; dkim=pass header.i=andredemarre@gmail.com Received: from mr.google.com ([10.68.132.198]) by 10.68.132.198 with SMTP id ow6mr6584840pbb.161.1330640676708 (num_hops = 1); Thu, 01 Mar 2012 14:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QdltoJ2crwxwllBgLr1hPl7y0INrLgsKcV3gKFQ257A=; b=nlm7Xm9OT3+HNa8SiGThYJs7ItOo88pI/YS9QRl7gsivinusMWW/5eFFrM2kUy7W9q KGEet+42zVfC5AUGSDJ+/i/ArZpqw7QAqL+TM/GSAeC01O3KkyiokTI5nsp4iJyJNcco uHxyIKFzGy/yeF43CBiDqAp6nRP2MTtoIsiFDRQGwDagqFtAsdGEu2R4zU2tEiX252jF SgpOBCemTOXeUijLgNFGa8UToLaIzJ2QTW6BjQInSEnP3di8o3J4q5xapMiJVs7wtOrF tg6WNAgOdkAZGXP8JMhgNXagYi4tuMGMD2tqq4dfb/FX47ehEBZbhSKg7A9snYXD98JM UikQ== MIME-Version: 1.0 Received: by 10.68.132.198 with SMTP id ow6mr5374539pbb.161.1330640676595; Thu, 01 Mar 2012 14:24:36 -0800 (PST) Received: by 10.68.233.230 with HTTP; Thu, 1 Mar 2012 14:24:36 -0800 (PST) In-Reply-To: References: Date: Thu, 1 Mar 2012 14:24:36 -0800 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: Pete Clark Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:24:46 -0000 Pete, Shane is right; the way you described your problem, the client credential grant type may be appropriate. That's especially true if the client will be accessing resources that don't necessarily belong to specific users. But if the client (web site) will be using the API (OAuth auth/resource server) to access user-specific resources, then the authorization code grant type is a better fit. It doesn't matter that the OAuth server trusts the client without needing user authorization. The authorization code flow offers a solution for user identification that is absent in the client credential flow. In other words, even though the OAuth server trusts the client and will comply with all API requests, how is the client x supposed to identify a user so it can request the right resource from the resource server? By using an authorization code grant, the client can acquire an access token that is bound to a specific user. This is makes the authorization code flow suitable for single sign-on implementations, whereas the client credential flow is not appropriate for user authentication. Don't worry about the fact that the client does not need to be authorized by the user. You can still use the authorization code flow, and the authorization server will not need to prompt the user for authorization because you will have pre-authorized the client for all users. As an added bonus, this sets you up perfectly for when you add new clients which are not pre-authorized and need user authorization. I hope that helps. Regards, Andre DeMarre On Wed, Feb 29, 2012 at 6:59 PM, Shane B Weeden wrote= : > 1. Yes, client credentials sounds right for what you described. Think of = it > as lightweight b2b authentication in that sense (but two steps - one to g= et > a token, and another to use it). > 2. Can't help you with source - but do have a product-based solution :) > 3. Absolutely it should for the resource server, but the answer may depen= d > have same dependency on the implementation you use. > > Regards, > Shane. > > > > From: =A0 Pete Clark > To: =A0 =A0 "oauth@ietf.org" > Date: =A0 29/02/2012 06:50 PM > Subject: =A0 =A0 =A0 =A0[OAUTH-WG] Securing APIs with OAuth 2.0 > Sent by: =A0 =A0 =A0 =A0oauth-bounces@ietf.org > > > > Hey all, I've joined the list because I'd like to use OAuth 2 to implemen= t > security for a new set of REST APIs I'm developing for a client. =A0I'm > coding with PHP, but my questions are more general. =A0Right now, there w= ill > be only one web site that uses the APIs, in a server-to-server fashion, a= nd > currently we don't have a need for a third party application to gain acce= ss > to user data, such that a user would need to authorize that app. =A0We do= , > however, want to have that ability down the road. =A0My question is, can = I > still use OAuth 2 in some way to implement our first phase? =A0From what = I've > read, it seems like the "client credentials" flow is the one I want to us= e > for now. =A0Can someone: > > 1) Confirm that that's what I should use for this first phase? > 2) Point me to an implementation of this flow (in any language) that I > could use or port to PHP? =A0I've found some libraries for php but can't > really tell, being new, if they offer the "client credentials" flow > 3) Answer one more question.. Will using the client credentials flow now > allow me to move to one of the user-authorizes-external-app flows down th= e > road without having to reimplement or throw away the client credentials > flow code? > > I apologize for all the questions, but these would really help point me i= n > the right direction.. Thank you for reading! > > Sincerely, > Pete > > > > _______________________________________________ > 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 zachary.zeltsan@alcatel-lucent.com Thu Mar 1 14:33:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D702021E83A6 for ; Thu, 1 Mar 2012 14:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.266 X-Spam-Level: X-Spam-Status: No, score=-9.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-bfOHs+MPw9 for ; Thu, 1 Mar 2012 14:33:38 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 25B6A21E809C for ; Thu, 1 Mar 2012 14:33:38 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q21MXaM9017692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 16:33:36 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q21MXYdq003600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Mar 2012 16:33:34 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 1 Mar 2012 16:33:34 -0600 From: "Zeltsan, Zachary (Zachary)" To: "'Sergey Beryozkin'" Date: Thu, 1 Mar 2012 16:33:31 -0600 Thread-Topic: [OAUTH-WG] Few questions about client_credentials Thread-Index: Acz3+QyElChRA5xES2e4W9mEGiKsmgAABwkQ Message-ID: <5710F82C0E73B04FA559560098BF95B1250DBA5F93@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4F3BB6B8.1030501@mitre.org> <4F4FA62F.7010404@gmail.com> <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> <5710F82C0E73B04FA559560098BF95B1250DBA5E89@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4F4FF563.3070806@gmail.com> In-Reply-To: <4F4FF563.3070806@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "''" Subject: Re: [OAUTH-WG] Few questions about client_credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:33:39 -0000 >Are you saying that this can include the resources of possibly different e= nd users ? Yes. The specification does not limit a number of the users whose resources= a client may access using the client credentials flow. Zachary=20 =20 -----Original Message----- From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]=20 Sent: Thursday, March 01, 2012 5:17 PM To: Zeltsan, Zachary (Zachary) Cc: 'Richer, Justin P.'; '' Subject: Re: [OAUTH-WG] Few questions about client_credentials Hi, On 01/03/12 19:23, Zeltsan, Zachary (Zachary) wrote: > In the case of the Client Credentials Grant, an authorization servers kno= ws what resources the client is authorized to access (this includes the res= ources that are not owned by the client). The specification explains that a= uthorization of access to the resources "has been previously arranged with = the authorization server (the method of which is beyond > the scope of this specification)". > Are you saying that this can include the resources of possibly different=20 end users ? Or only of a specific single end-user ? > I have nothing to add to Justin's answer to the second question. OK Thanks Sergey > > Zachary > > > Zachary > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Richer, Justin P. > Sent: Thursday, March 01, 2012 12:01 PM > To: Sergey Beryozkin > Cc: > Subject: Re: [OAUTH-WG] Few questions about client_credentials > > If there's a fully trusted relationship between the client and the server= , then the client may in fact be accessing data on behalf of another resour= ce owner. It's a useful pattern when a three-legged flow like the Auth Code= is not available. But it's kind of splitting hairs because the client has = been granted a blanket access to the resource ahead of time, by virtue of i= ts registration. Showing up to get a token is a method of limiting exposure= and power of the client credentials, and making it easier to support both = direct-client access and delegated-client access simultaneously with most o= f the same tooling. > > To your second question, no -- scopes do not have to be ignored in this c= ase. In fact, a well-designed client and server can make use of scopes to l= et the client request an access token that's only good for whatever the cur= rent transaction is, as opposed to something that's representative of all o= f the client's capabilities. This is a method known as "downscoping" and it= 's a very powerful pattern that OAuth enables. Of course, if you want, you = are fully allowed to leave the scope out entirely, then it's up to the Auth= orization Server alone to figure out what the token is really good for. > > Hope this clears things up, > > -- Justin > > > > On Mar 1, 2012, at 11:39 AM, Sergey Beryozkin wrote: > >> Hi, >> >> I have few questions about the client_credentials grant type. >> Section 4.4 [1] says: "...client is requesting access to the protected r= esources under its control, or those of another resource owner..." >> >> What I do not understand is the latter part of the above statement, how = to establish a link between the client authentication (which is an actual g= rant in this case) and different resource owners given that the only thing = we have is the client authentication. As far as I can see it is only possib= le to get a one to one link with the end user in this case. >> >> Can someone please clarify what is meant by "those of another resource o= wner" phrase ? >> >> The other question is about an optional scope parameter. It has to be ig= nored in case of the client requesting a token for accessing its own resour= ces, right ? >> >> Thanks, Sergey >> >> >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4 >> _______________________________________________ >> 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 paul.madsen@gmail.com Thu Mar 1 14:36:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C34321E83A6 for ; Thu, 1 Mar 2012 14:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f53PPiP8fEo0 for ; Thu, 1 Mar 2012 14:36:25 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2323B21E80BE for ; Thu, 1 Mar 2012 14:36:25 -0800 (PST) Received: by yenm5 with SMTP id m5so617557yen.31 for ; Thu, 01 Mar 2012 14:36:24 -0800 (PST) Received-SPF: pass (google.com: domain of paul.madsen@gmail.com designates 10.50.179.106 as permitted sender) client-ip=10.50.179.106; Authentication-Results: mr.google.com; spf=pass (google.com: domain of paul.madsen@gmail.com designates 10.50.179.106 as permitted sender) smtp.mail=paul.madsen@gmail.com; dkim=pass header.i=paul.madsen@gmail.com Received: from mr.google.com ([10.50.179.106]) by 10.50.179.106 with SMTP id df10mr6691654igc.6.1330641384630 (num_hops = 1); Thu, 01 Mar 2012 14:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=3IFKTfPHiXtyMWSkeG9u/q4YYv4MuM2YeA062jfWIIM=; b=BHbit99qL54xygyvHmLrwr6OUoEucBCXv6WGsD5A05SxJs9TuqapPXaoQqSmooO0S6 F9cn2pMFn/oSho/EHS4estwhSRmvvwH0rJ2UOAJ5Or0wb9i1lal08LOxzx+Q0A6g/Sbb cT3tHG1JEyCiuSof4dXoKeZWKm9a6n3LvvsrrnGjlGW3FTSwIE+i4tjABP41xPt0ymzK PH0alYvSTtYDgR6QXybYnDSnqYU1JIfX6Dl5u/4oMB8yEtoZCzEzEDZ/0Jx+vcshb1Ii fEB5bmx+dpPUtda4LJdVKsgLjjirqhC6FU9VPHD2t5SF3B3avYGXZtUZ8uRGdVHfMLIs 86QA== Received: by 10.50.179.106 with SMTP id df10mr5482612igc.6.1330641384576; Thu, 01 Mar 2012 14:36:24 -0800 (PST) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.162.33]) by mx.google.com with ESMTPS id cx9sm2982403igc.12.2012.03.01.14.36.20 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 14:36:22 -0800 (PST) Message-ID: <4F4FF9E3.3010007@gmail.com> Date: Thu, 01 Mar 2012 17:36:19 -0500 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Zeltsan, Zachary (Zachary)" References: <4F3BB6B8.1030501@mitre.org> <4F4FA62F.7010404@gmail.com> <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> <5710F82C0E73B04FA559560098BF95B1250DBA5E89@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4F4FF563.3070806@gmail.com> <5710F82C0E73B04FA559560098BF95B1250DBA5F93@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B1250DBA5F93@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------020706080108090500050600" Cc: "''" Subject: Re: [OAUTH-WG] Few questions about client_credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:36:26 -0000 This is a multi-part message in MIME format. --------------020706080108090500050600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit RO =/= end-user On 3/1/12 5:33 PM, Zeltsan, Zachary (Zachary) wrote: >> Are you saying that this can include the resources of possibly different end users ? > Yes. The specification does not limit a number of the users whose resources a client may access using the client credentials flow. > > Zachary > > > -----Original Message----- > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com] > Sent: Thursday, March 01, 2012 5:17 PM > To: Zeltsan, Zachary (Zachary) > Cc: 'Richer, Justin P.'; '' > Subject: Re: [OAUTH-WG] Few questions about client_credentials > > Hi, > On 01/03/12 19:23, Zeltsan, Zachary (Zachary) wrote: >> In the case of the Client Credentials Grant, an authorization servers knows what resources the client is authorized to access (this includes the resources that are not owned by the client). The specification explains that authorization of access to the resources "has been previously arranged with the authorization server (the method of which is beyond >> the scope of this specification)". >> > Are you saying that this can include the resources of possibly different > end users ? Or only of a specific single end-user ? > > >> I have nothing to add to Justin's answer to the second question. > OK > > Thanks > > Sergey > >> Zachary >> >> >> Zachary >> >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P. >> Sent: Thursday, March 01, 2012 12:01 PM >> To: Sergey Beryozkin >> Cc: >> Subject: Re: [OAUTH-WG] Few questions about client_credentials >> >> If there's a fully trusted relationship between the client and the server, then the client may in fact be accessing data on behalf of another resource owner. It's a useful pattern when a three-legged flow like the Auth Code is not available. But it's kind of splitting hairs because the client has been granted a blanket access to the resource ahead of time, by virtue of its registration. Showing up to get a token is a method of limiting exposure and power of the client credentials, and making it easier to support both direct-client access and delegated-client access simultaneously with most of the same tooling. >> >> To your second question, no -- scopes do not have to be ignored in this case. In fact, a well-designed client and server can make use of scopes to let the client request an access token that's only good for whatever the current transaction is, as opposed to something that's representative of all of the client's capabilities. This is a method known as "downscoping" and it's a very powerful pattern that OAuth enables. Of course, if you want, you are fully allowed to leave the scope out entirely, then it's up to the Authorization Server alone to figure out what the token is really good for. >> >> Hope this clears things up, >> >> -- Justin >> >> >> >> On Mar 1, 2012, at 11:39 AM, Sergey Beryozkin wrote: >> >>> Hi, >>> >>> I have few questions about the client_credentials grant type. >>> Section 4.4 [1] says: "...client is requesting access to the protected resources under its control, or those of another resource owner..." >>> >>> What I do not understand is the latter part of the above statement, how to establish a link between the client authentication (which is an actual grant in this case) and different resource owners given that the only thing we have is the client authentication. As far as I can see it is only possible to get a one to one link with the end user in this case. >>> >>> Can someone please clarify what is meant by "those of another resource owner" phrase ? >>> >>> The other question is about an optional scope parameter. It has to be ignored in case of the client requesting a token for accessing its own resources, right ? >>> >>> Thanks, Sergey >>> >>> >>> >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4 >>> _______________________________________________ >>> 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 --------------020706080108090500050600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit RO =/= end-user

On 3/1/12 5:33 PM, Zeltsan, Zachary (Zachary) wrote: 
Are you saying that this can include the resources of possibly different end users ?

Yes. The specification does not limit a number of the users whose resources a client may access using the client credentials flow.

Zachary 
 

-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com] 
Sent: Thursday, March 01, 2012 5:17 PM
To: Zeltsan, Zachary (Zachary)
Cc: 'Richer, Justin P.'; '<oauth@ietf.org>'
Subject: Re: [OAUTH-WG] Few questions about client_credentials

Hi,
On 01/03/12 19:23, Zeltsan, Zachary (Zachary) wrote:

In the case of the Client Credentials Grant, an authorization servers knows what resources the client is authorized to access (this includes the resources that are not owned by the client). The specification explains that authorization of access to the resources "has been previously arranged with the authorization server (the method of which is beyond
  the scope of this specification)".


Are you saying that this can include the resources of possibly different 
end users ? Or only of a specific single end-user ?



I have nothing to add to Justin's answer to the second question.

OK

Thanks

Sergey


Zachary


Zachary


-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P.
Sent: Thursday, March 01, 2012 12:01 PM
To: Sergey Beryozkin
Cc:<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Few questions about client_credentials

If there's a fully trusted relationship between the client and the server, then the client may in fact be accessing data on behalf of another resource owner. It's a useful pattern when a three-legged flow like the Auth Code is not available. But it's kind of splitting hairs because the client has been granted a blanket access to the resource ahead of time, by virtue of its registration. Showing up to get a token is a method of limiting exposure and power of the client credentials, and making it easier to support both direct-client access and delegated-client access simultaneously with most of the same tooling.

To your second question, no -- scopes do not have to be ignored in this case. In fact, a well-designed client and server can make use of scopes to let the client request an access token that's only good for whatever the current transaction is, as opposed to something that's representative of all of the client's capabilities. This is a method known as "downscoping" and it's a very powerful pattern that OAuth enables. Of course, if you want, you are fully allowed to leave the scope out entirely, then it's up to the Authorization Server alone to figure out what the token is really good for.

Hope this clears things up,

  -- Justin



On Mar 1, 2012, at 11:39 AM, Sergey Beryozkin wrote:


Hi,

I have few questions about the client_credentials grant type.
Section 4.4 [1] says: "...client is requesting access to the protected resources under its control, or those of another resource owner..."

What I do not understand is the latter part of the above statement, how to establish a link between the client authentication (which is an actual grant in this case) and different resource owners given that the only thing we have is the client authentication. As far as I can see it is only possible to get a one to one link with the end user in this case.

Can someone please clarify what is meant by "those of another resource owner" phrase ?

The other question is about an optional scope parameter. It has to be ignored in case of the client requesting a token for accessing its own resources, right ?

Thanks, Sergey



[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4
_______________________________________________
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
--------------020706080108090500050600-- From andredemarre@gmail.com Thu Mar 1 15:42:55 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0496421E83E2 for ; Thu, 1 Mar 2012 15:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.068 X-Spam-Level: X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S76vrJt4+Vl6 for ; Thu, 1 Mar 2012 15:42:54 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE2F21E83E1 for ; Thu, 1 Mar 2012 15:42:54 -0800 (PST) Received: by dakl33 with SMTP id l33so1523513dak.31 for ; Thu, 01 Mar 2012 15:42:54 -0800 (PST) Received-SPF: pass (google.com: domain of andredemarre@gmail.com designates 10.68.219.130 as permitted sender) client-ip=10.68.219.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andredemarre@gmail.com designates 10.68.219.130 as permitted sender) smtp.mail=andredemarre@gmail.com; dkim=pass header.i=andredemarre@gmail.com Received: from mr.google.com ([10.68.219.130]) by 10.68.219.130 with SMTP id po2mr8735224pbc.140.1330645374074 (num_hops = 1); Thu, 01 Mar 2012 15:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UYU2GzjB6JFvpXDBGEwbDmtKq7U0ebwHyMwIdaRVIqs=; b=GKhPUsAq8kL9aGyqcJhuAaPZ9GsJIbKxvXY+HSOYkV++kKEDJxitoMjHyPomsIbPLD bA+LfOQRUrAvqZaAsjq3i3nEbcRWk65eQr27pdqhcuup7cla6LfnGvXF4o5iWBmeCS0V ZPTXAleG3EImHexPwZZRMgtUU9ovQXZPyhPvVcHwGmSWqiTkMoHX3D5qzrc8Y/Re+lSb GIOo1p1GL9bf5Ozj/smUB6xAAlsnpCdE68GE5aHe1n8ef9047E+8AIR5C9clx6VV8IAm a7nKq2AForaI3M2A/k0JhbUGJ3eg8ls5imD2JgZj7AenPJ1KAbfUvr10VvxjHHv5rLVu e1HQ== MIME-Version: 1.0 Received: by 10.68.219.130 with SMTP id po2mr7205549pbc.140.1330645373971; Thu, 01 Mar 2012 15:42:53 -0800 (PST) Received: by 10.68.233.230 with HTTP; Thu, 1 Mar 2012 15:42:53 -0800 (PST) In-Reply-To: <5710F82C0E73B04FA559560098BF95B1250DBA5F93@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4F3BB6B8.1030501@mitre.org> <4F4FA62F.7010404@gmail.com> <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> <5710F82C0E73B04FA559560098BF95B1250DBA5E89@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4F4FF563.3070806@gmail.com> <5710F82C0E73B04FA559560098BF95B1250DBA5F93@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Date: Thu, 1 Mar 2012 15:42:53 -0800 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: Sergey Beryozkin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Few questions about client_credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 23:42:55 -0000 Sergey, This thread is a lot like another thread titled "Securing APIs with OAuth 2.0". You might read the comments there for further clarification: http://www.ietf.org/mail-archive/web/oauth/current/msg08472.html Regards, Andre DeMarre On Thu, Mar 1, 2012 at 2:33 PM, Zeltsan, Zachary (Zachary) wrote: >>Are you saying that this can include the resources of possibly different = end users ? > Yes. The specification does not limit a number of the users whose resourc= es a client may access using the client credentials flow. > > Zachary > > > -----Original Message----- > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com] > Sent: Thursday, March 01, 2012 5:17 PM > To: Zeltsan, Zachary (Zachary) > Cc: 'Richer, Justin P.'; '' > Subject: Re: [OAUTH-WG] Few questions about client_credentials > > Hi, > On 01/03/12 19:23, Zeltsan, Zachary (Zachary) wrote: >> In the case of the Client Credentials Grant, an authorization servers kn= ows what resources the client is authorized to access (this includes the re= sources that are not owned by the client). The specification explains that = authorization of access to the resources "has been previously arranged with= the authorization server (the method of which is beyond >> =A0 the scope of this specification)". >> > Are you saying that this can include the resources of possibly different > end users ? Or only of a specific single end-user ? > > >> I have nothing to add to Justin's answer to the second question. > > OK > > Thanks > > Sergey > >> >> Zachary >> >> >> Zachary >> >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Richer, Justin P. >> Sent: Thursday, March 01, 2012 12:01 PM >> To: Sergey Beryozkin >> Cc: >> Subject: Re: [OAUTH-WG] Few questions about client_credentials >> >> If there's a fully trusted relationship between the client and the serve= r, then the client may in fact be accessing data on behalf of another resou= rce owner. It's a useful pattern when a three-legged flow like the Auth Cod= e is not available. But it's kind of splitting hairs because the client has= been granted a blanket access to the resource ahead of time, by virtue of = its registration. Showing up to get a token is a method of limiting exposur= e and power of the client credentials, and making it easier to support both= direct-client access and delegated-client access simultaneously with most = of the same tooling. >> >> To your second question, no -- scopes do not have to be ignored in this = case. In fact, a well-designed client and server can make use of scopes to = let the client request an access token that's only good for whatever the cu= rrent transaction is, as opposed to something that's representative of all = of the client's capabilities. This is a method known as "downscoping" and i= t's a very powerful pattern that OAuth enables. Of course, if you want, you= are fully allowed to leave the scope out entirely, then it's up to the Aut= horization Server alone to figure out what the token is really good for. >> >> Hope this clears things up, >> >> =A0 -- Justin >> >> >> >> On Mar 1, 2012, at 11:39 AM, Sergey Beryozkin wrote: >> >>> Hi, >>> >>> I have few questions about the client_credentials grant type. >>> Section 4.4 [1] says: "...client is requesting access to the protected = resources under its control, or those of another resource owner..." >>> >>> What I do not understand is the latter part of the above statement, how= to establish a link between the client authentication (which is an actual = grant in this case) and different resource owners given that the only thing= we have is the client authentication. As far as I can see it is only possi= ble to get a one to one link with the end user in this case. >>> >>> Can someone please clarify what is meant by "those of another resource = owner" phrase ? >>> >>> The other question is about an optional scope parameter. It has to be i= gnored in case of the client requesting a token for accessing its own resou= rces, right ? >>> >>> Thanks, Sergey >>> >>> >>> >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4 >>> _______________________________________________ >>> 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 From sberyozkin@gmail.com Fri Mar 2 01:44:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB8121F8C1A for ; Fri, 2 Mar 2012 01:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDTKRvLF+MkP for ; Fri, 2 Mar 2012 01:44:21 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3577221F8C08 for ; Fri, 2 Mar 2012 01:44:21 -0800 (PST) Received: by bkuw5 with SMTP id w5so1518464bku.31 for ; Fri, 02 Mar 2012 01:44:20 -0800 (PST) Received-SPF: pass (google.com: domain of sberyozkin@gmail.com designates 10.205.122.77 as permitted sender) client-ip=10.205.122.77; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sberyozkin@gmail.com designates 10.205.122.77 as permitted sender) smtp.mail=sberyozkin@gmail.com; dkim=pass header.i=sberyozkin@gmail.com Received: from mr.google.com ([10.205.122.77]) by 10.205.122.77 with SMTP id gf13mr4878595bkc.15.1330681460309 (num_hops = 1); Fri, 02 Mar 2012 01:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lB2xksQEetdMQSzcNbi2bE8wIO3X3hYFxCc7db61SnE=; b=ZeyWNoWJpYfAz7mzdPAgL9amtQJBC3AwFk2VmABMg9NkscbPb2+QKaaLv08tpeKQJ4 xwv7TQ6iVfq865pLh80aSWxx6OuFIyDxFlZ27F0jUJR17/GQzpeSOmMKxyDzBoB9RMpr zqWlEiGBg1eSDSX8kBD15ts0WqEJYEQeNjJPd4PQlNzlS9u/VAhmOWMtB785TIMij8tz eIVQocrrJO3ypW2L8jJZ3/qjbMfm1QA6DR9f+Pyby7QRKZ8jze2SStwpGSo4M69mS08e 2TJVxKpAeWq+CfwcY4TReayN1JwifHIOgWl5ig0BP+9BSw2kLt1Eshs1H+b9McADmW59 ucBA== Received: by 10.205.122.77 with SMTP id gf13mr3904635bkc.15.1330681460209; Fri, 02 Mar 2012 01:44:20 -0800 (PST) Received: from [192.168.2.3] ([89.100.23.77]) by mx.google.com with ESMTPS id d5sm8352852bkb.3.2012.03.02.01.44.16 (version=SSLv3 cipher=OTHER); Fri, 02 Mar 2012 01:44:17 -0800 (PST) Message-ID: <4F50966F.5070607@gmail.com> Date: Fri, 02 Mar 2012 09:44:15 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Andr=E9_DeMarre?= References: <4F3BB6B8.1030501@mitre.org> <4F4FA62F.7010404@gmail.com> <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> <5710F82C0E73B04FA559560098BF95B1250DBA5E89@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4F4FF563.3070806@gmail.com> <5710F82C0E73B04FA559560098BF95B1250DBA5F93@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Few questions about client_credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 09:44:22 -0000 Hi Andre On 01/03/12 23:42, André DeMarre wrote: > Sergey, > > This thread is a lot like another thread titled "Securing APIs with > OAuth 2.0". You might read the comments there for further > clarification: > http://www.ietf.org/mail-archive/web/oauth/current/msg08472.html Indeed, I was just reading it :-) thanks to all for the comments Sergey > > Regards, > Andre DeMarre > > On Thu, Mar 1, 2012 at 2:33 PM, Zeltsan, Zachary (Zachary) > wrote: >>> Are you saying that this can include the resources of possibly different end users ? >> Yes. The specification does not limit a number of the users whose resources a client may access using the client credentials flow. >> >> Zachary >> >> >> -----Original Message----- >> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com] >> Sent: Thursday, March 01, 2012 5:17 PM >> To: Zeltsan, Zachary (Zachary) >> Cc: 'Richer, Justin P.'; '' >> Subject: Re: [OAUTH-WG] Few questions about client_credentials >> >> Hi, >> On 01/03/12 19:23, Zeltsan, Zachary (Zachary) wrote: >>> In the case of the Client Credentials Grant, an authorization servers knows what resources the client is authorized to access (this includes the resources that are not owned by the client). The specification explains that authorization of access to the resources "has been previously arranged with the authorization server (the method of which is beyond >>> the scope of this specification)". >>> >> Are you saying that this can include the resources of possibly different >> end users ? Or only of a specific single end-user ? >> >> >>> I have nothing to add to Justin's answer to the second question. >> >> OK >> >> Thanks >> >> Sergey >> >>> >>> Zachary >>> >>> >>> Zachary >>> >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P. >>> Sent: Thursday, March 01, 2012 12:01 PM >>> To: Sergey Beryozkin >>> Cc: >>> Subject: Re: [OAUTH-WG] Few questions about client_credentials >>> >>> If there's a fully trusted relationship between the client and the server, then the client may in fact be accessing data on behalf of another resource owner. It's a useful pattern when a three-legged flow like the Auth Code is not available. But it's kind of splitting hairs because the client has been granted a blanket access to the resource ahead of time, by virtue of its registration. Showing up to get a token is a method of limiting exposure and power of the client credentials, and making it easier to support both direct-client access and delegated-client access simultaneously with most of the same tooling. >>> >>> To your second question, no -- scopes do not have to be ignored in this case. In fact, a well-designed client and server can make use of scopes to let the client request an access token that's only good for whatever the current transaction is, as opposed to something that's representative of all of the client's capabilities. This is a method known as "downscoping" and it's a very powerful pattern that OAuth enables. Of course, if you want, you are fully allowed to leave the scope out entirely, then it's up to the Authorization Server alone to figure out what the token is really good for. >>> >>> Hope this clears things up, >>> >>> -- Justin >>> >>> >>> >>> On Mar 1, 2012, at 11:39 AM, Sergey Beryozkin wrote: >>> >>>> Hi, >>>> >>>> I have few questions about the client_credentials grant type. >>>> Section 4.4 [1] says: "...client is requesting access to the protected resources under its control, or those of another resource owner..." >>>> >>>> What I do not understand is the latter part of the above statement, how to establish a link between the client authentication (which is an actual grant in this case) and different resource owners given that the only thing we have is the client authentication. As far as I can see it is only possible to get a one to one link with the end user in this case. >>>> >>>> Can someone please clarify what is meant by "those of another resource owner" phrase ? >>>> >>>> The other question is about an optional scope parameter. It has to be ignored in case of the client requesting a token for accessing its own resources, right ? >>>> >>>> Thanks, Sergey >>>> >>>> >>>> >>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4 >>>> _______________________________________________ >>>> 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 From jricher@mitre.org Fri Mar 2 07:27:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8F21F84B6 for ; Fri, 2 Mar 2012 07:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuGOwkzuOkeE for ; Fri, 2 Mar 2012 07:27:32 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1AA21F85B5 for ; Fri, 2 Mar 2012 07:27:32 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5D1E321B0E06; Fri, 2 Mar 2012 10:27:31 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 23C2021B0EB6; Fri, 2 Mar 2012 10:27:31 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 2 Mar 2012 10:27:30 -0500 Message-ID: <4F50E68B.9050200@mitre.org> Date: Fri, 2 Mar 2012 10:26:03 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Andr=E9_DeMarre?= References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:27:33 -0000 +1 to André's suggestion below. If you find that you're going to have to add a field to your API to indicate the userID along with a two-legged transaction, you're likely doing things wrong. We've used the auto-approve method below for several applications, and users don't seem to know or care what's really happening. They show up to the client app, they see a little waiting screen the first time through, and then it works. That is to say, it's nearly as transparent as a two-legged scenario but with better security and flexibility aspects. The two-legged approach works best when: 1) There's no user involved in the transaction at all (traditional system-to-system data exchange) 2) You *can't* have the user present on any part of the transaction (it must work fully back-channel) If you can count on the user being there at any point, even to just kick things off, then the code flow is likely more like what you're after. -- Justin On 03/01/2012 05:24 PM, André DeMarre wrote: > Pete, > > Shane is right; the way you described your problem, the client > credential grant type may be appropriate. That's especially true if > the client will be accessing resources that don't necessarily belong > to specific users. But if the client (web site) will be using the API > (OAuth auth/resource server) to access user-specific resources, then > the authorization code grant type is a better fit. It doesn't matter > that the OAuth server trusts the client without needing user > authorization. > > The authorization code flow offers a solution for user identification > that is absent in the client credential flow. In other words, even > though the OAuth server trusts the client and will comply with all API > requests, how is the client x supposed to identify a user so it can > request the right resource from the resource server? > > By using an authorization code grant, the client can acquire an access > token that is bound to a specific user. This is makes the > authorization code flow suitable for single sign-on implementations, > whereas the client credential flow is not appropriate for user > authentication. > > Don't worry about the fact that the client does not need to be > authorized by the user. You can still use the authorization code flow, > and the authorization server will not need to prompt the user for > authorization because you will have pre-authorized the client for all > users. > > As an added bonus, this sets you up perfectly for when you add new > clients which are not pre-authorized and need user authorization. > > I hope that helps. > > Regards, > Andre DeMarre > > On Wed, Feb 29, 2012 at 6:59 PM, Shane B Weeden wrote: >> 1. Yes, client credentials sounds right for what you described. Think of it >> as lightweight b2b authentication in that sense (but two steps - one to get >> a token, and another to use it). >> 2. Can't help you with source - but do have a product-based solution :) >> 3. Absolutely it should for the resource server, but the answer may depend >> have same dependency on the implementation you use. >> >> Regards, >> Shane. >> >> >> >> From: Pete Clark >> To: "oauth@ietf.org" >> Date: 29/02/2012 06:50 PM >> Subject: [OAUTH-WG] Securing APIs with OAuth 2.0 >> Sent by: oauth-bounces@ietf.org >> >> >> >> Hey all, I've joined the list because I'd like to use OAuth 2 to implement >> security for a new set of REST APIs I'm developing for a client. I'm >> coding with PHP, but my questions are more general. Right now, there will >> be only one web site that uses the APIs, in a server-to-server fashion, and >> currently we don't have a need for a third party application to gain access >> to user data, such that a user would need to authorize that app. We do, >> however, want to have that ability down the road. My question is, can I >> still use OAuth 2 in some way to implement our first phase? From what I've >> read, it seems like the "client credentials" flow is the one I want to use >> for now. Can someone: >> >> 1) Confirm that that's what I should use for this first phase? >> 2) Point me to an implementation of this flow (in any language) that I >> could use or port to PHP? I've found some libraries for php but can't >> really tell, being new, if they offer the "client credentials" flow >> 3) Answer one more question.. Will using the client credentials flow now >> allow me to move to one of the user-authorizes-external-app flows down the >> road without having to reimplement or throw away the client credentials >> flow code? >> >> I apologize for all the questions, but these would really help point me in >> the right direction.. Thank you for reading! >> >> Sincerely, >> Pete >> >> >> >> _______________________________________________ >> 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 From sberyozkin@gmail.com Mon Mar 5 04:04:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F01621F857F for ; Mon, 5 Mar 2012 04:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIkp2MxudN12 for ; Mon, 5 Mar 2012 04:04:46 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 306AA21F8578 for ; Mon, 5 Mar 2012 04:04:45 -0800 (PST) Received: by bkuw5 with SMTP id w5so3577201bku.31 for ; Mon, 05 Mar 2012 04:04:45 -0800 (PST) Received-SPF: pass (google.com: domain of sberyozkin@gmail.com designates 10.205.122.77 as permitted sender) client-ip=10.205.122.77; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sberyozkin@gmail.com designates 10.205.122.77 as permitted sender) smtp.mail=sberyozkin@gmail.com; dkim=pass header.i=sberyozkin@gmail.com Received: from mr.google.com ([10.205.122.77]) by 10.205.122.77 with SMTP id gf13mr10697861bkc.15.1330949085040 (num_hops = 1); Mon, 05 Mar 2012 04:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bHv3Jmqryd+w7IZ1z4wjrRK4Xxz4HEwcyn3e+sDQTNY=; b=P8k+5CbqHukbRhR+CPSI+ZHH10UWalxlpFBr8h3EPtDNQo+FtajcI0E4dZyjObnXo1 cHy/831NHwZ625zcJXSCenDiTH6mGI9jtU3i5XLeWsanp87zAQdcH+2mcKMwHbu3C9A3 0C2pSvemVl0cAW3dotfUdAFV2Z1BWpWQce5EyqA2TkOUVl3BDucudqgJtor9JWOJsByI IMbgoW739AZQjiCkvJY6k+1MV28MXD3x8xh3QiUIKkOEwgyoQknc8chblC2Ig0rTwdsh tVFL9XmkrZARPaAF86rYlVkmnXrafk0RS+vY2MoechcakMaOA7w4tbzkUCFcXmKV4cUi R1+A== Received: by 10.205.122.77 with SMTP id gf13mr8488262bkc.15.1330949084907; Mon, 05 Mar 2012 04:04:44 -0800 (PST) Received: from [10.36.226.4] ([217.173.99.61]) by mx.google.com with ESMTPS id jc4sm24906589bkc.7.2012.03.05.04.04.44 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 04:04:44 -0800 (PST) Message-ID: <4F54ABDB.1050702@gmail.com> Date: Mon, 05 Mar 2012 12:04:43 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 12:04:47 -0000 Hi, On 01/03/12 22:24, André DeMarre wrote: > Pete, > > Shane is right; the way you described your problem, the client > credential grant type may be appropriate. That's especially true if > the client will be accessing resources that don't necessarily belong > to specific users. But if the client (web site) will be using the API > (OAuth auth/resource server) to access user-specific resources, then > the authorization code grant type is a better fit. It doesn't matter > that the OAuth server trusts the client without needing user > authorization. > > The authorization code flow offers a solution for user identification > that is absent in the client credential flow. In other words, even > though the OAuth server trusts the client and will comply with all API > requests, how is the client x supposed to identify a user so it can > request the right resource from the resource server? > > By using an authorization code grant, the client can acquire an access > token that is bound to a specific user. This is makes the > authorization code flow suitable for single sign-on implementations, > whereas the client credential flow is not appropriate for user > authentication. > > Don't worry about the fact that the client does not need to be > authorized by the user. You can still use the authorization code flow, > and the authorization server will not need to prompt the user for > authorization because you will have pre-authorized the client for all > users. > Can the authorization server return a (pre-authorized) token immediately in this case, despite the fact the client is specifying "response_type=code" ? If the authorization code, to be exchanged later for this token, has to be returned, how reasonable is it to expect that the authorization code will be bound to the pre-authorized access token (example, the access token's key/id will be returned as the authorization code) ? I suspect it may not be a good idea given the spec is saying the authorization code should be short-lived, thus the codes and actual tokens will have different life-cycles, however the fact the end user has pre-authorized the client adds some uncertainty to it... thanks, Sergey > As an added bonus, this sets you up perfectly for when you add new > clients which are not pre-authorized and need user authorization. > > I hope that helps. > > Regards, > Andre DeMarre > > On Wed, Feb 29, 2012 at 6:59 PM, Shane B Weeden wrote: >> 1. Yes, client credentials sounds right for what you described. Think of it >> as lightweight b2b authentication in that sense (but two steps - one to get >> a token, and another to use it). >> 2. Can't help you with source - but do have a product-based solution :) >> 3. Absolutely it should for the resource server, but the answer may depend >> have same dependency on the implementation you use. >> >> Regards, >> Shane. >> >> >> >> From: Pete Clark >> To: "oauth@ietf.org" >> Date: 29/02/2012 06:50 PM >> Subject: [OAUTH-WG] Securing APIs with OAuth 2.0 >> Sent by: oauth-bounces@ietf.org >> >> >> >> Hey all, I've joined the list because I'd like to use OAuth 2 to implement >> security for a new set of REST APIs I'm developing for a client. I'm >> coding with PHP, but my questions are more general. Right now, there will >> be only one web site that uses the APIs, in a server-to-server fashion, and >> currently we don't have a need for a third party application to gain access >> to user data, such that a user would need to authorize that app. We do, >> however, want to have that ability down the road. My question is, can I >> still use OAuth 2 in some way to implement our first phase? From what I've >> read, it seems like the "client credentials" flow is the one I want to use >> for now. Can someone: >> >> 1) Confirm that that's what I should use for this first phase? >> 2) Point me to an implementation of this flow (in any language) that I >> could use or port to PHP? I've found some libraries for php but can't >> really tell, being new, if they offer the "client credentials" flow >> 3) Answer one more question.. Will using the client credentials flow now >> allow me to move to one of the user-authorizes-external-app flows down the >> road without having to reimplement or throw away the client credentials >> flow code? >> >> I apologize for all the questions, but these would really help point me in >> the right direction.. Thank you for reading! >> >> Sincerely, >> Pete >> >> >> >> _______________________________________________ >> 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 From jricher@mitre.org Mon Mar 5 06:15:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F034921F8621 for ; Mon, 5 Mar 2012 06:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUYfn9ovkxJy for ; Mon, 5 Mar 2012 06:15:53 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D916221F85E6 for ; Mon, 5 Mar 2012 06:15:52 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 79E3F21B14FA; Mon, 5 Mar 2012 09:15:49 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5077521B083A; Mon, 5 Mar 2012 09:15:49 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 5 Mar 2012 09:15:48 -0500 Message-ID: <4F54CA3A.8020502@mitre.org> Date: Mon, 5 Mar 2012 09:14:18 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sergey Beryozkin References: <4F54ABDB.1050702@gmail.com> In-Reply-To: <4F54ABDB.1050702@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:15:54 -0000 >> >> Shane is right; the way you described your problem, the client >> credential grant type may be appropriate. That's especially true if >> the client will be accessing resources that don't necessarily belong >> to specific users. But if the client (web site) will be using the API >> (OAuth auth/resource server) to access user-specific resources, then >> the authorization code grant type is a better fit. It doesn't matter >> that the OAuth server trusts the client without needing user >> authorization. >> >> The authorization code flow offers a solution for user identification >> that is absent in the client credential flow. In other words, even >> though the OAuth server trusts the client and will comply with all API >> requests, how is the client x supposed to identify a user so it can >> request the right resource from the resource server? >> >> By using an authorization code grant, the client can acquire an access >> token that is bound to a specific user. This is makes the >> authorization code flow suitable for single sign-on implementations, >> whereas the client credential flow is not appropriate for user >> authentication. >> >> Don't worry about the fact that the client does not need to be >> authorized by the user. You can still use the authorization code flow, >> and the authorization server will not need to prompt the user for >> authorization because you will have pre-authorized the client for all >> users. >> > > Can the authorization server return a (pre-authorized) token > immediately in this case, despite the fact the client is specifying > "response_type=code" ? No -- the server MUST return an authorization code, even if there is no interaction beyond the user logging in (which may be SSO and therefore "invisible" to users). This code is bound to the user session and the client ID, and it needs to be presented in the back channel with the client's ID and secret, away from the user session. These two steps are what close the client-server-user triangle in a secure way so that no party knows more than they really need to. The Client Credentials flow and the Implicit flow collapse this triangle into a line in two different ways, both for different use cases and both have their tradeoffs. So if you want to get an access token from the authz endpoint directly, you use the implicit flow. It puts all of the weight onto the user agent, which sounds like the opposite of what you actually want to do here. > If the authorization code, to be exchanged later for this token, has > to be returned, how reasonable is it to expect that the authorization > code will be bound to the pre-authorized access token (example, the > access token's key/id will be returned as the authorization code) ? > > I suspect it may not be a good idea given the spec is saying the > authorization code should be short-lived, thus the codes and actual > tokens will have different life-cycles, however the fact the end user > has pre-authorized the client adds some uncertainty to it... Again, no -- the code shouldn't have anything in it that ties it to the access token directly. If it did, then anybody intercepting just the code on the wire could guess the access token, which would make the auth code a pointless abstraction. The best way to deploy the authz code is to have a short, random, opaque blob that is one-time use and expires after a set amount of time, probably fairly short (on the order of minutes in most cases). Think of it as a one-time-password that is generated for the resource owner to give to the client on their behalf. Since it's a credential known to both the user agent and the client, you really, really don't want it to be copied from any other part of the flow. -- Justin > thanks, Sergey > >> As an added bonus, this sets you up perfectly for when you add new >> clients which are not pre-authorized and need user authorization. >> >> I hope that helps. >> >> Regards, >> Andre DeMarre >> >> On Wed, Feb 29, 2012 at 6:59 PM, Shane B Weeden >> wrote: >>> 1. Yes, client credentials sounds right for what you described. >>> Think of it >>> as lightweight b2b authentication in that sense (but two steps - one >>> to get >>> a token, and another to use it). >>> 2. Can't help you with source - but do have a product-based solution :) >>> 3. Absolutely it should for the resource server, but the answer may >>> depend >>> have same dependency on the implementation you use. >>> >>> Regards, >>> Shane. >>> >>> >>> >>> From: Pete Clark >>> To: "oauth@ietf.org" >>> Date: 29/02/2012 06:50 PM >>> Subject: [OAUTH-WG] Securing APIs with OAuth 2.0 >>> Sent by: oauth-bounces@ietf.org >>> >>> >>> >>> Hey all, I've joined the list because I'd like to use OAuth 2 to >>> implement >>> security for a new set of REST APIs I'm developing for a client. I'm >>> coding with PHP, but my questions are more general. Right now, >>> there will >>> be only one web site that uses the APIs, in a server-to-server >>> fashion, and >>> currently we don't have a need for a third party application to gain >>> access >>> to user data, such that a user would need to authorize that app. We >>> do, >>> however, want to have that ability down the road. My question is, >>> can I >>> still use OAuth 2 in some way to implement our first phase? From >>> what I've >>> read, it seems like the "client credentials" flow is the one I want >>> to use >>> for now. Can someone: >>> >>> 1) Confirm that that's what I should use for this first phase? >>> 2) Point me to an implementation of this flow (in any language) that I >>> could use or port to PHP? I've found some libraries for php but can't >>> really tell, being new, if they offer the "client credentials" flow >>> 3) Answer one more question.. Will using the client credentials flow >>> now >>> allow me to move to one of the user-authorizes-external-app flows >>> down the >>> road without having to reimplement or throw away the client credentials >>> flow code? >>> >>> I apologize for all the questions, but these would really help point >>> me in >>> the right direction.. Thank you for reading! >>> >>> Sincerely, >>> Pete >>> >>> >>> >>> _______________________________________________ >>> 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 From sberyozkin@gmail.com Mon Mar 5 09:35:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D66A21F87BD for ; Mon, 5 Mar 2012 09:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGoUExb5s1Ms for ; Mon, 5 Mar 2012 09:35:21 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C77BD21F8770 for ; Mon, 5 Mar 2012 09:35:20 -0800 (PST) Received: by bkuw5 with SMTP id w5so4001533bku.31 for ; Mon, 05 Mar 2012 09:35:19 -0800 (PST) Received-SPF: pass (google.com: domain of sberyozkin@gmail.com designates 10.204.173.11 as permitted sender) client-ip=10.204.173.11; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sberyozkin@gmail.com designates 10.204.173.11 as permitted sender) smtp.mail=sberyozkin@gmail.com; dkim=pass header.i=sberyozkin@gmail.com Received: from mr.google.com ([10.204.173.11]) by 10.204.173.11 with SMTP id n11mr11087134bkz.120.1330968919976 (num_hops = 1); Mon, 05 Mar 2012 09:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qG1I6gKJuVm6SLC7hjfhcz3BB9UbpAIpoRmme/JkdqQ=; b=GEaeo2Bpzrm/J2qL7MG7XxSgiVHcp7WiMFihGzK64CnsDpzfJ7RYvr0LfoO61tf6nN V8cBStsqznssyqvMMU9di9YCD12cYhNwcGhp+/dG6pxHLo9rO4B2w41AJgS0QXyUiCJO eo6YQ6O0AcvG4mEifH0htqXhIWW1zH3aaE9YplAeFc70vnJ81ybRMcTnZ2cumx1pLqsP 4WGA/7VYfkUEVYeo5geEtKbvSjEQmr+e7KXwmIEN1LuRMAI54beaXH3OeSIWPup9l1aR QL6VU8SKTmjQIdpXCyoZ30/FvzXzVnYC0VLl1IW6UySZLRSGfXKbdGz7V/OCRBiKXtnM 697A== MIME-Version: 1.0 Received: by 10.204.173.11 with SMTP id n11mr8767057bkz.120.1330968919784; Mon, 05 Mar 2012 09:35:19 -0800 (PST) Received: by 10.204.175.141 with HTTP; Mon, 5 Mar 2012 09:35:19 -0800 (PST) In-Reply-To: <4F54CA3A.8020502@mitre.org> References: <4F54ABDB.1050702@gmail.com> <4F54CA3A.8020502@mitre.org> Date: Mon, 5 Mar 2012 17:35:19 +0000 Message-ID: From: Sergey Beryozkin To: Justin Richer Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:35:22 -0000 On 05/03/12 14:14, Justin Richer wrote: > >>> >>> Shane is right; the way you described your problem, the client >>> credential grant type may be appropriate. That's especially true if >>> the client will be accessing resources that don't necessarily belong >>> to specific users. But if the client (web site) will be using the API >>> (OAuth auth/resource server) to access user-specific resources, then >>> the authorization code grant type is a better fit. It doesn't matter >>> that the OAuth server trusts the client without needing user >>> authorization. >>> >>> The authorization code flow offers a solution for user identification >>> that is absent in the client credential flow. In other words, even >>> though the OAuth server trusts the client and will comply with all API >>> requests, how is the client x supposed to identify a user so it can >>> request the right resource from the resource server? >>> >>> By using an authorization code grant, the client can acquire an access >>> token that is bound to a specific user. This is makes the >>> authorization code flow suitable for single sign-on implementations, >>> whereas the client credential flow is not appropriate for user >>> authentication. >>> >>> Don't worry about the fact that the client does not need to be >>> authorized by the user. You can still use the authorization code flow, >>> and the authorization server will not need to prompt the user for >>> authorization because you will have pre-authorized the client for all >>> users. >>> >> >> Can the authorization server return a (pre-authorized) token >> immediately in this case, despite the fact the client is specifying >> "response_type=code" ? > No -- the server MUST return an authorization code, even if there is no > interaction beyond the user logging in (which may be SSO and therefore > "invisible" to users). This code is bound to the user session and the > client ID, and it needs to be presented in the back channel with the > client's ID and secret, away from the user session. These two steps are > what close the client-server-user triangle in a secure way so that no > party knows more than they really need to. The Client Credentials flow > and the Implicit flow collapse this triangle into a line in two > different ways, both for different use cases and both have their > tradeoffs. So if you want to get an access token from the authz endpoint > directly, you use the implicit flow. It puts all of the weight onto the > user agent, which sounds like the opposite of what you actually want to > do here. OK > >> If the authorization code, to be exchanged later for this token, has >> to be returned, how reasonable is it to expect that the authorization >> code will be bound to the pre-authorized access token (example, the >> access token's key/id will be returned as the authorization code) ? >> >> I suspect it may not be a good idea given the spec is saying the >> authorization code should be short-lived, thus the codes and actual >> tokens will have different life-cycles, however the fact the end user >> has pre-authorized the client adds some uncertainty to it... > > Again, no -- the code shouldn't have anything in it that ties it to the > access token directly. If it did, then anybody intercepting just the > code on the wire could guess the access token, which would make the auth > code a pointless abstraction. The best way to deploy the authz code is > to have a short, random, opaque blob that is one-time use and expires > after a set amount of time, probably fairly short (on the order of > minutes in most cases). Think of it as a one-time-password that is > generated for the resource owner to give to the client on their behalf. > Since it's a credential known to both the user agent and the client, you > really, really don't want it to be copied from any other part of the flow. > OK. Thanks for the explanations so far. It's very helpful. I'm prototyping the framework support for OAuth 2.0 and at this stage I'm trying to figure out what exactly the runtime itself can do and what has to be delegated to the custom code and thus how to design the api the runtime and the custom code will use to communicate with each other. Let me ask one more question, sorry if it's a silly one :-) So suppose a given client has been pre-authorized by the end user. Next, the client can get the pre-authorized token via the authorization code flow or the implicit code flow (ignoring the client_credentials one for the moment). Does it make sense to restrict which flow a given pre-authorized token can 'work' with ? Example, enforce that the pre-authorized token can only be issued to the clients initiating an authorization code flow but not to those trying an implicit one, or vice versa ? The reason I ask is that I'm thinking that the entity representing an access token should have a property indicating which grant type was used for this token being created in the first place. So if such a token were to represent the user pre-authorizing the client and then eventually given to a client via the authorization code or implicit code flow, then this token would actually need to be cloned each time for a specific grant type property be set, and this does not look optimal... Cheers, Sergey > -- Justin > > >> thanks, Sergey >> >>> As an added bonus, this sets you up perfectly for when you add new >>> clients which are not pre-authorized and need user authorization. >>> >>> I hope that helps. >>> >>> Regards, >>> Andre DeMarre >>> >>> On Wed, Feb 29, 2012 at 6:59 PM, Shane B Weeden >>> wrote: >>>> 1. Yes, client credentials sounds right for what you described. >>>> Think of it >>>> as lightweight b2b authentication in that sense (but two steps - one >>>> to get >>>> a token, and another to use it). >>>> 2. Can't help you with source - but do have a product-based solution :) >>>> 3. Absolutely it should for the resource server, but the answer may >>>> depend >>>> have same dependency on the implementation you use. >>>> >>>> Regards, >>>> Shane. >>>> >>>> >>>> >>>> From: Pete Clark >>>> To: "oauth@ietf.org" >>>> Date: 29/02/2012 06:50 PM >>>> Subject: [OAUTH-WG] Securing APIs with OAuth 2.0 >>>> Sent by: oauth-bounces@ietf.org >>>> >>>> >>>> >>>> Hey all, I've joined the list because I'd like to use OAuth 2 to >>>> implement >>>> security for a new set of REST APIs I'm developing for a client. I'm >>>> coding with PHP, but my questions are more general. Right now, there >>>> will >>>> be only one web site that uses the APIs, in a server-to-server >>>> fashion, and >>>> currently we don't have a need for a third party application to gain >>>> access >>>> to user data, such that a user would need to authorize that app. We do, >>>> however, want to have that ability down the road. My question is, can I >>>> still use OAuth 2 in some way to implement our first phase? From >>>> what I've >>>> read, it seems like the "client credentials" flow is the one I want >>>> to use >>>> for now. Can someone: >>>> >>>> 1) Confirm that that's what I should use for this first phase? >>>> 2) Point me to an implementation of this flow (in any language) that I >>>> could use or port to PHP? I've found some libraries for php but can't >>>> really tell, being new, if they offer the "client credentials" flow >>>> 3) Answer one more question.. Will using the client credentials flow >>>> now >>>> allow me to move to one of the user-authorizes-external-app flows >>>> down the >>>> road without having to reimplement or throw away the client credentials >>>> flow code? >>>> >>>> I apologize for all the questions, but these would really help point >>>> me in >>>> the right direction.. Thank you for reading! >>>> >>>> Sincerely, >>>> Pete >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > From bcampbell@pingidentity.com Mon Mar 5 14:40:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E99021F8685 for ; Mon, 5 Mar 2012 14:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFAK6Yk7vb9Y for ; Mon, 5 Mar 2012 14:40:52 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 591E021F864F for ; Mon, 5 Mar 2012 14:40:52 -0800 (PST) Received: from mail-vw0-f43.google.com ([209.85.212.43]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKT1VA8+uSflOg3toxz5EV0T+4M/2y+mCq@postini.com; Mon, 05 Mar 2012 14:40:52 PST Received: by mail-vw0-f43.google.com with SMTP id fq11so4705944vbb.2 for ; Mon, 05 Mar 2012 14:40:51 -0800 (PST) Received-SPF: pass (google.com: domain of bcampbell@pingidentity.com designates 10.52.68.241 as permitted sender) client-ip=10.52.68.241; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bcampbell@pingidentity.com designates 10.52.68.241 as permitted sender) smtp.mail=bcampbell@pingidentity.com Received: from mr.google.com ([10.52.68.241]) by 10.52.68.241 with SMTP id z17mr37980906vdt.97.1330987251549 (num_hops = 1); Mon, 05 Mar 2012 14:40:51 -0800 (PST) Received: by 10.52.68.241 with SMTP id z17mr32527226vdt.97.1330987251213; Mon, 05 Mar 2012 14:40:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.171.172 with HTTP; Mon, 5 Mar 2012 14:40:21 -0800 (PST) From: Brian Campbell Date: Mon, 5 Mar 2012 14:40:21 -0800 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl7364sipDrx+2dDv59FDTR6T+R2JyrxXGhbgAA3qCHTT2DFUlYb0kqYh66cr7OFD4tN6Mg Subject: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:40:53 -0000 On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer Tokens"* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client and RS. Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token. Do I read this correctly? If so, I feel like some additional clarifying text in the Bearer Tokens draft might help avoid what is (based on my small sample) a common point of misunderstanding. Also, does the use of b64token implicitly limit the allowed characters that an AS can use to construct a bearer access token? Thanks, Brian * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 ** http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 From James.H.Manger@team.telstra.com Mon Mar 5 15:33:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70DB21E804D for ; Mon, 5 Mar 2012 15:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45bOoGWeQbg4 for ; Mon, 5 Mar 2012 15:33:07 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id EC50B21E8053 for ; Mon, 5 Mar 2012 15:32:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,537,1325422800"; d="scan'208";a="64121055" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 06 Mar 2012 10:32:56 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6640"; a="1203406" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcani.tcif.telstra.com.au with ESMTP; 06 Mar 2012 10:32:56 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Tue, 6 Mar 2012 10:32:56 +1100 From: "Manger, James H" To: Brian Campbell , oauth Date: Tue, 6 Mar 2012 10:32:54 +1100 Thread-Topic: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Thread-Index: Acz7IQo6kb65NrOMT92lUwLW39DciQAA3VLA Message-ID: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:33:07 -0000 Brian, > On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer > Tokens"* I've encountered several people (including myself) who have > made the assumption that the name b64token implies that some kind of > base64 encoding/decoding on the access token is taking place between > the client and RS. >=20 > Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**, > however, I see that b64token is just an ABNF syntax definition > allowing for characters typically used in base64, base64url, etc.. So > the b64token doesn't define any encoding or decoding but rather just > defines what characters can be used in the part of the Authorization > header that will contain the access token. > > Do I read this correctly? Yes. > If so, I feel like some additional clarifying text in the Bearer > Tokens draft might help avoid what is (based on my small sample) a > common point of misunderstanding. Changing the example bearer token should be a simple way to avoid some conf= usion by showing that it does not have to be base64 encoding. How about cha= nging: Authorization: Bearer vF9dft4qmT to Authorization: Bearer vF9.dft4.qmT The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't qui= te manage to be precise about how OAuth and Bearer connect. It could explic= itly state that the string value of the "access_token" member of an access = token response is the bearer token. The "access_token" string value (after = unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used= with the Bearer HTTP scheme. Such text could be put in =A75.1.1 where the = "Bearer" OAuth access token type is defined. > Also, does the use of b64token implicitly limit the allowed characters > that an AS can use to construct a bearer access token? Yes. > * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 > ** http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 -- James Manger From Michael.Jones@microsoft.com Mon Mar 5 17:34:02 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152F321E8027 for ; Mon, 5 Mar 2012 17:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swwfrXug5pvI for ; Mon, 5 Mar 2012 17:34:01 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 38B6521E8012 for ; Mon, 5 Mar 2012 17:34:01 -0800 (PST) Received: from mail86-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 6 Mar 2012 01:34:00 +0000 Received: from mail86-ch1 (localhost [127.0.0.1]) by mail86-ch1-R.bigfish.com (Postfix) with ESMTP id 4F9291C0209; Tue, 6 Mar 2012 01:34:00 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I542M1432Nzz1202hzz1033IL8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail86-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail86-ch1 (localhost.localdomain [127.0.0.1]) by mail86-ch1 (MessageSwitch) id 1330997637500548_25134; Tue, 6 Mar 2012 01:33:57 +0000 (UTC) Received: from CH1EHSMHS011.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail86-ch1.bigfish.com (Postfix) with ESMTP id 6AB872000DC; Tue, 6 Mar 2012 01:33:57 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 6 Mar 2012 01:33:57 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.124]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0283.004; Tue, 6 Mar 2012 01:32:59 +0000 From: Mike Jones To: "Manger, James H" , Brian Campbell , oauth Thread-Topic: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Thread-Index: AQHM+yhkmuwCbxmTb0mjcYxusRGRDJZcezXg Date: Tue, 6 Mar 2012 01:32:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943663DB078@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 01:34:02 -0000 I'm fine with changing the example to make it clearer that b64token allows = a wider range of characters than just those legal for base64 and base64url = encodings of data values. I'll add it to my to-do list for any additional edits for the Bearer spec. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Monday, March 05, 2012 3:33 PM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oa= uth-v2-bearer Brian, > On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer > Tokens"* I've encountered several people (including myself) who have=20 > made the assumption that the name b64token implies that some kind of > base64 encoding/decoding on the access token is taking place between=20 > the client and RS. >=20 > Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,=20 > however, I see that b64token is just an ABNF syntax definition=20 > allowing for characters typically used in base64, base64url, etc.. So=20 > the b64token doesn't define any encoding or decoding but rather just=20 > defines what characters can be used in the part of the Authorization=20 > header that will contain the access token. > > Do I read this correctly? Yes. > If so, I feel like some additional clarifying text in the Bearer=20 > Tokens draft might help avoid what is (based on my small sample) a=20 > common point of misunderstanding. Changing the example bearer token should be a simple way to avoid some conf= usion by showing that it does not have to be base64 encoding. How about cha= nging: Authorization: Bearer vF9dft4qmT to Authorization: Bearer vF9.dft4.qmT The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't qui= te manage to be precise about how OAuth and Bearer connect. It could explic= itly state that the string value of the "access_token" member of an access = token response is the bearer token. The "access_token" string value (after = unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used= with the Bearer HTTP scheme. Such text could be put in =A75.1.1 where the = "Bearer" OAuth access token type is defined. > Also, does the use of b64token implicitly limit the allowed characters=20 > that an AS can use to construct a bearer access token? Yes. > * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 > **=20 > http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Tue Mar 6 08:23:57 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F86721F8964 for ; Tue, 6 Mar 2012 08:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.768 X-Spam-Level: X-Spam-Status: No, score=-5.768 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7mp5RPZci-x for ; Tue, 6 Mar 2012 08:23:56 -0800 (PST) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 9A02A21F8970 for ; Tue, 6 Mar 2012 08:23:55 -0800 (PST) Received: from mail-vx0-f175.google.com ([209.85.220.175]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKT1Y6Gh+ewUKZf96+zKVqPUFwgndQr8vF@postini.com; Tue, 06 Mar 2012 08:23:55 PST Received: by mail-vx0-f175.google.com with SMTP id fl13so5052235vcb.20 for ; Tue, 06 Mar 2012 08:23:54 -0800 (PST) Received-SPF: pass (google.com: domain of bcampbell@pingidentity.com designates 10.220.59.133 as permitted sender) client-ip=10.220.59.133; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bcampbell@pingidentity.com designates 10.220.59.133 as permitted sender) smtp.mail=bcampbell@pingidentity.com Received: from mr.google.com ([10.220.59.133]) by 10.220.59.133 with SMTP id l5mr3423655vch.6.1331051034871 (num_hops = 1); Tue, 06 Mar 2012 08:23:54 -0800 (PST) Received: by 10.220.59.133 with SMTP id l5mr2943000vch.6.1331051034235; Tue, 06 Mar 2012 08:23:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.171.172 with HTTP; Tue, 6 Mar 2012 08:23:23 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663DB078@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943663DB078@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Brian Campbell Date: Tue, 6 Mar 2012 08:23:24 -0800 Message-ID: To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlie52G6OQkbvhpeEP5VJNKzQ0teWwY9ADJPJRv3pHSGW6CZy7nL+7Hr7884RlJwuhtWYhR Cc: oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:23:57 -0000 Thanks Mike, I think changing the example would be helpful. However I think that including some text along the lines of what James suggested would also be very valuable. I agree that the connection between OAuth and Bearer could and should be made more explicit. And that the implications of the b64token syntax, particularly on what AS can use to construct ATs, could/should be made more clear. I can propose some specific text (building on James') if others in the WG a= gree? On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones wr= ote: > I'm fine with changing the example to make it clearer that b64token allow= s a wider range of characters than just those legal for base64 and base64ur= l encodings of data values. > > I'll add it to my to-do list for any additional edits for the Bearer spec= . > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Manger, James H > Sent: Monday, March 05, 2012 3:33 PM > To: Brian Campbell; oauth > Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-= oauth-v2-bearer > > Brian, > >> On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer >> Tokens"* I've encountered several people (including myself) who have >> made the assumption that the name b64token implies that some kind of >> base64 encoding/decoding on the access token is taking place between >> the client and RS. >> >> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**, >> however, I see that b64token is just an ABNF syntax definition >> allowing for characters typically used in base64, base64url, etc.. So >> the b64token doesn't define any encoding or decoding but rather just >> defines what characters can be used in the part of the Authorization >> header that will contain the access token. >> >> Do I read this correctly? > > Yes. > >> If so, I feel like some additional clarifying text in the Bearer >> Tokens draft might help avoid what is (based on my small sample) a >> common point of misunderstanding. > > Changing the example bearer token should be a simple way to avoid some co= nfusion by showing that it does not have to be base64 encoding. How about c= hanging: > =A0Authorization: Bearer vF9dft4qmT > to > =A0Authorization: Bearer vF9.dft4.qmT > > The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't q= uite manage to be precise about how OAuth and Bearer connect. It could expl= icitly state that the string value of the "access_token" member of an acces= s token response is the bearer token. The "access_token" string value (afte= r unescaping any JSON-escapes) MUST match the b64token ABNF so it can be us= ed with the Bearer HTTP scheme. Such text could be put in =A75.1.1 where th= e "Bearer" OAuth access token type is defined. > > >> Also, does the use of b64token implicitly limit the allowed characters >> that an AS can use to construct a bearer access token? > > Yes. > > >> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 >> ** >> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 > > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From paul.madsen@gmail.com Tue Mar 6 08:30:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD8821F87A0 for ; Tue, 6 Mar 2012 08:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZxkiiwXiigp for ; Tue, 6 Mar 2012 08:30:05 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4021F86C4 for ; Tue, 6 Mar 2012 08:29:54 -0800 (PST) Received: by ghbg16 with SMTP id g16so2612572ghb.31 for ; Tue, 06 Mar 2012 08:29:53 -0800 (PST) Received-SPF: pass (google.com: domain of paul.madsen@gmail.com designates 10.236.173.202 as permitted sender) client-ip=10.236.173.202; Authentication-Results: mr.google.com; spf=pass (google.com: domain of paul.madsen@gmail.com designates 10.236.173.202 as permitted sender) smtp.mail=paul.madsen@gmail.com; dkim=pass header.i=paul.madsen@gmail.com Received: from mr.google.com ([10.236.173.202]) by 10.236.173.202 with SMTP id v50mr35008266yhl.102.1331051393686 (num_hops = 1); Tue, 06 Mar 2012 08:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=PVzxAZy0tpeIBOr2f+sP9K+wGq3eAT73h9T/UF8h0C8=; b=cL9+PoBLar0520iv7oslX1S/9fTILxgm0SgoWi1k17bluvJCjgJXE/k5URd88OPQbG kshb1bGnpq61ycJG6//Chc/u27OjaVJiR7/N/q4p8MAcw4ods93zDqut3wcigRx/AJIs qdTuFgipjdCAbdhoGZX7+5Uk3793QRjI9wsfNYMzsJlhHxNyEcQpU1v+XmifEWqN6zYM 5B00sgrZr3OtvNT/A1/qt9QMF7rCn8/bdOknOZlqf0pYvF01zMIWGB4obTuc6wMaozdr zJrnDuxgHti6D0x4cJ73yQhFIn1Mul1UOscd5DPJ+lnKE38HrXINHJKm+j024oGsY5tR UfxQ== Received: by 10.236.173.202 with SMTP id v50mr27705704yhl.102.1331051393608; Tue, 06 Mar 2012 08:29:53 -0800 (PST) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.162.33]) by mx.google.com with ESMTPS id i7sm12625659ani.17.2012.03.06.08.29.41 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 08:29:42 -0800 (PST) Message-ID: <4F563B74.6000301@gmail.com> Date: Tue, 06 Mar 2012 11:29:40 -0500 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian Campbell References: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943663DB078@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030402000801010707030308" Cc: oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:30:06 -0000 This is a multi-part message in MIME format. --------------030402000801010707030308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit as one of the unnamed 'confused colleagues', I'd welcome clarification paul On 3/6/12 11:23 AM, Brian Campbell wrote: > Thanks Mike, I think changing the example would be helpful. > > However I think that including some text along the lines of what James > suggested would also be very valuable. I agree that the connection > between OAuth and Bearer could and should be made more explicit. And > that the implications of the b64token syntax, particularly on what AS > can use to construct ATs, could/should be made more clear. > > I can propose some specific text (building on James') if others in the WG agree? > > > On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones wrote: >> I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values. >> >> I'll add it to my to-do list for any additional edits for the Bearer spec. >> >> -- Mike >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H >> Sent: Monday, March 05, 2012 3:33 PM >> To: Brian Campbell; oauth >> Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer >> >> Brian, >> >>> On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer >>> Tokens"* I've encountered several people (including myself) who have >>> made the assumption that the name b64token implies that some kind of >>> base64 encoding/decoding on the access token is taking place between >>> the client and RS. >>> >>> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**, >>> however, I see that b64token is just an ABNF syntax definition >>> allowing for characters typically used in base64, base64url, etc.. So >>> the b64token doesn't define any encoding or decoding but rather just >>> defines what characters can be used in the part of the Authorization >>> header that will contain the access token. >>> >>> Do I read this correctly? >> Yes. >> >>> If so, I feel like some additional clarifying text in the Bearer >>> Tokens draft might help avoid what is (based on my small sample) a >>> common point of misunderstanding. >> Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing: >> Authorization: Bearer vF9dft4qmT >> to >> Authorization: Bearer vF9.dft4.qmT >> >> The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the "access_token" member of an access token response is the bearer token. The "access_token" string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the "Bearer" OAuth access token type is defined. >> >> >>> Also, does the use of b64token implicitly limit the allowed characters >>> that an AS can use to construct a bearer access token? >> Yes. >> >> >>> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 >>> ** >>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 >> -- >> James Manger >> _______________________________________________ >> 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 --------------030402000801010707030308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit as one of the unnamed 'confused colleagues', I'd welcome clarification

paul

On 3/6/12 11:23 AM, Brian Campbell wrote: 
Thanks Mike, I think changing the example would be helpful.

However I think that including some text along the lines of what James
suggested would also be very valuable. I agree that the connection
between OAuth and Bearer could and should be made more explicit. And
that the implications of the b64token syntax, particularly on what AS
can use to construct ATs, could/should be made more clear.

I can propose some specific text (building on James') if others in the WG agree?


On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values.

I'll add it to my to-do list for any additional edits for the Bearer spec.

                               -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Monday, March 05, 2012 3:33 PM
To: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer

Brian,


On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
Tokens"* I've encountered several people (including myself) who have
made the assumption that the name b64token implies that some kind of
base64 encoding/decoding on the access token is taking place between
the client and RS.

Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,
however, I see that b64token is just an ABNF syntax definition
allowing for characters typically used in base64, base64url, etc.. So
the b64token doesn't define any encoding or decoding but rather just
defines what characters can be used in the part of the Authorization
header that will contain the access token.

Do I read this correctly?

Yes.


If so, I feel like some additional clarifying text in the Bearer
Tokens draft might help avoid what is (based on my small sample) a
common point of misunderstanding.

Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing:
 Authorization: Bearer vF9dft4qmT
to
 Authorization: Bearer vF9.dft4.qmT

The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the "access_token" member of an access token response is the bearer token. The "access_token" string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the "Bearer" OAuth access token type is defined.



Also, does the use of b64token implicitly limit the allowed characters
that an AS can use to construct a bearer access token?

Yes.



* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1
**
http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1

--
James Manger
_______________________________________________
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
--------------030402000801010707030308-- From jricher@mitre.org Tue Mar 6 08:33:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0BF21F88A4 for ; Tue, 6 Mar 2012 08:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROWpa4+WmuNd for ; Tue, 6 Mar 2012 08:33:39 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D3A3921F8863 for ; Tue, 6 Mar 2012 08:33:37 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3B00821B1FD9; Tue, 6 Mar 2012 11:33:37 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id F404E21B1FF4; Tue, 6 Mar 2012 11:33:36 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 6 Mar 2012 11:33:36 -0500 Message-ID: <4F563C04.4030009@mitre.org> Date: Tue, 6 Mar 2012 11:32:04 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Paul Madsen References: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943663DB078@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F563B74.6000301@gmail.com> In-Reply-To: <4F563B74.6000301@gmail.com> Content-Type: multipart/alternative; boundary="------------050903050007090200050700" X-Originating-IP: [129.83.31.51] Cc: oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:33:40 -0000 --------------050903050007090200050700 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit I think clarification text makes sense here because we're importing a term from a foreign spec -- b64token -- that overlaps with a term meaning something quite different in our spec -- token. We can't really change either of these terms, so we need to separate them some other way. -- Justin On 03/06/2012 11:29 AM, Paul Madsen wrote: > as one of the unnamed 'confused colleagues', I'd welcome clarification > > paul > > On 3/6/12 11:23 AM, Brian Campbell wrote: >> Thanks Mike, I think changing the example would be helpful. >> >> However I think that including some text along the lines of what James >> suggested would also be very valuable. I agree that the connection >> between OAuth and Bearer could and should be made more explicit. And >> that the implications of the b64token syntax, particularly on what AS >> can use to construct ATs, could/should be made more clear. >> >> I can propose some specific text (building on James') if others in the WG agree? >> >> >> On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones wrote: >>> I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values. >>> >>> I'll add it to my to-do list for any additional edits for the Bearer spec. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H >>> Sent: Monday, March 05, 2012 3:33 PM >>> To: Brian Campbell; oauth >>> Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer >>> >>> Brian, >>> >>>> On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer >>>> Tokens"* I've encountered several people (including myself) who have >>>> made the assumption that the name b64token implies that some kind of >>>> base64 encoding/decoding on the access token is taking place between >>>> the client and RS. >>>> >>>> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**, >>>> however, I see that b64token is just an ABNF syntax definition >>>> allowing for characters typically used in base64, base64url, etc.. So >>>> the b64token doesn't define any encoding or decoding but rather just >>>> defines what characters can be used in the part of the Authorization >>>> header that will contain the access token. >>>> >>>> Do I read this correctly? >>> Yes. >>> >>>> If so, I feel like some additional clarifying text in the Bearer >>>> Tokens draft might help avoid what is (based on my small sample) a >>>> common point of misunderstanding. >>> Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing: >>> Authorization: Bearer vF9dft4qmT >>> to >>> Authorization: Bearer vF9.dft4.qmT >>> >>> The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the "access_token" member of an access token response is the bearer token. The "access_token" string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the "Bearer" OAuth access token type is defined. >>> >>> >>>> Also, does the use of b64token implicitly limit the allowed characters >>>> that an AS can use to construct a bearer access token? >>> Yes. >>> >>> >>>> *http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 >>>> ** >>>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 >>> -- >>> James Manger >>> _______________________________________________ >>> 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 --------------050903050007090200050700 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I think clarification text makes sense here because we're importing a term from a foreign spec -- b64token -- that overlaps with a term meaning something quite different in our spec -- token. We can't really change either of these terms, so we need to separate them some other way.
 -- Justin

On 03/06/2012 11:29 AM, Paul Madsen wrote:
as one of the unnamed 'confused colleagues', I'd welcome clarification

paul

On 3/6/12 11:23 AM, Brian Campbell wrote: 
Thanks Mike, I think changing the example would be helpful.

However I think that including some text along the lines of what James
suggested would also be very valuable. I agree that the connection
between OAuth and Bearer could and should be made more explicit. And
that the implications of the b64token syntax, particularly on what AS
can use to construct ATs, could/should be made more clear.

I can propose some specific text (building on James') if others in the WG agree?


On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values.

I'll add it to my to-do list for any additional edits for the Bearer spec.

                               -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Monday, March 05, 2012 3:33 PM
To: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer

Brian,


On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
Tokens"* I've encountered several people (including myself) who have
made the assumption that the name b64token implies that some kind of
base64 encoding/decoding on the access token is taking place between
the client and RS.

Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,
however, I see that b64token is just an ABNF syntax definition
allowing for characters typically used in base64, base64url, etc.. So
the b64token doesn't define any encoding or decoding but rather just
defines what characters can be used in the part of the Authorization
header that will contain the access token.

Do I read this correctly?

Yes.


If so, I feel like some additional clarifying text in the Bearer
Tokens draft might help avoid what is (based on my small sample) a
common point of misunderstanding.

Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing:
 Authorization: Bearer vF9dft4qmT
to
 Authorization: Bearer vF9.dft4.qmT

The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the "access_token" member of an access token response is the bearer token. The "access_token" string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the "Bearer" OAuth access token type is defined.



Also, does the use of b64token implicitly limit the allowed characters
that an AS can use to construct a bearer access token?

Yes.



* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1
**
http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1

--
James Manger
_______________________________________________
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

--------------050903050007090200050700-- From jricher@mitre.org Tue Mar 6 08:39:50 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31F321F8609 for ; Tue, 6 Mar 2012 08:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34ntJCsFIXt6 for ; Tue, 6 Mar 2012 08:39:50 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 885D221F85AD for ; Tue, 6 Mar 2012 08:39:48 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2AEEA21B0464; Tue, 6 Mar 2012 11:39:48 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1A28C21B0BD9; Tue, 6 Mar 2012 11:39:48 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 6 Mar 2012 11:39:47 -0500 Message-ID: <4F563D77.3050105@mitre.org> Date: Tue, 6 Mar 2012 11:38:15 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sergey Beryozkin References: <4F54ABDB.1050702@gmail.com> <4F54CA3A.8020502@mitre.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:39:51 -0000 > OK. > > Thanks for the explanations so far. It's very helpful. > > I'm prototyping the framework support for OAuth 2.0 and at this stage > I'm trying to figure out what exactly the runtime itself can do and what > has to be delegated to the custom code and thus how to design the api > the runtime and the custom code will use to communicate with each other. Makes sense. It's often hard to figure out exactly where to draw the lines of abstraction for fundamental libraries like this. > Let me ask one more question, sorry if it's a silly one :-) > > So suppose a given client has been pre-authorized by the end user. > Next, the client can get the pre-authorized token via the authorization > code flow or the implicit code flow (ignoring the client_credentials one > for the moment). > > Does it make sense to restrict which flow a given pre-authorized token > can 'work' with ? Example, enforce that the pre-authorized token can > only be issued to the clients initiating an authorization code flow but > not to those trying an implicit one, or vice versa ? > > The reason I ask is that I'm thinking that the entity representing an > access token should have a property indicating which grant type was used > for this token being created in the first place. So if such a token > were to represent the user pre-authorizing the client > and then eventually given to a client via the authorization code or > implicit code flow, then this token would actually need to > be cloned each time for a specific grant type property be set, and > this does not look optimal... Several implementations that I've seen do restrict the flows that a given client is allowed to do. Any time you have a privileged client, such as one that's been auto-approved, it makes even more sense to lock it down in other avenues. You don't have to encode it into the token or code, but of course if you have a structured token format you may do that. Note that with the code flow, you probably don't actually generate the token until the client shows up with a valid code and client id/secret, but that's really a runtime optimization that's going to be specific for your setup. All you really need is a flag at your AS that ties the given client id to a set of allowable grant types. When the client shows up at the AS endpoints, you look up this flag based on the client ID and verify that the flow you're doing matches up with what's allowed by configuration. -- Justin From wmills@yahoo-inc.com Tue Mar 6 10:45:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C18F21F85ED for ; Tue, 6 Mar 2012 10:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.218 X-Spam-Level: X-Spam-Status: No, score=-17.218 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaPlSfjP0oLo for ; Tue, 6 Mar 2012 10:45:29 -0800 (PST) Received: from nm19.bullet.mail.sp2.yahoo.com (nm19.bullet.mail.sp2.yahoo.com [98.139.91.89]) by ietfa.amsl.com (Postfix) with SMTP id CBB8321F8501 for ; Tue, 6 Mar 2012 10:45:29 -0800 (PST) Received: from [98.139.91.64] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 06 Mar 2012 18:45:29 -0000 Received: from [98.139.91.25] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 06 Mar 2012 18:45:29 -0000 Received: from [127.0.0.1] by omp1025.mail.sp2.yahoo.com with NNFMP; 06 Mar 2012 18:45:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 672306.63959.bm@omp1025.mail.sp2.yahoo.com Received: (qmail 92354 invoked by uid 60001); 6 Mar 2012 18:45:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1331059529; bh=+4679B/Zt6gVACZZ7Cm2GFPKuCNf7b7TX13vq9qka/4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GBkbhgnEYF9FuyeNY23l//Ps6t3fTuyyBAYlYd+ie27rlzAQxw6si7mXRJ2sNB+2AtTRU0ncwvhHk8QoGPQkHypJH+RsuCAwOk7UoIlr72yoOEmTxs44/ROtp0WPbITU7ZxU5R50/QFaXsca9/Uw9QHIss0DVT2Hqf4karYgMKU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HuAZyexVEAba7wzuq3dHwXF0mSw0gMZmp2XM7eV4SsJ0/4DvBA+tKFvkS6UTdgq/5wcc88FFk1UlPMQckPiRIZXtwgAcqZW4rtETlaEfLG6smipkAVwW759wKrw3GKtVGfVqtSV2veBcbQXH0C4O1xHAYZmEO+/R9ZcFTIDMWo0=; X-YMail-OSG: toE5Es4VM1l10eJavYdRnjISNAKcJAXTsVwRqW6ASDRnZbp WxcIwvV9clYJ9BX3hTrsig9bCTXyyMdDVgqYSwxAlDfHEqfv6_FWVnioiVSq 6_2AfKaijcSXZhQNYzUdKmHCPOE5PL0Ik.MGu2kq8XlhEY4a.GEeJigHsPOn f7NDpyi0_dU2X9EJYTUgYz3WHGflPCgNi7NyKv62G.PjP976AcWcSbpDnq.e Hlfpv4mSCkHEzLdEHxA9DUK4OQ0._L94BktvyuYX4PZnvSOHSncPwhdss35Q TGlYfCaxyIBxFWbeF25yHAqes0dQWzUEJdpc..sW7NTEWxx4yCYTKQ5Ezy4e DUYAe9MrTl.ZHJzWMgn81efOooNeU5X2XVp4P8VS.Lb1jrSrh1pnH977mq4n gEXiDvgH9eRY8kw5uDyjGp1xnfUVNHWpdmnNGtxnHBWGXXLrMIA-- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Tue, 06 Mar 2012 10:45:28 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943663DB078@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1331059528.92345.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Tue, 6 Mar 2012 10:45:28 -0800 (PST) From: William Mills To: Brian Campbell , Mike Jones In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-743777887-1331059528=:92345" Cc: oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:45:31 -0000 ---1055047407-743777887-1331059528=:92345 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, something as simple as, "Note that the name 'b64token' does not imply= base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would d= o it.=0A=0A=A0-bill=0A=0A=0A=0A=0A________________________________=0A From:= Brian Campbell =0ATo: Mike Jones =0ACc: oauth =0ASent: Tuesday, March 6, 2= 012 8:23 AM=0ASubject: Re: [OAUTH-WG] question about the b64token syntax in= draft-ietf-oauth-v2-bearer=0A =0AThanks Mike, I think changing the example= would be helpful.=0A=0AHowever I think that including some text along the = lines of what James=0Asuggested would also be very valuable. I agree that t= he connection=0Abetween OAuth and Bearer could and should be made more expl= icit. And=0Athat the implications of the b64token syntax, particularly on w= hat AS=0Acan use to construct ATs, could/should be made more clear.=0A=0AI = can propose some specific text (building on James') if others in the WG agr= ee?=0A=0A=0AOn Mon, Mar 5, 2012 at 5:32 PM, Mike Jones wrote:=0A> I'm fine with changing the example to make it clearer = that b64token allows a wider range of characters than just those legal for = base64 and base64url encodings of data values.=0A>=0A> I'll add it to my to= -do list for any additional edits for the Bearer spec.=0A>=0A> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike=0A>=0A> -----Ori= ginal Message-----=0A> From: oauth-bounces@ietf.org [mailto:oauth-bounces@i= etf.org] On Behalf Of Manger, James H=0A> Sent: Monday, March 05, 2012 3:33= PM=0A> To: Brian Campbell; oauth=0A> Subject: Re: [OAUTH-WG] question abou= t the b64token syntax in draft-ietf-oauth-v2-bearer=0A>=0A> Brian,=0A>=0A>>= On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer=0A>> To= kens"* I've encountered several people (including myself) who have=0A>> mad= e the assumption that the name b64token implies that some kind of=0A>> base= 64 encoding/decoding on the access token is taking place between=0A>> the c= lient and RS.=0A>>=0A>> Digging a bit deeper in to "HTTP/1.1, part 7: Authe= ntication"**,=0A>> however, I see that b64token is just an ABNF syntax defi= nition=0A>> allowing for characters typically used in base64, base64url, et= c.. So=0A>> the b64token doesn't define any encoding or decoding but rather= just=0A>> defines what characters can be used in the part of the Authoriza= tion=0A>> header that will contain the access token.=0A>>=0A>> Do I read th= is correctly?=0A>=0A> Yes.=0A>=0A>> If so, I feel like some additional clar= ifying text in the Bearer=0A>> Tokens draft might help avoid what is (based= on my small sample) a=0A>> common point of misunderstanding.=0A>=0A> Chang= ing the example bearer token should be a simple way to avoid some confusion= by showing that it does not have to be base64 encoding. How about changing= :=0A> =A0Authorization: Bearer vF9dft4qmT=0A> to=0A> =A0Authorization: Bear= er vF9.dft4.qmT=0A>=0A> The Bearer spec has lots of (unnecessary) text abou= t OAuth, but doesn't quite manage to be precise about how OAuth and Bearer = connect. It could explicitly state that the string value of the "access_tok= en" member of an access token response is the bearer token. The "access_tok= en" string value (after unescaping any JSON-escapes) MUST match the b64toke= n ABNF so it can be used with the Bearer HTTP scheme. Such text could be pu= t in =A75.1.1 where the "Bearer" OAuth access token type is defined.=0A>=0A= >=0A>> Also, does the use of b64token implicitly limit the allowed characte= rs=0A>> that an AS can use to construct a bearer access token?=0A>=0A> Yes.= =0A>=0A>=0A>> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#se= ction-2.1=0A>> **=0A>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-aut= h-18#section-2.1=0A>=0A> --=0A> James Manger=0A> __________________________= _____________________=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https:/= /www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A____________________________= ___________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.iet= f.org/mailman/listinfo/oauth ---1055047407-743777887-1331059528=:92345 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, something as simple as, "Note that the name 'b64token' does not imp= ly base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would= do it.
 
-bill

From:= Brian Campbell <bcampbell@pingidentity.com>
To: Mike Jones <Michael.Jones@microso= ft.com>
Cc: oauth &= lt;oauth@ietf.org>
Sent: Tuesday, March 6, 2012 8:23 AM
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-o= auth-v2-bearer

=0AThanks Mike, I think changing the = example would be helpful.

However I think that including some text a= long the lines of what James
suggested would also be very valuable. I ag= ree that the connection
between OAuth and Bearer could and should be mad= e more explicit. And
that the implications of the b64token syntax, parti= cularly on what AS
can use to construct ATs, could/should be made more c= lear.

I can propose some specific text (building on James') if other= s in the WG agree?


On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones &l= t;Michael.Jones@microsoft.com> wrote:
> I'm= fine with changing the example to make it clearer that b64token allows a w= ider range of characters than just those legal for base64 and base64url enc= odings of data values.
>
> I'll add it to my to-do list for any= additional edits for the Bearer spec.
>
>               &nb= sp;                -- Mike
><= br>> -----Original Message-----
> From: oauth-bounces@iet= f.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger,= James H
> Sent: Monday, March 05, 2012 3:33 PM
> To: Brian Cam= pbell; oauth
> Subject: Re: [OAUTH-WG] question about the b64token sy= ntax in draft-ietf-oauth-v2-bearer
>
> Brian,
>
>&g= t; On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
&g= t;> Tokens"* I've encountered several people (including myself) who have=
>> made the assumption that the name b64token implies that some k= ind of
>> base64 encoding/decoding on the access token is taking place between
>> the client and RS.
>>
>> Diggi= ng a bit deeper in to "HTTP/1.1, part 7: Authentication"**,
>> how= ever, I see that b64token is just an ABNF syntax definition
>> all= owing for characters typically used in base64, base64url, etc.. So
>&= gt; the b64token doesn't define any encoding or decoding but rather just>> defines what characters can be used in the part of the Authorizat= ion
>> header that will contain the access token.
>>
&= gt;> Do I read this correctly?
>
> Yes.
>
>> = If so, I feel like some additional clarifying text in the Bearer
>>= ; Tokens draft might help avoid what is (based on my small sample) a
>= ;> common point of misunderstanding.
>
> Changing the exampl= e bearer token should be a simple way to avoid some confusion by showing th= at it does not have to be base64 encoding. How about changing:
>  Authorization: Bearer vF9dft4qmT
> to
>= ;  Authorization: Bearer vF9.dft4.qmT
>
> The Bearer spec = has lots of (unnecessary) text about OAuth, but doesn't quite manage to be = precise about how OAuth and Bearer connect. It could explicitly state that = the string value of the "access_token" member of an access token response i= s the bearer token. The "access_token" string value (after unescaping any J= SON-escapes) MUST match the b64token ABNF so it can be used with the Bearer= HTTP scheme. Such text could be put in =A75.1.1 where the "Bearer" OAuth a= ccess token type is defined.
>
>
>> Also, does the use= of b64token implicitly limit the allowed characters
>> that an AS= can use to construct a bearer access token?
>
> Yes.
>>
>> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-= 17#section-2.1
>> **
>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1
&g= t;
> --
> James Manger
> ________________________________= _______________
> OAuth mailing list
> OAuth@ietf.org
> https= ://www.ietf.org/mailman/listinfo/oauth
>
>
_____________= __________________________________
OAuth mailing list
OAuth@ietf.org
= h= ttps://www.ietf.org/mailman/listinfo/oauth


<= /div>
---1055047407-743777887-1331059528=:92345-- From bcampbell@pingidentity.com Wed Mar 7 09:17:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC54F21E80EF for ; Wed, 7 Mar 2012 09:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.81 X-Spam-Level: X-Spam-Status: No, score=-5.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU3WytYx+qk3 for ; Wed, 7 Mar 2012 09:17:03 -0800 (PST) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8889421E80A0 for ; Wed, 7 Mar 2012 09:17:03 -0800 (PST) Received: from mail-vx0-f180.google.com ([209.85.220.180]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKT1eYDoGAGDVLitNylpinCxJ4QwYVB1b9@postini.com; Wed, 07 Mar 2012 09:17:03 PST Received: by mail-vx0-f180.google.com with SMTP id fl10so5573803vcb.39 for ; Wed, 07 Mar 2012 09:17:02 -0800 (PST) Received: by 10.52.72.130 with SMTP id d2mr970387vdv.80.1331140622394; Wed, 07 Mar 2012 09:17:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.171.172 with HTTP; Wed, 7 Mar 2012 09:16:31 -0800 (PST) In-Reply-To: <1331059528.92345.YahooMailNeo@web31806.mail.mud.yahoo.com> References: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943663DB078@TK5EX14MBXC283.redmond.corp.microsoft.com> <1331059528.92345.YahooMailNeo@web31806.mail.mud.yahoo.com> From: Brian Campbell Date: Wed, 7 Mar 2012 10:16:31 -0700 Message-ID: To: William Mills Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmyb6GvMVvrAamYC5hv/bumgIwoQXxrHU8mRFS2qdkh2U+HNO8TfnO/M/pIsEoc3Zycs4K2 Cc: oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:17:04 -0000 I'd like to propose the following changes and additions, derived largely from Bill and James suggestions, to draft-ietf-oauth-v2-bearer-17. These changes have no normative impact and only aim to add additional clarity and explanation the workings and implications of the current spec. I'm definitely open to changes or improvements in the wording here (not my strong suit by any means) but I think it's important that these general ideas be conveyed in the draft. =3D=3D> Insert the following text at the beginning of =A72: To make a protected resource request, the client must be in possession of a valid bearer token. Typically a bearer token is returned to the client as part of an access token response as defined in OAuth 2.0 [I-D.ietf-oauth-v2]. When the "token_type" parameter of the access token response is "Bearer", the string value of the "access_token" parameter becomes the bearer access token used to make protected resource requests. =3D=3D> Change the value of the token in the Authorization header example t= o this: Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b =3D=3D> Insert the following text before the last paragraph of =A72.1: Note that the name b64token does not imply base64 encoding but rather is the name for an ABNF syntax definition from HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token" string value from an access token response MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Thanks, Brian On Tue, Mar 6, 2012 at 11:45 AM, William Mills wrote= : > Yeah, something as simple as, "Note that the name 'b64token' does not imp= ly > base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would = do > it. > > -bill > > ________________________________ > From: Brian Campbell > To: Mike Jones > Cc: oauth > Sent: Tuesday, March 6, 2012 8:23 AM > > Subject: Re: [OAUTH-WG] question about the b64token syntax in > draft-ietf-oauth-v2-bearer > > Thanks Mike, I think changing the example would be helpful. > > However I think that including some text along the lines of what James > suggested would also be very valuable. I agree that the connection > between OAuth and Bearer could and should be made more explicit. And > that the implications of the b64token syntax, particularly on what AS > can use to construct ATs, could/should be made more clear. > > I can propose some specific text (building on James') if others in the WG > agree? > > > On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones > wrote: >> I'm fine with changing the example to make it clearer that b64token allo= ws >> a wider range of characters than just those legal for base64 and base64u= rl >> encodings of data values. >> >> I'll add it to my to-do list for any additional edits for the Bearer spe= c. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> Manger, James H >> Sent: Monday, March 05, 2012 3:33 PM >> To: Brian Campbell; oauth >> Subject: Re: [OAUTH-WG] question about the b64token syntax in >> draft-ietf-oauth-v2-bearer >> >> Brian, >> >>> On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer >>> Tokens"* I've encountered several people (including myself) who have >>> made the assumption that the name b64token implies that some kind of >>> base64 encoding/decoding on the access token is taking place between >>> the client and RS. >>> >>> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**, >>> however, I see that b64token is just an ABNF syntax definition >>> allowing for characters typically used in base64, base64url, etc.. So >>> the b64token doesn't define any encoding or decoding but rather just >>> defines what characters can be used in the part of the Authorization >>> header that will contain the access token. >>> >>> Do I read this correctly? >> >> Yes. >> >>> If so, I feel like some additional clarifying text in the Bearer >>> Tokens draft might help avoid what is (based on my small sample) a >>> common point of misunderstanding. >> >> Changing the example bearer token should be a simple way to avoid some >> confusion by showing that it does not have to be base64 encoding. How ab= out >> changing: >> =A0Authorization: Bearer vF9dft4qmT >> to >> =A0Authorization: Bearer vF9.dft4.qmT >> >> The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't >> quite manage to be precise about how OAuth and Bearer connect. It could >> explicitly state that the string value of the "access_token" member of a= n >> access token response is the bearer token. The "access_token" string val= ue >> (after unescaping any JSON-escapes) MUST match the b64token ABNF so it c= an >> be used with the Bearer HTTP scheme. Such text could be put in =A75.1.1 = where >> the "Bearer" OAuth access token type is defined. >> >> >>> Also, does the use of b64token implicitly limit the allowed characters >>> that an AS can use to construct a bearer access token? >> >> Yes. >> >> >>> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 >>> ** >>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 >> >> -- >> James Manger >> _______________________________________________ >> 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 hardjono@mit.edu Wed Mar 7 10:36:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F0021E80BC for ; Wed, 7 Mar 2012 10:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI8nvdooPo+S for ; Wed, 7 Mar 2012 10:36:33 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id D410621E8017 for ; Wed, 7 Mar 2012 10:36:32 -0800 (PST) X-AuditID: 1209190d-b7fbf6d0000008ba-f8-4f57aaafac80 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 8A.C6.02234.FAAA75F4; Wed, 7 Mar 2012 13:36:31 -0500 (EST) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id q27IaVnb029283 for ; Wed, 7 Mar 2012 13:36:31 -0500 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id q27IaRTm023945 for ; Wed, 7 Mar 2012 13:36:31 -0500 Received: from OC11EXHUB11.exchange.mit.edu (18.9.3.25) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Mar 2012 13:36:17 -0500 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.142]) by OC11EXHUB11.exchange.mit.edu ([18.9.3.25]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 13:36:29 -0500 From: Thomas Hardjono To: "oauth@ietf.org" Thread-Topic: Status of OAUTH re-charter discussion Thread-Index: Acz8kTWfLodHBoznRTOZ/7UqX31Wyg== Date: Wed, 7 Mar 2012 18:36:29 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A1071D075@OC11EXPO24.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.189.40.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsUixG6nrrt+Vbi/waabOhYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpnTcgWTmCqe3dnM2MB4jbGLkZNDQsBE4vaJnUwQtpjEhXvr 2boYuTiEBPYxSqx8sIYdwrnCKLFl2iNmkCohgVuMEpsuFkIktjFKdK+6xwrhrGKUWDDjJBtI FZuAhsS533vZQWwRAVWJfUevgNnCAnoSPbdaWCHixhLXPu+AqtGTOPhrD5DNwcEioCKxflo1 SJhXIEji8dpnYKcyAp33/dQasFOZBcQlbj2ZD3W2oMSi2XuYYV74t+shG4StKHF8831miHod iQW7P7FB2NoSyxa+ZoaYLyhxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYpRNya3SzU3MzClO TdYtTk7My0st0jXSy80s0UtNKd3ECIoeTkneHYzvDiodYhTgYFTi4c2cFu4vxJpYVlyZe4hR koNJSZS3cgVQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjvt0VAOd6UxMqq1KJ8mJQ0B4uSOK+q 1js/IYH0xJLU7NTUgtQimKwMB4eSBO+blUCNgkWp6akVaZk5JQhpJg5OkOE8QMOPg9TwFhck 5hZnpkPkTzEqSonzXgVJCIAkMkrz4Hphye0VozjQK8K8j0CqeICJEa77FdBgJqDBmTJgg0sS EVJSDYxz/4g3/+6Q/Z8TVH77w6N889V6m7x7X301vHa+OPQc/+Tfqe6pjx+XhHVrcd+eUWGu 98s23156Z+rrM+Kqzyb8UVRz+XB7+dQ3Fo9jnvWmP1g+xfHbSu+phxJyb7bvqz2SHrqv9+jd H+xGG6/kB176/ejjE26GQ61x3/7yK6k+9ztcId59+PweJZbijERDLeai4kQAgC2y00kDAAA= Subject: [OAUTH-WG] Status of OAUTH re-charter discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 18:36:33 -0000 What is the status of the OAUTH WG re-charter efforts? The last thread was = back in October. Will the re-charter be on the IETF-Paris agenda? (or will it be pushed out = to the July 2012 IETF). Thanks. /thomas/ __________________________________________ From hannes.tschofenig@gmx.net Wed Mar 7 10:45:02 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1FD21F8599 for ; Wed, 7 Mar 2012 10:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.882 X-Spam-Level: X-Spam-Status: No, score=-101.882 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiJM-ZOEtOev for ; Wed, 7 Mar 2012 10:45:01 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8F88D21F8597 for ; Wed, 7 Mar 2012 10:44:56 -0800 (PST) Received: (qmail invoked by alias); 07 Mar 2012 18:44:53 -0000 Received: from unknown (EHLO [10.255.128.218]) [192.100.123.77] by mail.gmx.net (mp033) with SMTP; 07 Mar 2012 19:44:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19bX8w4iGRb7/BPmW82yBEeCcFZeCNHPKRtpqtT/P pEJLn1zPIiqK9L Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5E393DF26B791A428E5F003BB6C5342A1071D075@OC11EXPO24.exchange.mit.edu> Date: Wed, 7 Mar 2012 20:44:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A7A6A3D-06DD-42EE-818E-822DBD672EFC@gmx.net> References: <5E393DF26B791A428E5F003BB6C5342A1071D075@OC11EXPO24.exchange.mit.edu> To: Thomas Hardjono X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Status of OAUTH re-charter discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 18:45:03 -0000 I was planning to kick of a discussion next week with a strawman = proposal for a new charter text.=20 Ciao Hannes On Mar 7, 2012, at 8:36 PM, Thomas Hardjono wrote: > What is the status of the OAUTH WG re-charter efforts? The last thread = was back in October. >=20 > Will the re-charter be on the IETF-Paris agenda? (or will it be pushed = out to the July 2012 IETF). >=20 > Thanks. >=20 > /thomas/ >=20 > __________________________________________ >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Wed Mar 7 10:45:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E3D11E8072 for ; Wed, 7 Mar 2012 10:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.228 X-Spam-Level: X-Spam-Status: No, score=-17.228 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeTwbcatFJYI for ; Wed, 7 Mar 2012 10:45:32 -0800 (PST) Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (nm12-vm0.bullet.mail.bf1.yahoo.com [98.139.213.140]) by ietfa.amsl.com (Postfix) with SMTP id 1255B11E8073 for ; Wed, 7 Mar 2012 10:45:31 -0800 (PST) Received: from [98.139.212.152] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2012 18:45:26 -0000 Received: from [98.139.212.203] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2012 18:45:26 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 07 Mar 2012 18:45:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 465761.12314.bm@omp1012.mail.bf1.yahoo.com Received: (qmail 10064 invoked by uid 60001); 7 Mar 2012 18:45:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1331145925; bh=5yRmmE9g9/Qw2My4raifMhFy9uwV+oSpE3zhomS9lsw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=biFqvTCcuRZQocjaESluo+uAnjfvm/8PjhUQqhs62s/Hy2Nr2YPnYAGdcxqAj42XOgQDNtc0GT8PCv7hyY4DC5V0IWrOwQKC5yrqdh9VV9G5C3UKTW288Ut6HJhry/b41kw5/n8XJNONozPfEfUFo8XySnIUbUvX4Y7GDpd5MKs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Yfxh2wGEfjrkphPxHMyEzSyu8mz1slldyvdhmgFX7IJGRob/yHM6EuQGXh6NLBgcTTkEtZ+4BWeko6CGnqFmUPal+QflazYO+NI25W7oDZWVw9FJ1vABxcLEgQCsVdTEqAL7JhLYtIsYoDEh6acJKbRKMnnAf6CFyI8x0HbAr6g=; X-YMail-OSG: Ah6mEzoVM1kO.Jt2ylBuy.0YI6odV4QPunvOWoQOhNtjhX2 pJRrrcPK3TByE9DBZ6_19vVe96tE2P8OLv9JN1z_m2DrARY61c2P80C41Yj3 lI.aigOc5i3cRw6JboFTWsVB2ow6I2w3nT21rEKUnQCSII.m0dxXpnRHFtK1 Qls2AiOvDNqOwD6n53sURAamBrrIF.I2B33WYdBQ1tnJBZeyUJpWTZ5Qq5_Y P3xkeXQCn8vhq70la6pcKjQI9ZDuQgrLt8P.KU0Ls11Ae_Y2kihTSlXQ7Y2F lgEdyyG.Zk8CwFOrQ5MwVx41NomkB3JE7RZFJOB3TzYmqvWjEdAzr7RBKOee CtwyqOU5vLK9PCQIGHwpqCV.jiiEaWZcFwvCCWJE5wXWxVNbUEtO87tHt70T 8YqB3FDAp7mTa3lOgtYkTNFZriIAtbaEefkiNGNY4IN9INAIN3.E9RVpXu16 QEukNn3hAQ0OmlJq0Z57snB7FbYM4VAMLKGVTQMK.DtKxE33iYyyTk5Yw8fm TExDQjrYRh9.YXJ.ZF0sjbafQpLJzPMazd3PhgsRxO5Aj8IoRjB4VttSoxhY aLpvtUO0- Received: from [209.131.62.116] by web31807.mail.mud.yahoo.com via HTTP; Wed, 07 Mar 2012 10:45:25 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943663DB078@TK5EX14MBXC283.redmond.corp.microsoft.com> <1331059528.92345.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1331145925.9591.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Wed, 7 Mar 2012 10:45:25 -0800 (PST) From: William Mills To: Brian Campbell In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-5876745-1331145925=:9591" Cc: oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 18:45:33 -0000 ---125733401-5876745-1331145925=:9591 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable works for me.=0A=0A=A0=0A=0A=0AP.S. Please start using the http://twiki.cor= p.yahoo.com/view/Paranoidyahoos/SecurityRequest=A0 for new requests like pr= oduct and feature=A0 reviews.=0A=0A=0A=0A________________________________= =0A From: Brian Campbell =0ATo: William Mills <= wmills@yahoo-inc.com> =0ACc: Mike Jones ; oaut= h =0ASent: Wednesday, March 7, 2012 9:16 AM=0ASubject: Re:= [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-beare= r=0A =0AI'd like to propose the following changes and additions, derived=0A= largely from Bill and James suggestions, to=0Adraft-ietf-oauth-v2-bearer-17= .=A0 These changes have no normative impact=0Aand only aim to add additiona= l clarity and explanation the workings=0Aand implications of the current sp= ec.=A0 I'm definitely open to changes=0Aor improvements in the wording here= (not my strong suit by any means)=0Abut I think it's important that these = general ideas be conveyed in the=0Adraft.=0A=0A=0A=3D=3D> Insert the follow= ing text at the beginning of =A72:=0A=0ATo make a protected resource reques= t, the client must be in possession=0Aof a valid bearer token. Typically a = bearer token is returned to the=0Aclient as part of an access token respons= e as defined in OAuth 2.0=0A[I-D.ietf-oauth-v2]. When the "token_type" para= meter of the access=0Atoken response is "Bearer", the string value of the "= access_token"=0Aparameter becomes the bearer access token used to make prot= ected=0Aresource requests.=0A=0A=3D=3D> Change the value of the token in th= e Authorization header example to this:=0A=0AAuthorization: Bearer vF_9.5dC= f-t4.qbcmT_k1b=0A=0A=3D=3D> Insert the following text before the last parag= raph of =A72.1:=0A=0ANote that the name b64token does not imply base64 enco= ding but rather=0Ais the name for an ABNF syntax definition from HTTP/1.1, = Part 7=0A[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"= =0Astring value from an access token response MUST match the b64token=0AABN= F so it can be used with the Bearer HTTP scheme.=0A=0A=0AThanks,=0ABrian=0A= =0A=0A=0A=0AOn Tue, Mar 6, 2012 at 11:45 AM, William Mills wrote:=0A> Yeah, something as simple as, "Note that the name 'b64tok= en' does not imply=0A> base64 encoding, see the definition in [[INSERT REFE= RENCE HERE]]." would do=0A> it.=0A>=0A> -bill=0A>=0A> _____________________= ___________=0A> From: Brian Campbell =0A> To: M= ike Jones =0A> Cc: oauth =0A> = Sent: Tuesday, March 6, 2012 8:23 AM=0A>=0A> Subject: Re: [OAUTH-WG] questi= on about the b64token syntax in=0A> draft-ietf-oauth-v2-bearer=0A>=0A> Than= ks Mike, I think changing the example would be helpful.=0A>=0A> However I t= hink that including some text along the lines of what James=0A> suggested w= ould also be very valuable. I agree that the connection=0A> between OAuth a= nd Bearer could and should be made more explicit. And=0A> that the implicat= ions of the b64token syntax, particularly on what AS=0A> can use to constru= ct ATs, could/should be made more clear.=0A>=0A> I can propose some specifi= c text (building on James') if others in the WG=0A> agree?=0A>=0A>=0A> On M= on, Mar 5, 2012 at 5:32 PM, Mike Jones =0A> wr= ote:=0A>> I'm fine with changing the example to make it clearer that b64tok= en allows=0A>> a wider range of characters than just those legal for base64= and base64url=0A>> encodings of data values.=0A>>=0A>> I'll add it to my t= o-do list for any additional edits for the Bearer spec.=0A>>=0A>> =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike=0A>>=0A>> --= ---Original Message-----=0A>> From: oauth-bounces@ietf.org [mailto:oauth-bo= unces@ietf.org] On Behalf Of=0A>> Manger, James H=0A>> Sent: Monday, March = 05, 2012 3:33 PM=0A>> To: Brian Campbell; oauth=0A>> Subject: Re: [OAUTH-WG= ] question about the b64token syntax in=0A>> draft-ietf-oauth-v2-bearer=0A>= >=0A>> Brian,=0A>>=0A>>> On casual reading of "The OAuth 2.0 Authorization = Protocol: Bearer=0A>>> Tokens"* I've encountered several people (including = myself) who have=0A>>> made the assumption that the name b64token implies t= hat some kind of=0A>>> base64 encoding/decoding on the access token is taki= ng place between=0A>>> the client and RS.=0A>>>=0A>>> Digging a bit deeper = in to "HTTP/1.1, part 7: Authentication"**,=0A>>> however, I see that b64to= ken is just an ABNF syntax definition=0A>>> allowing for characters typical= ly used in base64, base64url, etc.. So=0A>>> the b64token doesn't define an= y encoding or decoding but rather just=0A>>> defines what characters can be= used in the part of the Authorization=0A>>> header that will contain the a= ccess token.=0A>>>=0A>>> Do I read this correctly?=0A>>=0A>> Yes.=0A>>=0A>>= > If so, I feel like some additional clarifying text in the Bearer=0A>>> To= kens draft might help avoid what is (based on my small sample) a=0A>>> comm= on point of misunderstanding.=0A>>=0A>> Changing the example bearer token s= hould be a simple way to avoid some=0A>> confusion by showing that it does = not have to be base64 encoding. How about=0A>> changing:=0A>> =A0Authorizat= ion: Bearer vF9dft4qmT=0A>> to=0A>> =A0Authorization: Bearer vF9.dft4.qmT= =0A>>=0A>> The Bearer spec has lots of (unnecessary) text about OAuth, but = doesn't=0A>> quite manage to be precise about how OAuth and Bearer connect.= It could=0A>> explicitly state that the string value of the "access_token"= member of an=0A>> access token response is the bearer token. The "access_t= oken" string value=0A>> (after unescaping any JSON-escapes) MUST match the = b64token ABNF so it can=0A>> be used with the Bearer HTTP scheme. Such text= could be put in =A75.1.1 where=0A>> the "Bearer" OAuth access token type i= s defined.=0A>>=0A>>=0A>>> Also, does the use of b64token implicitly limit = the allowed characters=0A>>> that an AS can use to construct a bearer acces= s token?=0A>>=0A>> Yes.=0A>>=0A>>=0A>>> * http://tools.ietf.org/html/draft-= ietf-oauth-v2-bearer-17#section-2.1=0A>>> **=0A>>> http://tools.ietf.org/ht= ml/draft-ietf-httpbis-p7-auth-18#section-2.1=0A>>=0A>> --=0A>> James Manger= =0A>> _______________________________________________=0A>> OAuth mailing li= st=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/oauth=0A>= >=0A>>=0A> _______________________________________________=0A> OAuth mailin= g list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth= =0A>=0A> ---125733401-5876745-1331145925=:9591 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
works for me.
 


=
P.S. Please start using the http://twiki.corp.yahoo.com/view/Paranoidy= ahoos/SecurityRequest  for new requests like product and feature = reviews.

From: Brian Campbell <bcampbell@pingidentity.com>= ;
To: William Mills &l= t;wmills@yahoo-inc.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; oauth <oauth@ie= tf.org>
Sent: Wednesday, Mar= ch 7, 2012 9:16 AM
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth= -v2-bearer

=0AI'd like to propose the following chan= ges and additions, derived
largely from Bill and James suggestions, todraft-ietf-oauth-v2-bearer-17.  These changes have no normative impa= ct
and only aim to add additional clarity and explanation the workingsand implications of the current spec.  I'm definitely open to change= s
or improvements in the wording here (not my strong suit by any means)<= br>but I think it's important that these general ideas be conveyed in thedraft.


=3D=3D> Insert the following text at the beginning o= f =A72:

To make a protected resource request, the client must be in = possession
of a valid bearer token. Typically a bearer token is returned= to the
client as part of an access token response as defined in OAuth 2= .0
[I-D.ietf-oauth-v2]. When the "token_type" parameter of the accesstoken response is "Bearer", the string value of the "access_token"
para= meter becomes the bearer access token used to make protected
resource requests.

=3D=3D> Chang= e the value of the token in the Authorization header example to this:
Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b

=3D=3D> Insert the= following text before the last paragraph of =A72.1:

Note that the n= ame b64token does not imply base64 encoding but rather
is the name for a= n ABNF syntax definition from HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth= ]. Because of its use, the "access_token"
string value from an access to= ken response MUST match the b64token
ABNF so it can be used with the Bea= rer HTTP scheme.


Thanks,
Brian




On Tue, Mar= 6, 2012 at 11:45 AM, William Mills <wmills@yahoo-inc.com> w= rote:
> Yeah, something as simple as, "Note that the name 'b64token' = does not imply
> base64 encoding, see the definition in [[INSERT REFE= RENCE HERE]]." would do
> it.
>
> -bill
>
> ______= __________________________
> From: Brian Campbell <bcampbell@pingidentity.com>
> To: Mike Jones <Michael.Jones@microsoft.com>
> Cc: oauth <oauth@ietf.org<= /a>>
> Sent: Tuesday, March 6, 2012 8:23 AM
>
> Subjec= t: Re: [OAUTH-WG] question about the b64token syntax in
> draft-ietf-= oauth-v2-bearer
>
> Thanks Mike, I think changing the example w= ould be helpful.
>
> However I think that including some text a= long the lines of what James
> suggested would also be very valuable.= I agree that the connection
> between OAuth and Bearer could and sho= uld be made more explicit. And
> that the implications of the b64token synt= ax, particularly on what AS
> can use to construct ATs, could/should = be made more clear.
>
> I can propose some specific text (build= ing on James') if others in the WG
> agree?
>
>
> O= n Mon, Mar 5, 2012 at 5:32 PM, Mike Jones <Michael.Jo= nes@microsoft.com>
> wrote:
>> I'm fine with changing= the example to make it clearer that b64token allows
>> a wider ra= nge of characters than just those legal for base64 and base64url
>>= ; encodings of data values.
>>
>> I'll add it to my to-do= list for any additional edits for the Bearer spec.
>>
>>=                     &nbs= p;          -- Mike
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.o= rg [mailto:oauth-bounces@ietf.org] On Behalf Of
>>= ; Manger, James H
>> Sent: Monday, March 05, 2012 3:33 PM
>&= gt; To: Brian Campbell; oauth
>> Subject: Re: [OAUTH-WG] question = about the b64token syntax in
>> draft-ietf-oauth-v2-bearer
>= >
>> Brian,
>>
>>> On casual reading of "T= he OAuth 2.0 Authorization Protocol: Bearer
>>> Tokens"* I've e= ncountered several people (including myself) who have
>>> made = the assumption that the name b64token implies that some kind of
>>= > base64 encoding/decoding on the access token is taking place between>>> the client and RS.
>>>
>>> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,
>>> how= ever, I see that b64token is just an ABNF syntax definition
>>>= allowing for characters typically used in base64, base64url, etc.. So
&= gt;>> the b64token doesn't define any encoding or decoding but rather= just
>>> defines what characters can be used in the part of th= e Authorization
>>> header that will contain the access token.<= br>>>>
>>> Do I read this correctly?
>>
&g= t;> Yes.
>>
>>> If so, I feel like some additional = clarifying text in the Bearer
>>> Tokens draft might help avoid= what is (based on my small sample) a
>>> common point of misun= derstanding.
>>
>> Changing the example bearer token shou= ld be a simple way to avoid some
>> confusion by showing that it d= oes not have to be base64 encoding. How about
>> changing:
>>  Authorization: Bearer vF9dft4qmT
>> t= o
>>  Authorization: Bearer vF9.dft4.qmT
>>
>&= gt; The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't=
>> quite manage to be precise about how OAuth and Bearer connect.= It could
>> explicitly state that the string value of the "access= _token" member of an
>> access token response is the bearer token.= The "access_token" string value
>> (after unescaping any JSON-esc= apes) MUST match the b64token ABNF so it can
>> be used with the B= earer HTTP scheme. Such text could be put in =A75.1.1 where
>> the= "Bearer" OAuth access token type is defined.
>>
>>
&g= t;>> Also, does the use of b64token implicitly limit the allowed char= acters
>>> that an AS can use to construct a bearer access toke= n?
>>
>> Yes.
>>
>>
>>> * htt= p://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1
&g= t;>> **
>>> http://tools.ietf.org= /html/draft-ietf-httpbis-p7-auth-18#section-2.1
>>
>>= --
>> James Manger
>> __________________________________= _____________
>> OAuth mailing list
>> OAuth@ietf.org
>= ;> https://www.ietf.org/mailman/listinfo/oauth
>>
>>= ;
> _______________________________________________
> OAuth mai= ling list
> OAuth@ietf.org
> https://www.ietf.= org/mailman/listinfo/oauth
>
>


<= /div>
---125733401-5876745-1331145925=:9591-- From jricher@mitre.org Wed Mar 7 11:02:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF0811E8086 for ; Wed, 7 Mar 2012 11:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWO6RwCS1vYs for ; Wed, 7 Mar 2012 11:02:08 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 74C4311E8087 for ; Wed, 7 Mar 2012 11:02:05 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 44E0C21B1987; Wed, 7 Mar 2012 14:02:01 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8D0AE21B0F6B; Wed, 7 Mar 2012 14:02:00 -0500 (EST) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 7 Mar 2012 14:02:00 -0500 Message-ID: <4F57B04A.9070509@mitre.org> Date: Wed, 7 Mar 2012 14:00:26 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian Campbell References: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943663DB078@TK5EX14MBXC283.redmond.corp.microsoft.com> <1331059528.92345.YahooMailNeo@web31806.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [129.83.31.51] Cc: oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:02:10 -0000 Makes sense to me, except that I think the token_type value is typically lowercase "bearer", though it's defined to be case insensitive in Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value of this field for the Bearer token type ever got defined anywhere. Section 7.1 references the bearer spec as defining the value of the "token_type" parameter, and passes its example as if by reference. Would be worthwhile giving an example of a token endpoint response, such as what's found in OAuth-v2-23 section 5.1. -- Justin On 03/07/2012 12:16 PM, Brian Campbell wrote: > I'd like to propose the following changes and additions, derived > largely from Bill and James suggestions, to > draft-ietf-oauth-v2-bearer-17. These changes have no normative impact > and only aim to add additional clarity and explanation the workings > and implications of the current spec. I'm definitely open to changes > or improvements in the wording here (not my strong suit by any means) > but I think it's important that these general ideas be conveyed in the > draft. > > > ==> Insert the following text at the beginning of §2: > > To make a protected resource request, the client must be in possession > of a valid bearer token. Typically a bearer token is returned to the > client as part of an access token response as defined in OAuth 2.0 > [I-D.ietf-oauth-v2]. When the "token_type" parameter of the access > token response is "Bearer", the string value of the "access_token" > parameter becomes the bearer access token used to make protected > resource requests. > > ==> Change the value of the token in the Authorization header example to this: > > Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b > > ==> Insert the following text before the last paragraph of §2.1: > > Note that the name b64token does not imply base64 encoding but rather > is the name for an ABNF syntax definition from HTTP/1.1, Part 7 > [I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token" > string value from an access token response MUST match the b64token > ABNF so it can be used with the Bearer HTTP scheme. > > > Thanks, > Brian > > > > > On Tue, Mar 6, 2012 at 11:45 AM, William Mills wrote: >> Yeah, something as simple as, "Note that the name 'b64token' does not imply >> base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would do >> it. >> >> -bill >> >> ________________________________ >> From: Brian Campbell >> To: Mike Jones >> Cc: oauth >> Sent: Tuesday, March 6, 2012 8:23 AM >> >> Subject: Re: [OAUTH-WG] question about the b64token syntax in >> draft-ietf-oauth-v2-bearer >> >> Thanks Mike, I think changing the example would be helpful. >> >> However I think that including some text along the lines of what James >> suggested would also be very valuable. I agree that the connection >> between OAuth and Bearer could and should be made more explicit. And >> that the implications of the b64token syntax, particularly on what AS >> can use to construct ATs, could/should be made more clear. >> >> I can propose some specific text (building on James') if others in the WG >> agree? >> >> >> On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones >> wrote: >>> I'm fine with changing the example to make it clearer that b64token allows >>> a wider range of characters than just those legal for base64 and base64url >>> encodings of data values. >>> >>> I'll add it to my to-do list for any additional edits for the Bearer spec. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of >>> Manger, James H >>> Sent: Monday, March 05, 2012 3:33 PM >>> To: Brian Campbell; oauth >>> Subject: Re: [OAUTH-WG] question about the b64token syntax in >>> draft-ietf-oauth-v2-bearer >>> >>> Brian, >>> >>>> On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer >>>> Tokens"* I've encountered several people (including myself) who have >>>> made the assumption that the name b64token implies that some kind of >>>> base64 encoding/decoding on the access token is taking place between >>>> the client and RS. >>>> >>>> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**, >>>> however, I see that b64token is just an ABNF syntax definition >>>> allowing for characters typically used in base64, base64url, etc.. So >>>> the b64token doesn't define any encoding or decoding but rather just >>>> defines what characters can be used in the part of the Authorization >>>> header that will contain the access token. >>>> >>>> Do I read this correctly? >>> Yes. >>> >>>> If so, I feel like some additional clarifying text in the Bearer >>>> Tokens draft might help avoid what is (based on my small sample) a >>>> common point of misunderstanding. >>> Changing the example bearer token should be a simple way to avoid some >>> confusion by showing that it does not have to be base64 encoding. How about >>> changing: >>> Authorization: Bearer vF9dft4qmT >>> to >>> Authorization: Bearer vF9.dft4.qmT >>> >>> The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't >>> quite manage to be precise about how OAuth and Bearer connect. It could >>> explicitly state that the string value of the "access_token" member of an >>> access token response is the bearer token. The "access_token" string value >>> (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can >>> be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where >>> the "Bearer" OAuth access token type is defined. >>> >>> >>>> Also, does the use of b64token implicitly limit the allowed characters >>>> that an AS can use to construct a bearer access token? >>> Yes. >>> >>> >>>> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 >>>> ** >>>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 >>> -- >>> James Manger >>> _______________________________________________ >>> 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 From bcampbell@pingidentity.com Wed Mar 7 13:08:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CB521E805E for ; Wed, 7 Mar 2012 13:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.838 X-Spam-Level: X-Spam-Status: No, score=-5.838 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHqFdRvDcSiI for ; Wed, 7 Mar 2012 13:08:46 -0800 (PST) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) by ietfa.amsl.com (Postfix) with ESMTP id 5317F11E8086 for ; Wed, 7 Mar 2012 13:08:46 -0800 (PST) Received: from mail-vx0-f177.google.com ([209.85.220.177]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKT1fOXf4QFkdM2vzAqpqDu84hGpBEi2MQ@postini.com; Wed, 07 Mar 2012 13:08:46 PST Received: by mail-vx0-f177.google.com with SMTP id f13so4776275vcb.36 for ; Wed, 07 Mar 2012 13:08:45 -0800 (PST) Received: by 10.52.68.241 with SMTP id z17mr5635654vdt.97.1331154525370; Wed, 07 Mar 2012 13:08:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.171.172 with HTTP; Wed, 7 Mar 2012 13:08:14 -0800 (PST) In-Reply-To: <4F57B04A.9070509@mitre.org> References: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943663DB078@TK5EX14MBXC283.redmond.corp.microsoft.com> <1331059528.92345.YahooMailNeo@web31806.mail.mud.yahoo.com> <4F57B04A.9070509@mitre.org> From: Brian Campbell Date: Wed, 7 Mar 2012 14:08:14 -0700 Message-ID: To: Justin Richer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnI18+eumKQ/Xq7q81l/aNqly9SR9Apc+RSJhvZ8qzYwxQuHB8+OVvyL6bu79sGMdHApCtO Cc: oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 21:08:47 -0000 Yeah, it is case insensitive. I just went with the upper case B because that's how it was written in =A75.1.1 of draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**. Either one would be fine. I agree that an example response from the token endpoint would be worthwhile. Something like the following might help tie together with the Authorization header example (proposed earlier). It could maybe be worked in near the top of =A72? HTTP/1.1 200 OK Content-Type: application/json;charset=3DUTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"vF_9.5dCf-t4.qbcmT_k1b", "token_type":"example", "expires_in":3600, "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA", } It'd probably make sense to change the examples in the body =A72.2*** and query =A72.3**** to use the same access token value too. * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1 ** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1 *** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2 **** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3 On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer wrote: > Makes sense to me, except that I think the token_type value is typically > lowercase "bearer", though it's defined to be case insensitive in > Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value= of > this field for the Bearer token type ever got defined anywhere. Section 7= .1 > references the bearer spec as defining the value of the "token_type" > parameter, and passes its example as if by reference. Would be worthwhile > giving an example of a token endpoint response, such as what's found in > OAuth-v2-23 section 5.1. > > =A0-- Justin > > > On 03/07/2012 12:16 PM, Brian Campbell wrote: >> >> I'd like to propose the following changes and additions, derived >> largely from Bill and James suggestions, to >> draft-ietf-oauth-v2-bearer-17. =A0These changes have no normative impact >> and only aim to add additional clarity and explanation the workings >> and implications of the current spec. =A0I'm definitely open to changes >> or improvements in the wording here (not my strong suit by any means) >> but I think it's important that these general ideas be conveyed in the >> draft. >> >> >> =3D=3D> =A0Insert the following text at the beginning of =A72: >> >> To make a protected resource request, the client must be in possession >> of a valid bearer token. Typically a bearer token is returned to the >> client as part of an access token response as defined in OAuth 2.0 >> [I-D.ietf-oauth-v2]. When the "token_type" parameter of the access >> token response is "Bearer", the string value of the "access_token" >> parameter becomes the bearer access token used to make protected >> resource requests. >> >> =3D=3D> =A0Change the value of the token in the Authorization header exa= mple to >> this: >> >> Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b >> >> =3D=3D> =A0Insert the following text before the last paragraph of =A72.1= : >> >> Note that the name b64token does not imply base64 encoding but rather >> is the name for an ABNF syntax definition from HTTP/1.1, Part 7 >> [I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token" >> string value from an access token response MUST match the b64token >> ABNF so it can be used with the Bearer HTTP scheme. >> >> >> Thanks, >> Brian >> >> >> >> >> On Tue, Mar 6, 2012 at 11:45 AM, William Mills >> =A0wrote: >>> >>> Yeah, something as simple as, "Note that the name 'b64token' does not >>> imply >>> base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." woul= d >>> do >>> it. >>> >>> -bill >>> >>> ________________________________ >>> From: Brian Campbell >>> To: Mike Jones >>> Cc: oauth >>> Sent: Tuesday, March 6, 2012 8:23 AM >>> >>> Subject: Re: [OAUTH-WG] question about the b64token syntax in >>> draft-ietf-oauth-v2-bearer >>> >>> Thanks Mike, I think changing the example would be helpful. >>> >>> However I think that including some text along the lines of what James >>> suggested would also be very valuable. I agree that the connection >>> between OAuth and Bearer could and should be made more explicit. And >>> that the implications of the b64token syntax, particularly on what AS >>> can use to construct ATs, could/should be made more clear. >>> >>> I can propose some specific text (building on James') if others in the = WG >>> agree? >>> >>> >>> On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones >>> wrote: >>>> >>>> I'm fine with changing the example to make it clearer that b64token >>>> allows >>>> a wider range of characters than just those legal for base64 and >>>> base64url >>>> encodings of data values. >>>> >>>> I'll add it to my to-do list for any additional edits for the Bearer >>>> spec. >>>> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike >>>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>>> Of >>>> Manger, James H >>>> Sent: Monday, March 05, 2012 3:33 PM >>>> To: Brian Campbell; oauth >>>> Subject: Re: [OAUTH-WG] question about the b64token syntax in >>>> draft-ietf-oauth-v2-bearer >>>> >>>> Brian, >>>> >>>>> On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer >>>>> Tokens"* I've encountered several people (including myself) who have >>>>> made the assumption that the name b64token implies that some kind of >>>>> base64 encoding/decoding on the access token is taking place between >>>>> the client and RS. >>>>> >>>>> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**, >>>>> however, I see that b64token is just an ABNF syntax definition >>>>> allowing for characters typically used in base64, base64url, etc.. So >>>>> the b64token doesn't define any encoding or decoding but rather just >>>>> defines what characters can be used in the part of the Authorization >>>>> header that will contain the access token. >>>>> >>>>> Do I read this correctly? >>>> >>>> Yes. >>>> >>>>> If so, I feel like some additional clarifying text in the Bearer >>>>> Tokens draft might help avoid what is (based on my small sample) a >>>>> common point of misunderstanding. >>>> >>>> Changing the example bearer token should be a simple way to avoid some >>>> confusion by showing that it does not have to be base64 encoding. How >>>> about >>>> changing: >>>> =A0Authorization: Bearer vF9dft4qmT >>>> to >>>> =A0Authorization: Bearer vF9.dft4.qmT >>>> >>>> The Bearer spec has lots of (unnecessary) text about OAuth, but doesn'= t >>>> quite manage to be precise about how OAuth and Bearer connect. It coul= d >>>> explicitly state that the string value of the "access_token" member of >>>> an >>>> access token response is the bearer token. The "access_token" string >>>> value >>>> (after unescaping any JSON-escapes) MUST match the b64token ABNF so it >>>> can >>>> be used with the Bearer HTTP scheme. Such text could be put in =A75.1.= 1 >>>> where >>>> the "Bearer" OAuth access token type is defined. >>>> >>>> >>>>> Also, does the use of b64token implicitly limit the allowed character= s >>>>> that an AS can use to construct a bearer access token? >>>> >>>> Yes. >>>> >>>> >>>>> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.= 1 >>>>> ** >>>>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 >>>> >>>> -- >>>> James Manger >>>> _______________________________________________ >>>> 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 > > From paul.madsen@gmail.com Wed Mar 7 13:34:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC0E11E80A1 for ; Wed, 7 Mar 2012 13:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxZ2SfWVtgZM for ; Wed, 7 Mar 2012 13:34:08 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED0011E80AE for ; Wed, 7 Mar 2012 13:34:08 -0800 (PST) Received: by ghbg16 with SMTP id g16so3614174ghb.31 for ; Wed, 07 Mar 2012 13:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=vbEH8QnTqj3ytj/JAdnmUg7FDhdEqO/OwUMiaGJ43QI=; b=mtvMNG352quuTQjKgqbiSyu8ju17m2FFvNBLyIutqBBcuI+BTHuXaEZXjRSdQNf3R4 c/7Ug6geWWVIPtyWI8hDzdAR3dvttqkmImhEtbjmAvszy6DTlO2ji8AbzetLuhd7f8Oh kApK9f0KzjnjTZG6ZRyb5VLmIflH74Opl/T2u3imMBSQo0V4crRWS0h70L+eIs4bPK1e cF+vRNJeaiiA3kzUqfQ8Opiyxo9gXyizCA55UXsvZjY+1ulJfJA+gkjAM8MQ20Ct04n6 5zI274Vl6MlziXcuNGHjHsJGA5x1hLhIhonNVEtHQ+l7z6gJBZM/+tAENsf32a8Xl1Da 6Hjg== Received: by 10.236.185.4 with SMTP id t4mr7297174yhm.129.1331156047933; Wed, 07 Mar 2012 13:34:07 -0800 (PST) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.162.33]) by mx.google.com with ESMTPS id q14sm38874681anj.9.2012.03.07.13.34.05 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 13:34:06 -0800 (PST) Message-ID: <4F57D44E.4030904@gmail.com> Date: Wed, 07 Mar 2012 16:34:06 -0500 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian Campbell References: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943663DB078@TK5EX14MBXC283.redmond.corp.microsoft.com> <1331059528.92345.YahooMailNeo@web31806.mail.mud.yahoo.com> <4F57B04A.9070509@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060705090403070301060908" Cc: oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 21:34:10 -0000 This is a multi-part message in MIME format. --------------060705090403070301060908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit +1 On 3/7/12 4:08 PM, Brian Campbell wrote: > Yeah, it is case insensitive. I just went with the upper case B > because that's how it was written in §5.1.1 of > draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually > defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**. > Either one would be fine. > > I agree that an example response from the token endpoint would be > worthwhile. Something like the following might help tie together with > the Authorization header example (proposed earlier). It could maybe be > worked in near the top of §2? > > HTTP/1.1 200 OK > Content-Type: application/json;charset=UTF-8 > Cache-Control: no-store > Pragma: no-cache > > { > "access_token":"vF_9.5dCf-t4.qbcmT_k1b", > "token_type":"example", > "expires_in":3600, > "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA", > } > > It'd probably make sense to change the examples in the body §2.2*** > and query §2.3**** to use the same access token value too. > > > * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1 > ** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1 > *** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2 > **** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3 > > > On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer wrote: >> Makes sense to me, except that I think the token_type value is typically >> lowercase "bearer", though it's defined to be case insensitive in >> Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value of >> this field for the Bearer token type ever got defined anywhere. Section 7.1 >> references the bearer spec as defining the value of the "token_type" >> parameter, and passes its example as if by reference. Would be worthwhile >> giving an example of a token endpoint response, such as what's found in >> OAuth-v2-23 section 5.1. >> >> -- Justin >> >> >> On 03/07/2012 12:16 PM, Brian Campbell wrote: >>> I'd like to propose the following changes and additions, derived >>> largely from Bill and James suggestions, to >>> draft-ietf-oauth-v2-bearer-17. These changes have no normative impact >>> and only aim to add additional clarity and explanation the workings >>> and implications of the current spec. I'm definitely open to changes >>> or improvements in the wording here (not my strong suit by any means) >>> but I think it's important that these general ideas be conveyed in the >>> draft. >>> >>> >>> ==> Insert the following text at the beginning of §2: >>> >>> To make a protected resource request, the client must be in possession >>> of a valid bearer token. Typically a bearer token is returned to the >>> client as part of an access token response as defined in OAuth 2.0 >>> [I-D.ietf-oauth-v2]. When the "token_type" parameter of the access >>> token response is "Bearer", the string value of the "access_token" >>> parameter becomes the bearer access token used to make protected >>> resource requests. >>> >>> ==> Change the value of the token in the Authorization header example to >>> this: >>> >>> Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b >>> >>> ==> Insert the following text before the last paragraph of §2.1: >>> >>> Note that the name b64token does not imply base64 encoding but rather >>> is the name for an ABNF syntax definition from HTTP/1.1, Part 7 >>> [I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token" >>> string value from an access token response MUST match the b64token >>> ABNF so it can be used with the Bearer HTTP scheme. >>> >>> >>> Thanks, >>> Brian >>> >>> >>> >>> >>> On Tue, Mar 6, 2012 at 11:45 AM, William Mills >>> wrote: >>>> Yeah, something as simple as, "Note that the name 'b64token' does not >>>> imply >>>> base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would >>>> do >>>> it. >>>> >>>> -bill >>>> >>>> ________________________________ >>>> From: Brian Campbell >>>> To: Mike Jones >>>> Cc: oauth >>>> Sent: Tuesday, March 6, 2012 8:23 AM >>>> >>>> Subject: Re: [OAUTH-WG] question about the b64token syntax in >>>> draft-ietf-oauth-v2-bearer >>>> >>>> Thanks Mike, I think changing the example would be helpful. >>>> >>>> However I think that including some text along the lines of what James >>>> suggested would also be very valuable. I agree that the connection >>>> between OAuth and Bearer could and should be made more explicit. And >>>> that the implications of the b64token syntax, particularly on what AS >>>> can use to construct ATs, could/should be made more clear. >>>> >>>> I can propose some specific text (building on James') if others in the WG >>>> agree? >>>> >>>> >>>> On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones >>>> wrote: >>>>> I'm fine with changing the example to make it clearer that b64token >>>>> allows >>>>> a wider range of characters than just those legal for base64 and >>>>> base64url >>>>> encodings of data values. >>>>> >>>>> I'll add it to my to-do list for any additional edits for the Bearer >>>>> spec. >>>>> >>>>> -- Mike >>>>> >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>>>> Of >>>>> Manger, James H >>>>> Sent: Monday, March 05, 2012 3:33 PM >>>>> To: Brian Campbell; oauth >>>>> Subject: Re: [OAUTH-WG] question about the b64token syntax in >>>>> draft-ietf-oauth-v2-bearer >>>>> >>>>> Brian, >>>>> >>>>>> On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer >>>>>> Tokens"* I've encountered several people (including myself) who have >>>>>> made the assumption that the name b64token implies that some kind of >>>>>> base64 encoding/decoding on the access token is taking place between >>>>>> the client and RS. >>>>>> >>>>>> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**, >>>>>> however, I see that b64token is just an ABNF syntax definition >>>>>> allowing for characters typically used in base64, base64url, etc.. So >>>>>> the b64token doesn't define any encoding or decoding but rather just >>>>>> defines what characters can be used in the part of the Authorization >>>>>> header that will contain the access token. >>>>>> >>>>>> Do I read this correctly? >>>>> Yes. >>>>> >>>>>> If so, I feel like some additional clarifying text in the Bearer >>>>>> Tokens draft might help avoid what is (based on my small sample) a >>>>>> common point of misunderstanding. >>>>> Changing the example bearer token should be a simple way to avoid some >>>>> confusion by showing that it does not have to be base64 encoding. How >>>>> about >>>>> changing: >>>>> Authorization: Bearer vF9dft4qmT >>>>> to >>>>> Authorization: Bearer vF9.dft4.qmT >>>>> >>>>> The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't >>>>> quite manage to be precise about how OAuth and Bearer connect. It could >>>>> explicitly state that the string value of the "access_token" member of >>>>> an >>>>> access token response is the bearer token. The "access_token" string >>>>> value >>>>> (after unescaping any JSON-escapes) MUST match the b64token ABNF so it >>>>> can >>>>> be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 >>>>> where >>>>> the "Bearer" OAuth access token type is defined. >>>>> >>>>> >>>>>> Also, does the use of b64token implicitly limit the allowed characters >>>>>> that an AS can use to construct a bearer access token? >>>>> Yes. >>>>> >>>>> >>>>>> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 >>>>>> ** >>>>>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 >>>>> -- >>>>> James Manger >>>>> _______________________________________________ >>>>> 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 --------------060705090403070301060908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

On 3/7/12 4:08 PM, Brian Campbell wrote: 
Yeah, it is case insensitive. I just went with the upper case B
because that's how it was written in §5.1.1 of
draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually
defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.
Either one would be fine.

I agree that an example response from the token endpoint would be
worthwhile.  Something like the following might help tie together with
the Authorization header example (proposed earlier). It could maybe be
worked in near the top of §2?

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"vF_9.5dCf-t4.qbcmT_k1b",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA",
     }

It'd probably make sense to change the examples in the body §2.2***
and query §2.3**** to use the same access token value too.


* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1
** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1
*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2
**** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3


On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer <jricher@mitre.org> wrote:

Makes sense to me, except that I think the token_type value is typically
lowercase "bearer", though it's defined to be case insensitive in
Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value of
this field for the Bearer token type ever got defined anywhere. Section 7.1
references the bearer spec as defining the value of the "token_type"
parameter, and passes its example as if by reference. Would be worthwhile
giving an example of a token endpoint response, such as what's found in
OAuth-v2-23 section 5.1.

 -- Justin


On 03/07/2012 12:16 PM, Brian Campbell wrote:

I'd like to propose the following changes and additions, derived
largely from Bill and James suggestions, to
draft-ietf-oauth-v2-bearer-17.  These changes have no normative impact
and only aim to add additional clarity and explanation the workings
and implications of the current spec.  I'm definitely open to changes
or improvements in the wording here (not my strong suit by any means)
but I think it's important that these general ideas be conveyed in the
draft.


==>  Insert the following text at the beginning of §2:

To make a protected resource request, the client must be in possession
of a valid bearer token. Typically a bearer token is returned to the
client as part of an access token response as defined in OAuth 2.0
[I-D.ietf-oauth-v2]. When the "token_type" parameter of the access
token response is "Bearer", the string value of the "access_token"
parameter becomes the bearer access token used to make protected
resource requests.

==>  Change the value of the token in the Authorization header example to
this:

Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b

==>  Insert the following text before the last paragraph of §2.1:

Note that the name b64token does not imply base64 encoding but rather
is the name for an ABNF syntax definition from HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"
string value from an access token response MUST match the b64token
ABNF so it can be used with the Bearer HTTP scheme.


Thanks,
Brian




On Tue, Mar 6, 2012 at 11:45 AM, William Mills<wmills@yahoo-inc.com>
 wrote:

Yeah, something as simple as, "Note that the name 'b64token' does not
imply
base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would
do
it.

-bill

________________________________
From: Brian Campbell<bcampbell@pingidentity.com>
To: Mike Jones<Michael.Jones@microsoft.com>
Cc: oauth<oauth@ietf.org>
Sent: Tuesday, March 6, 2012 8:23 AM

Subject: Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer

Thanks Mike, I think changing the example would be helpful.

However I think that including some text along the lines of what James
suggested would also be very valuable. I agree that the connection
between OAuth and Bearer could and should be made more explicit. And
that the implications of the b64token syntax, particularly on what AS
can use to construct ATs, could/should be made more clear.

I can propose some specific text (building on James') if others in the WG
agree?


On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones<Michael.Jones@microsoft.com>
wrote:

I'm fine with changing the example to make it clearer that b64token
allows
a wider range of characters than just those legal for base64 and
base64url
encodings of data values.

I'll add it to my to-do list for any additional edits for the Bearer
spec.

                               -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of
Manger, James H
Sent: Monday, March 05, 2012 3:33 PM
To: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer

Brian,


On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
Tokens"* I've encountered several people (including myself) who have
made the assumption that the name b64token implies that some kind of
base64 encoding/decoding on the access token is taking place between
the client and RS.

Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,
however, I see that b64token is just an ABNF syntax definition
allowing for characters typically used in base64, base64url, etc.. So
the b64token doesn't define any encoding or decoding but rather just
defines what characters can be used in the part of the Authorization
header that will contain the access token.

Do I read this correctly?

Yes.


If so, I feel like some additional clarifying text in the Bearer
Tokens draft might help avoid what is (based on my small sample) a
common point of misunderstanding.

Changing the example bearer token should be a simple way to avoid some
confusion by showing that it does not have to be base64 encoding. How
about
changing:
 Authorization: Bearer vF9dft4qmT
to
 Authorization: Bearer vF9.dft4.qmT

The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't
quite manage to be precise about how OAuth and Bearer connect. It could
explicitly state that the string value of the "access_token" member of
an
access token response is the bearer token. The "access_token" string
value
(after unescaping any JSON-escapes) MUST match the b64token ABNF so it
can
be used with the Bearer HTTP scheme. Such text could be put in §5.1.1
where
the "Bearer" OAuth access token type is defined.



Also, does the use of b64token implicitly limit the allowed characters
that an AS can use to construct a bearer access token?

Yes.



* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1
**
http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1

--
James Manger
_______________________________________________
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
--------------060705090403070301060908-- From eran@hueniverse.com Wed Mar 7 15:43:01 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DAC21E800C; Wed, 7 Mar 2012 15:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKYsx96AU1n8; Wed, 7 Mar 2012 15:43:00 -0800 (PST) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id F1B9111E8072; Wed, 7 Mar 2012 15:42:59 -0800 (PST) Received: from P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id iniz1i0A70U5vnL01nizmv; Wed, 07 Mar 2012 16:42:59 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Mar 2012 16:42:57 -0700 From: Eran Hammer To: "Henry S. Thompson" , Justin Richer Date: Wed, 7 Mar 2012 16:42:50 -0700 Thread-Topic: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 Thread-Index: AczrQyWuo/9gAw6OQ5yDyRn3Fjfr8gReLuwA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: 90C41DD21FB7C64BB94121FBBC2E723453AADDD2D4@P3PW5EX1MB01.EX1.SECURESERVER.NET, f5bfwemh7pe.fsf@calexico.inf.ed.ac.uk In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dr@fb.com" , "apps-discuss@ietf.org" , "barryleiba@gmail.com" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 23:43:01 -0000 > -----Original Message----- > From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] > Sent: Tuesday, February 14, 2012 9:07 AM > >> 11 It seems at best old-fashioned that the designer of a new access > >> token type, parameter, endpoint response type or extension error has > >> no better tool available than Google to help him/her discover whether > >> the name they have in mind is in use already. The same is true under > >> the proposed approach for any developer trying to determine what they > >> can use or must support. Is there some reason that mandated URI > >> templates, after the fashion of >=20 > >> http://www.iana.org/assignments/media-types/text/ >=20 > >> are not mandated for the registries, e.g. >=20 > >> http://www.iana.org/assignments/access-token-types/bearer >=20 > >> ? If there is a good reason, please use it to at least explicitly > >> acknowledge and justify the basis for failing to provide a way for > >> users and developers to use the "follow your nose" strategy > >> [1]. If there is no good reason, please include the appropriate > >> language to require something along the lines suggested above. If > >> you need a model, see [2]. >=20 > > I'm confused - is this a request to use a full URI for all extension > > values? I thought the purpose of a registry was to deconflict the > > short names, and that URIs could be used for anything else. >=20 > No, I appreciate that you want to use registered short names in the proto= col, > that's just fine. My problem is that you have left users, developers etc= . with > no way to discover what shortnames have been registered short of a non- > trivial and error-prone informal search effort. >=20 > What I'm asking for is support for probe URI prefixes for each family of > shortnames. So, just as today I use "text/n3" as the media type for my > Notation3 documents, I can check that this is a registered media type by > attempting to retrieve >=20 > http://www.iana.org/assignments/media-types/text/n3 >=20 > and I can see all the registered text types by retrieving from >=20 > http://www.iana.org/assignments/media-types/text >=20 > likewise I ought to be able to check e.g. the "bearer" token type by > attempting retrieval from (something along the lines of) >=20 > http://www.iana.org/assignments/access-token-types/bearer >=20 > and I should be able to see all the registered token types by retrieving = from >=20 > http://www.iana.org/assignments/access-token-types >=20 > Hope this clarifies what I meant. >=20 Not sure I understand what you are asking for, but what would the IANA inst= ruction include to support this? EH From barryleiba.mailing.lists@gmail.com Wed Mar 7 15:53:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB2E21F855D; Wed, 7 Mar 2012 15:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gbky3Du-FIU; Wed, 7 Mar 2012 15:53:38 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBD0621F8554; Wed, 7 Mar 2012 15:53:37 -0800 (PST) Received: by vbbez10 with SMTP id ez10so6830820vbb.31 for ; Wed, 07 Mar 2012 15:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EIio68DrxkirPlUhd26SVxEX0V+hi4FE17sVf3B4fz4=; b=r3gvd7wSPRSeSHV13TC5l/zCHtfVnscP34nosJVRsAn7FOjqdY9l0qvLvY10FziqBq MBcPRJ+AlErgI7zehY/A2lxW6YnXMJ3MAGA+gb6vc8WZBe5kE1W9Jk54MHm+LsYrVKl3 TKZZ7+W9waqDmrqD+wLPe0IgTq7cevlZCbdLPxYayUZ5aOrakJpE3MWpXttiJiVxGrMw 0I0GIatE/qfCj0qtjRCXz5HL9QEGmq6AIgm2/QC6SZXBW0NNjN+5KhJXkvudHRK8Wnrl 8gyAHkJHaPy7dm9eDPxI1+D6QrI/Zfr/cF3WyPPzv/E7/GMqnK1QKUG9RXSR/rjX0jtg mcfg== MIME-Version: 1.0 Received: by 10.52.24.233 with SMTP id x9mr6390326vdf.116.1331164417515; Wed, 07 Mar 2012 15:53:37 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.52.161.37 with HTTP; Wed, 7 Mar 2012 15:53:37 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 7 Mar 2012 18:53:37 -0500 X-Google-Sender-Auth: jXIYmhkhSeuRPa1dpkqaxSJgK8Y Message-ID: From: Barry Leiba To: Eran Hammer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Henry S. Thompson" , "apps-discuss@ietf.org" , "dr@fb.com" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 23:53:39 -0000 Henry says... >> No, I appreciate that you want to use registered short names in the prot= ocol, >> that's just fine. =A0My problem is that you have left users, developers = etc. with >> no way to discover what shortnames have been registered short of a non- >> trivial and error-prone informal search effort. >> >> What I'm asking for is support for probe URI prefixes for each family of >> shortnames. =A0So, just as today I use "text/n3" as the media type for m= y >> Notation3 documents, I can check that this is a registered media type by >> attempting to retrieve >> >> =A0http://www.iana.org/assignments/media-types/text/n3 >> >> and I can see all the registered text types by retrieving from >> >> =A0http://www.iana.org/assignments/media-types/text >> >> likewise I ought to be able to check e.g. the "bearer" token type by >> attempting retrieval from (something along the lines of) >> >> =A0http://www.iana.org/assignments/access-token-types/bearer >> >> and I should be able to see all the registered token types by retrieving= from >> >> =A0http://www.iana.org/assignments/access-token-types >> >> Hope this clarifies what I meant. Eran says... > Not sure I understand what you are asking for, but what would the IANA in= struction include to support this? Yeh, I'm not understanding this either. The spec establishes an access-token-type registry, and anyone will be able to look in that registry the same way they look in any other IANA registry, such as media-types. It looks like Henry is asking for this to use some sort of type/subtype mechanism, as media-types does, wherein when a new token type is registered, that registration or subsequent ones can create subtypes of that token type. But it's not clear that such a type/subtype scheme would always apply here, as it does with media types. Some token types will have no subtypes. What makes more sense is for the token types that need to create their own sub-registries to do so. And then those entries will be found from IANA as well -- no error-prone informal search effort should be needed. Or am I missing the same thing Eran is? Barry From eran@hueniverse.com Wed Mar 7 15:58:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E556411E8094 for ; Wed, 7 Mar 2012 15:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4impVra6cLRF for ; Wed, 7 Mar 2012 15:58:17 -0800 (PST) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id CA65211E808C for ; Wed, 7 Mar 2012 15:58:16 -0800 (PST) Received: from P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.47]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id inu91i00j11lQaG01nvoY2; Wed, 07 Mar 2012 16:55:48 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 7 Mar 2012 16:55:32 -0700 From: Eran Hammer To: Roger Crew Date: Wed, 7 Mar 2012 16:55:23 -0700 Thread-Topic: [OAUTH-WG] error codes in 4.1.2.1 and 4.2.2.1 and extension response types (8.4) Thread-Index: Aczl2ilWT6nLyLlSQtCoYNfpPEt95wW42oKQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4078@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20160.24172.942808.563672@hagen.valhalla> <90C41DD21FB7C64BB94121FBBC2E723453AAB964C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20273.36647.811224.493136@hagen.valhalla> In-Reply-To: <20273.36647.811224.493136@hagen.valhalla> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] error codes in 4.1.2.1 and 4.2.2.1 and extension response types (8.4) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 23:58:18 -0000 Added: unsupported parameter value (other than grant type) EH > -----Original Message----- > From: Roger Crew [mailto:crew@cs.stanford.edu] > Sent: Tuesday, February 07, 2012 12:53 PM > To: Eran Hammer > Cc: oauth@ietf.org > Subject: RE: [OAUTH-WG] error codes in 4.1.2.1 and 4.2.2.1 and extension > response types (8.4) >=20 > > > (2) [in 4.2.2.1] If the response_type is provided but unknown, > > > is that an 'invalid_request' (since this is clearly an > > > "unsupported parameter value") or is it an > > > 'unsupported_response_type'? > > > > > > Seems to me it should be the latter. If so, then... > > > ... > > > should the description for 'invalid_request' even be referring t= o > > > "unsupported" values at all? > > > ... > > > Section 5.2 has the same problem w.r.t. 'unsupported_grant_type' > > > > Changed the definition of invalid_request to: > > > > The request is missing a required parameter, includes an invalid > > parameter value, or is otherwise malformed. >=20 > Just noticed in draft 23 that you changed 4.2.2.1 but didn't change 5.2, = which > still refers to "unsupported" parameter values and thus similarly conflic= ts > with the definition of 'unsupported_grant_type'. >=20 >=20 > -- > Roger Crew > crew@cs.stanford.edu From eran@hueniverse.com Wed Mar 7 16:01:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E7A11E809A; Wed, 7 Mar 2012 16:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7waSW-F0lhGY; Wed, 7 Mar 2012 16:01:52 -0800 (PST) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 845FD11E808C; Wed, 7 Mar 2012 16:01:52 -0800 (PST) Received: from P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id io1q1i05F0SoFT401o1sN3; Wed, 07 Mar 2012 17:01:52 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 7 Mar 2012 17:01:51 -0700 From: Eran Hammer To: Songhaibin , Justin Richer Date: Wed, 7 Mar 2012 17:01:43 -0700 Thread-Topic: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 Thread-Index: AczrxK1m0Cmrx5G1TqO2SHCpS5Hjof//wGMA//yqX4D/2ndaEA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4079@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4F3BB6B8.1030501@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-oauth-v2@tools.ietf.org" , "tsv-ads@tools.ietf.org" , "tsv-dir@ietf.org" , "oauth@ietf.org" , Martin Stiemerling Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 00:01:53 -0000 > -----Original Message----- > From: Songhaibin [mailto:haibin.song@huawei.com] > Sent: Friday, February 17, 2012 12:53 AM > To: Justin Richer > Cc: tsv-ads@tools.ietf.org; draft-ietf-oauth-v2@tools.ietf.org; Martin > Stiemerling; oauth@ietf.org; tsv-dir@ietf.org > Subject: RE: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 >=20 > Hi Justin, >=20 > Thank you for the clarification. See in line. >=20 > > -----Original Message----- > > From: Justin Richer [mailto:jricher@mitre.org] > > Sent: Wednesday, February 15, 2012 9:44 PM > > To: Songhaibin > > Cc: tsv-ads@tools.ietf.org; draft-ietf-oauth-v2@tools.ietf.org; Martin > > Stiemerling; oauth@ietf.org; tsv-dir@ietf.org > > Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 > > > > On 02/15/2012 04:33 AM, Songhaibin wrote: > > > I've reviewed this document as part of the transport area > > > directorate's ongoing > > effort to review key IETF documents. These comments were written > > primarily for the transport area directors, but are copied to the > > document's authors for their information and to allow them to address > > any issues raised. The authors should consider this review together wit= h > any other last-call comments they receive. > > Please always CC tsv-dir@ietf.org if you reply to or forward this revie= w. > > > > > > First, I should apologize for the delay in this review, I should > > > have finished it two > > days ago. I have some common security knowledge but not an expert. > > > > > > Summary > > > > > > This draft is basically ready for publication, but has nits that > > > should be fixed > > before publication. > > > > > > General issues need discussion: > > > > > > 1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: > > > resource owner > > password credentials, and client credentials. These two have the same > > flow and many in common, and they are significantly different than the > > authorization code grant type and implicit grant type described in > > previous sections. And in section 1.3.4, it also says " Client > > credentials are used as an authorization grant typically when the > > client is acting on its own behalf (the client is also the resource > > owner),...". Is it better to combine these two grant types as one "clie= nt > credentials" grant type where the client can be the resource owner? > > > > No, they are quite distinct -- It all comes down to what you're > > authenticating. The Resource Owner Password Credentials flow *also* > > includes client credentials which are distinct from the resource > > owner's own credentials. The client's credentials are going to be the > > same for a given client across many different users, while the > > Resource Owner's credentials are going to be different across > > different users, but the same across different clients (for the same > > resource owner). In most flows, the client's credentials identify just > > the client, and the resource owner is identified through some other > > means (a direct password, a redirected login to the authz endpoint). > > In the Client Credentials flow, the client's credentials are the only o= nes that > you have. > > >=20 > Okay, in the Resource Owner Password Credentials flow, it adds client > credentials, but any client who was issued credentials from the authoriza= tion > server can pass. How much security does the client credential in this flo= w > add? It can allow the server to enforce policies, but more importantly, client a= uthentication is part of every access token request make to this endpoint a= s part of the overall architecture. > > > 2. Two concepts confused me in section 2.4, I don't know if I am the > > > only person > > who is confusing here. One is user-agent-based application and another > > is native application, why are they executed on the device used by the > > resource owner? I think they can run on any device used by resource > > consumer instead of resource owner. Resource owner is only used to gran= t > access to resources. > > > > OAuth's main 3-legged pattern allows what's called "Alice-to-Alice > > sharing", in that the Client is consuming on behalf of the resource > > owner. In cases where you have an in-user-agent app or a native app, > > the end user (resource owner) is going to be the one running it, and > > the one authorizing it. > > >=20 > Yes, I understand that. But the document seems like resource owner is the > "only" one who can run the UA app or native app? Or I missed something? It is the only one. Only the resource owner can grant access. EH >=20 > Thanks, > -Haibin >=20 > > > > Thanks for your feedback, and I hope this can help clear up the intent > > of the working group here. If you can suggest language that will > > solidify these points further, it can help make sure this doesn't > > further confuse people. > > > > -- Justin From eran@hueniverse.com Wed Mar 7 16:22:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CBC11E80A1 for ; Wed, 7 Mar 2012 16:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVVaqoR0zpYg for ; Wed, 7 Mar 2012 16:22:23 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D565D11E8094 for ; Wed, 7 Mar 2012 16:22:23 -0800 (PST) Received: (qmail 17659 invoked from network); 8 Mar 2012 00:22:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 00:22:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 7 Mar 2012 17:22:07 -0700 From: Eran Hammer To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Wed, 7 Mar 2012 17:21:58 -0700 Thread-Topic: [OAUTH-WG] How an AS can validate the state parameter? Thread-Index: AczvHDhFISNzBSQ3RAC7Me1xuWvrhQNpTaxQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD407E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407EP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] How an AS can validate the state parameter? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 00:22:24 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407EP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can't validate, but can sanitize. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Sunday, February 19, 2012 7:36 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] How an AS can validate the state parameter? >From section 10.14: (draft 23) The Authorization server and client MUST validate and sanitize any value re= ceived, and in particular, the value of the state and redirect_uri paramete= rs. Elsewhere in the spec the AS is instructed to exactly preserve the state an= d to consider it an opaque value. How then, can an AS validate and sanitiz= e the state parameter? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407EP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can’= ;t validate, but can sanitize.

 

EH<= /span>

 

From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Andrew Arnott
Sent: Sunday, = February 19, 2012 7:36 AM
To: OAuth WG (oauth@ietf.org)
Sub= ject: [OAUTH-WG] How an AS can validate the state parameter?=

 

From section 10.14: (draft 23)

The= Authorization server and client MUST validate and sanitize any value recei= ved, and in particular, the value of the state and red= irect_uri parameters.

 

Elsewhere in the = spec the AS is instructed to exactly preserve the state and to consider it = an opaque value.  How then, can an AS validate and sanitize the state = parameter?


--=

Andrew Arnott
"I [ma= y] not agree with what you have to say, but I'll defend to the death your r= ight to say it." - S. G. Tallentyre

= --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407EP3PW5EX1MB01E_-- From eran@hueniverse.com Wed Mar 7 16:41:03 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6579111E8085 for ; Wed, 7 Mar 2012 16:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLCOS3DI+xEs for ; Wed, 7 Mar 2012 16:41:02 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id BA7D711E8080 for ; Wed, 7 Mar 2012 16:41:02 -0800 (PST) Received: (qmail 4691 invoked from network); 8 Mar 2012 00:41:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 00:41:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 7 Mar 2012 17:40:32 -0700 From: Eran Hammer To: Buhake Sindi Date: Wed, 7 Mar 2012 17:40:24 -0700 Thread-Topic: [OAUTH-WG] error response for invalid refresh token Thread-Index: AczwrRc850XNpSkXRK+RkIDjBTsUCwMFu2hw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD407F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407FP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] error response for invalid refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 00:41:03 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407FP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW52YWxpZF9ncmFuZCBpcyBjb3JyZWN0Lg0KDQpFSA0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJ1aGFr ZSBTaW5kaQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjEsIDIwMTIgNzoxNiBBTQ0KVG86IFBl dGVyIEJyaW5kaXNpDQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IGVycm9yIHJlc3BvbnNlIGZvciBpbnZhbGlkIHJlZnJlc2ggdG9rZW4NCg0KSGkNCmludmFsaWRf Z3JhbnQNCg0KVGhlIHByb3ZpZGVkIGF1dGhvcml6YXRpb24gZ3JhbnQgKGUuZy4gYXV0aG9yaXph dGlvbiBjb2RlLA0KcmVzb3VyY2Ugb3duZXIgY3JlZGVudGlhbHMpIGlzIGludmFsaWQsIGV4cGly ZWQsIHJldm9rZWQsIGRvZXMNCm5vdCBtYXRjaCB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzZWQNCg0K SSB3b3VsZCB0aGluayB0aGF0IHRoZSByZWZyZXNoX3Rva2VuIGlzIGFuIGF1dGhvcml6YXRpb24g Y29kZSB0aGF0IG5lZWRzIHJlZnJlc2hpbmcsIHNvIHRoaXMgd291bGQgYmUgdmFsaWQuDQoNCg0K T24gMjEgRmVicnVhcnkgMjAxMiAxNTozMywgUGV0ZXIgQnJpbmRpc2kgPHBldGVyLmJyaW5kaXNp QGdtYWlsLmNvbTxtYWlsdG86cGV0ZXIuYnJpbmRpc2lAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBh bGwsDQoNCkkgYW0gY3VycmVudGx5IGltcGxlbWVudGluZyB2ZXJzaW9uIDIzIG9mIHRoZSBvYXV0 aDIgc3BlYywgYW5kIEkgY2FtZSBhY3Jvc3MgYSBiaXQgb2YgYW1iaWd1aXR5LiBXaGF0IGlzIHRo ZSBhcHByb3ByaWF0ZSBlcnJvciBjb2RlIGZvciBhbiBpbnZhbGlkIHJlZnJlc2ggdG9rZW4/IEkg YW0gdW5zdXJlIHdoZXRoZXIgaXQgc2hvdWxkIGJlICdpbnZhbGlkX2dyYW50JyBvciAnaW52YWxp ZF9yZXF1ZXN0Jy4gTmVpdGhlciBzZWVtcyAxMDAlIGNsZWFyLg0KDQpUaGFua3MgaW4gYWR2YW5j ZSENCg0KQmVzdCwNClBldGVyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0K --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407FP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5JbnZhbGlkX2dyYW5kIGlzIGNvcnJlY3QuPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5F SDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+QnVoYWtlIFNp bmRpPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAyMSwgMjAxMiA3OjE2IEFNPGJy PjxiPlRvOjwvYj4gUGV0ZXIgQnJpbmRpc2k8YnI+PGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxi cj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gZXJyb3IgcmVzcG9uc2UgZm9yIGludmFs aWQgcmVmcmVzaCB0b2tlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+SGk8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+aW52YWxpZF9ncmFudDxvOnA+PC9vOnA+PC9wPjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbic+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp bic+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZSBwcm92aWRlZCBhdXRob3JpemF0aW9uIGdyYW50IChl LmcuIGF1dGhvcml6YXRpb24gY29kZSw8YnI+cmVzb3VyY2Ugb3duZXIgY3JlZGVudGlhbHMpIGlz IGludmFsaWQsIGV4cGlyZWQsIHJldm9rZWQsIGRvZXM8YnI+bm90IG1hdGNoIHRoZSByZWRpcmVj dGlvbiBVUkkgdXNlZDxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+SSB3b3VsZCB0aGluayB0aGF0IHRo ZSByZWZyZXNoX3Rva2VuIGlzIGFuIGF1dGhvcml6YXRpb24gY29kZSB0aGF0IG5lZWRzIHJlZnJl c2hpbmcsIHNvIHRoaXMgd291bGQgYmUgdmFsaWQuPGJyPjxicj48YnI+PG86cD48L286cD48L3A+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gMjEgRmVicnVhcnkgMjAxMiAxNTozMywgUGV0ZXIg QnJpbmRpc2kgJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRlci5icmluZGlzaUBnbWFpbC5jb20iPnBl dGVyLmJyaW5kaXNpQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD5IaSBhbGwsPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBh bSBjdXJyZW50bHkgaW1wbGVtZW50aW5nIHZlcnNpb24gMjMgb2YgdGhlIG9hdXRoMiBzcGVjLCBh bmQgSSBjYW1lIGFjcm9zcyBhIGJpdCBvZiBhbWJpZ3VpdHkuIFdoYXQgaXMgdGhlIGFwcHJvcHJp YXRlIGVycm9yIGNvZGUgZm9yIGFuIGludmFsaWQgcmVmcmVzaCB0b2tlbj8gSSBhbSB1bnN1cmUg d2hldGhlciBpdCBzaG91bGQgYmUgJ2ludmFsaWRfZ3JhbnQnIG9yICdpbnZhbGlkX3JlcXVlc3Qn LiBOZWl0aGVyIHNlZW1zIDEwMCUgY2xlYXIuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+VGhhbmtzIGluIGFkdmFuY2UhPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+QmVzdCw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5QZXRlcjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWJvdHRvbToxMi4wcHQnPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407FP3PW5EX1MB01E_-- From eran@hueniverse.com Wed Mar 7 17:18:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1C21F85AD for ; Wed, 7 Mar 2012 17:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2q3fLIXryUq for ; Wed, 7 Mar 2012 17:18:08 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 763CE21E800C for ; Wed, 7 Mar 2012 17:18:08 -0800 (PST) Received: (qmail 11759 invoked from network); 7 Mar 2012 23:17:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Mar 2012 23:16:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Mar 2012 15:57:33 -0700 From: Eran Hammer To: John Bradley , Peter Saint-Andre Date: Wed, 7 Mar 2012 15:57:25 -0700 Thread-Topic: [OAUTH-WG] Server cret verification in 10.9 Thread-Index: Acza5vDuN+5YHYebS8uzmfI1xS/n7QhzrIHw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4068@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453AAB9653D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F1E2639.10902@stpeter.im> <494090F8-EEC5-4156-B372-D06745E01552@ve7jtb.com> In-Reply-To: <494090F8-EEC5-4156-B372-D06745E01552@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Server cret verification in 10.9 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 01:18:09 -0000 New text: In order to prevent man-in-the-middle attacks, the authorization = server MUST implement and require TLS with server authentication as defined by for any request sent to the authorization and token endpoints. The cl= ient MUST validate the authorization server's TLS certificate as defined by , and in accordance with its requirements for server identity authenticati= on. EH > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Tuesday, January 24, 2012 2:24 PM > To: Peter Saint-Andre > Cc: Eran Hammer; OAuth WG > Subject: Re: [OAUTH-WG] Server cret verification in 10.9 >=20 > We added the reference to RFC6125 in openID Connect. >=20 > The Client MUST perform a TLS/SSL server certificate check, per > RFC 6125. >=20 > We wanted to be more general to allow for non http bindings in the future= . >=20 > If you don't do it in core, every spec that references core will probably= have > to add it. >=20 > John B. >=20 >=20 > On 2012-01-24, at 12:32 AM, Peter Saint-Andre wrote: >=20 > > On 1/20/12 4:46 PM, Eran Hammer wrote: > >> Stephen asked: > >> > >>> (13) 10.9 says that the client MUST verify the server's cert which is > >>> fine. However, does that need a reference to e.g. rfc 6125? Also, do > >>> you want to be explicit here about the TLS server cert and thereby > >>> possibly rule out using DANE with the non PKI options that that WG > >>> (may) produce? > >> > >> Can someone help with this? I don't know enough to address. > > > > The OAuth core spec currently says: > > > > The client MUST validate the authorization server's > > TLS certificate in accordance with its requirements > > for server identity authentication. > > > > RFC 2818 has guidance about endpoint identity, in Section 3.1: > > > > http://tools.ietf.org/html/rfc2818#section-3.1 > > > > RFC 6125 attempts to generalize the guidance from RFC 2818 and many > > similar specs for use by new application protocols. Given that OAuth as > > defined by the core spec runs over HTTP, I think referencing RFC 2818 > > would make sense. So something like: > > > > The client MUST validate the authorization server's > > TLS certificate in accordance with the rules for > > server identity authentication provided in Section 3.1 > > of [RFC2818]. > > > > Peter > > > > -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Mar 7 17:24:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402CA21F842D for ; Wed, 7 Mar 2012 17:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtM2vT-O5bwK for ; Wed, 7 Mar 2012 17:24:44 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 4469F21E8025 for ; Wed, 7 Mar 2012 17:24:42 -0800 (PST) Received: (qmail 32527 invoked from network); 8 Mar 2012 00:16:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 00:16:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 7 Mar 2012 17:16:03 -0700 From: Eran Hammer To: Songhaibin , "tsv-ads@tools.ietf.org" , "draft-ietf-oauth-v2@tools.ietf.org" Date: Wed, 7 Mar 2012 17:15:56 -0700 Thread-Topic: tsv-dir review of draft-ietf-oauth-v2-23 Thread-Index: AczrxK1m0Cmrx5G1TqO2SHCpS5HjoQQ+W/QA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD407B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Martin Stiemerling , "oauth@ietf.org" , "tsv-dir@ietf.org" Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 01:24:44 -0000 Thanks Haibin. > -----Original Message----- > From: Songhaibin [mailto:haibin.song@huawei.com] > Sent: Wednesday, February 15, 2012 1:33 AM > Nits: > 1. Section 3.1, paragraph 4, the last sentence is confusing, is it the > authorization server who sends the request to the authorization endpoint? > Or is it the resource owner? The client. Added clarification in section 3. > 2. Section 3.1.1, paragraph 3, "...where the order of values does not mat= ter.." > I think a little clarification on the reason for this would be better for= people > like me. I don't think we need to explain it, but it's to meet typical developers' e= xpectations. > 3. Section 3.2, paragraph 4, the last sentence is confusing, is it the > authorization server who sends request to the token endpoint? Same as #1. > 4. Section 10.12, paragraph 4, should the terminology "end-user" be chang= ed > to "resource owner"? There are same issues in other places of this > document. Changed some. Clarified end-user in the intro. > 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent > to.../ When the authorization code request is sent to... Not sure what you mean. EH From haibin.song@huawei.com Wed Mar 7 18:10:57 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8960321E805B; Wed, 7 Mar 2012 18:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZCD7U4WtD-t; Wed, 7 Mar 2012 18:10:53 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C8D7721E8045; Wed, 7 Mar 2012 18:10:52 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J00362NE430@szxga04-in.huawei.com>; Thu, 08 Mar 2012 10:10:52 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J006TONE0C4@szxga04-in.huawei.com>; Thu, 08 Mar 2012 10:10:51 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHR01602; Thu, 08 Mar 2012 10:10:11 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 08 Mar 2012 10:10:02 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 08 Mar 2012 10:10:30 +0800 Date: Thu, 08 Mar 2012 02:10:39 +0000 From: Songhaibin In-reply-to: <90C41DD21FB7C64BB94121FBBC2E723453AFCD407B@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Originating-IP: [10.138.41.129] To: Eran Hammer , "tsv-ads@tools.ietf.org" , "draft-ietf-oauth-v2@tools.ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: tsv-dir review of draft-ietf-oauth-v2-23 Thread-index: AczrxK1m0Cmrx5G1TqO2SHCpS5HjoQQ+W/QAAASPNnA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD407B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Cc: Martin Stiemerling , "oauth@ietf.org" , "tsv-dir@ietf.org" Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:10:57 -0000 > > 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent > > to.../ When the authorization code request is sent to... > > Not sure what you mean. I mean you may have to change "the attacker is sent to..." to "the authorization code is sent to...". BR, -Haibin > -----Original Message----- > From: Eran Hammer [mailto:eran@hueniverse.com] > Sent: Thursday, March 08, 2012 8:16 AM > To: Songhaibin; tsv-ads@tools.ietf.org; draft-ietf-oauth-v2@tools.ietf.org > Cc: tsv-dir@ietf.org; oauth@ietf.org; Martin Stiemerling > Subject: RE: tsv-dir review of draft-ietf-oauth-v2-23 > > Thanks Haibin. > > > -----Original Message----- > > From: Songhaibin [mailto:haibin.song@huawei.com] > > Sent: Wednesday, February 15, 2012 1:33 AM > > > Nits: > > 1. Section 3.1, paragraph 4, the last sentence is confusing, is it the > > authorization server who sends the request to the authorization endpoint? > > Or is it the resource owner? > > The client. Added clarification in section 3. > > > 2. Section 3.1.1, paragraph 3, "...where the order of values does not matter.." > > I think a little clarification on the reason for this would be better for people > > like me. > > I don't think we need to explain it, but it's to meet typical developers' > expectations. > > > 3. Section 3.2, paragraph 4, the last sentence is confusing, is it the > > authorization server who sends request to the token endpoint? > > Same as #1. > > > 4. Section 10.12, paragraph 4, should the terminology "end-user" be changed > > to "resource owner"? There are same issues in other places of this > > document. > > Changed some. Clarified end-user in the intro. > > > 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent > > to.../ When the authorization code request is sent to... > > Not sure what you mean. > > EH > From eran@hueniverse.com Wed Mar 7 18:12:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B3121E8054 for ; Wed, 7 Mar 2012 18:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JUVzsiwtlow for ; Wed, 7 Mar 2012 18:12:53 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id CA9D921E8045 for ; Wed, 7 Mar 2012 18:12:53 -0800 (PST) Received: (qmail 10098 invoked from network); 8 Mar 2012 00:20:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 00:20:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 7 Mar 2012 17:20:33 -0700 From: Eran Hammer To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Wed, 7 Mar 2012 17:20:26 -0700 Thread-Topic: [OAUTH-WG] Section 10.3 client advice inapplicable? Thread-Index: AczvGGcPVtoM77e8RR2IhTr1/EDQsANqNVVg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD407D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Section 10.3 client advice inapplicable? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:12:54 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Removed 'and lifetime'. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Sunday, February 19, 2012 7:09 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Section 10.3 client advice inapplicable? >From draft 23, section 10.3: The client SHOULD request access tokens with the minimal scope and lifetime= necessary. The authorization server SHOULD take the client identity into a= ccount when choosing how to honor the requested scope and lifetime, and MAY= issue an access token with a less rights than requested. I can't find the part in the spec where the client can request access token= s in such a way as to influence the lifetime. Why is the client then being= advised in the above section to minimize the lifetime of the access tokens= it asks for? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Removed &= #8216;and lifetime’.

 

EH

 

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

From: oauth-bounces@ietf.org [mailto:oauth-bounc= es@ietf.org] On Behalf Of Andrew Arnott
Sent: Sunday, Febr= uary 19, 2012 7:09 AM
To: OAuth WG (oauth@ietf.org)
Subject= : [OAUTH-WG] Section 10.3 client advice inapplicable?=

 

From draft 23, section 10.3:

The client SHOULD request access tokens with the minimal scope and lif= etime necessary. The authorization server SHOULD take the client identity i= nto account when choosing how to honor the requested scope and lifetime, an= d MAY issue an access token with a less rights than requested.

 

I can't find the part in the spec where the client can reques= t access tokens in such a way as to influence the lifetime.  Why is th= e client then being advised in the above section to minimize the lifetime o= f the access tokens it asks for?

<= br clear=3Dall>--
Andrew Arnott
"I [may] not agree with what you= have to say, but I'll defend to the death your right to say it." - S.= G. Tallentyre

= --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407DP3PW5EX1MB01E_-- From eran@hueniverse.com Wed Mar 7 18:12:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B9321E8061 for ; Wed, 7 Mar 2012 18:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wQw66JDuyCh for ; Wed, 7 Mar 2012 18:12:54 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 09E1E21E8053 for ; Wed, 7 Mar 2012 18:12:54 -0800 (PST) Received: (qmail 4788 invoked from network); 8 Mar 2012 00:18:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 00:18:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 7 Mar 2012 17:17:39 -0700 From: Eran Hammer To: John Bradley Date: Wed, 7 Mar 2012 17:17:31 -0700 Thread-Topic: [OAUTH-WG] Ignoring unrecognized request parameters Thread-Index: AczulspwqLx1aonfQmGsGNazNyaP+gOKfa9A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD407C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407CP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:12:57 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Our "mustUnderstand" is extension grant types. Define a new one and everyth= ing will break if the server doesn't understand something as defined by the= new grant type spec. EH From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Saturday, February 18, 2012 3:41 PM To: Eran Hammer Cc: William Mills; oauth@ietf.org Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters It is a general problem with security protocols like SOAP, SAML, X.509. Sometimes when you define an extension you want to be certain that the Auth= orization server understands it, or you want an error. As an example if someone did a authentication context extension (Not propos= ing it just an example). They would perhaps rather have an error if the A= uthorization server did not understand the extension, they could then retr= y without the extension if that worked for them. This is generally dealt with by marking something as mustUnderstand in SOAP or critical i= n x.509. Without that functionality (I am not asking to add it) it may be reasonable= for some Authorization servers to return an error if they do not completel= y understand what is being sent to them. One school of thought feels that anything you don't understand in a message= could be an indication of a problem or tampering. I am sympathetic to the Forward compatibility argument, however without so= me sort of mustUnderstand semantics it is not going to always work. One thing that might help is an error message to indicate that it is being = rejected due to unknown extensions so a client can retry. John B. On 2012-02-16, at 8:01 PM, Eran Hammer wrote: Can you give an example where an unknown parameter being ignored can lead t= o security issues? EH From: John Bradley > Date: Thu, 16 Feb 2012 11:55:21 -0700 To: William Mills > Cc: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters If you have a generic client that works across multiple Authorization endpo= ints some that have extension X and others not, I can see that having the A= uthorization servers ignore unknown parameters is desirable. However there are some endpoints that are not going to be able to allow unk= nown parameters due to there security policy. They are often a indication= of an attack. If this remains a MUST then some endpoints will have to ignore it, and be n= on compliant. I would be OK with something like "MUST ignore unknown parameters unless th= e endpoint is required to return an error due to local security policy." There is probably no perfect compromise on this one. John B. On 2012-02-16, at 3:32 PM, William Mills wrote: No, this is required for forward compatibility. Implementations that send = extended parameters like capability advertisements (i.e. CAPTCHA support or= something) shoudl not be broken hitting older implementations. ________________________________ From: Mike Jones > To: "oauth@ietf.org" > Sent: Thursday, February 16, 2012 10:16 AM Subject: [OAUTH-WG] Ignoring unrecognized request parameters In core -23, the last paragraph of section 3.1 now says: The authorization server MUST ignore unrecognized request p= arameters. In -22, this said: The authorization server SHOULD ignore unrecognized request= parameters. In a security protocol, it seems unreasonable to require that information b= e ignored. As I see it, it SHOULD be legal to return an error if unrecogni= zed information is received. Why the change? And can we please have it changed back to SHOULD in -24? Thanks, -- Mike _______________________________________________ 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 --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Our ̶= 0;mustUnderstand” is extension grant types. Define a new one and ever= ything will break if the server doesn’t understand something as defin= ed by the new grant type spec.

 

EH<= /span>

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com= ]
Sent: Saturday, February 18, 2012 3:41 PM
To: Eran H= ammer
Cc: William Mills; oauth@ietf.org
Subject: Re: [O= AUTH-WG] Ignoring unrecognized request parameters

 

It i= s a general problem with security protocols like SOAP, SAML, X.509.

 

Sometimes when you define an extension you want to be certain = that the Authorization server understands it,  or you want an error.

 

As an example if someone did a authentication contex= t extension (Not proposing it just an example).   They would perhaps r= ather have an error if the Authorization server did not understand the exte= nsion,  they could then retry without the extension if that worked for= them.

 

<= /div>

This is generally dealt with by marking some= thing as mustUnderstand in SOAP or critical in x.509.=

 

Without that functionality (I am not asking to add it) it may= be reasonable for some Authorization servers to return an error if they do= not completely understand what is being sent to them.

=

 

One school of thought feels that anything you don't understand in a mes= sage could be an indication of a problem or tampering.   

 

I am sympathetic to the Forward compatibility argument, &n= bsp;however without some sort of mustUnderstand semantics it is not going t= o always work.

 

One thing that might help is an erro= r message to indicate that it is being rejected due to unknown extensions s= o a client can retry.

&n= bsp;

John B. 

<= /div>

 

 

On 2012-02-16= , at 8:01 PM, Eran Hammer wrote:


Can you give an example where an un= known parameter being ignored can lead to security issues?

 

EH=

 

 

From: John Bradley <ve7jtb@ve7jtb.com>
Date: Thu, 16 Feb 2012 11:= 55:21 -0700
To: William Mills <wmills@yahoo-inc.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Ignoring unre= cognized request parameters

&= nbsp;

If you have a generic client= that works across multiple Authorization endpoints some that have extensio= n X and others not, I can see that having the Authorization servers ignore = unknown parameters is desirable.

&n= bsp;

However there are some endpoints t= hat are not going to be able to allow unknown parameters due to there secur= ity policy.   They are often a indication of an attack.

 

If this remains a MUST then some endpoints will have to ignore it, and be = non compliant.

 

I would be OK with something like "MUST i= gnore unknown parameters unless the endpoint is required to return an error= due to local security policy."

 

There is probably no pe= rfect compromise on this one.

 

John B.

 

&nbs= p;

On 2012-02-16, at 3:32 PM,= William Mills wrote:



No,= this is required for forward compatibility.  Implementations that sen= d extended parameters like capability advertisements (i.e. CAPTCHA support = or something) shoudl not be broken hitting older implementations.

&nb= sp;

From: Mike Jones <Michael.Jones@microsoft.com>
To: "= oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, Feb= ruary 16, 2012 10:16 AM
Subject: [OAUTH-WG] Ignoring unrecognized= request parameters

 

<= p class=3DMsoNormal style=3D'background:white'>= In core -23, the last paragraph of section 3.1 now say= s:

 

=

            &n= bsp;   The authorization server MUST ignore unrecognized request = parameters.

 

In -22, this said:

 

<= span style=3D'color:black'>        =         The authorization server SHOULD = ignore unrecognized request parameters.

&n= bsp;

In a security protocol, it seems unre= asonable to require that information be ignored.  As I see it, it SHOU= LD be legal to return an error if unrecognized information is received.

 

Why t= he change?  And can we please have it changed back to SHOULD in -24?

 

&nb= sp;            =             &nb= sp;            =             &nb= sp;            = Thanks,

     &nb= sp;            =             &nb= sp;            =             &nb= sp;        -- Mike

=

 


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

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

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD407CP3PW5EX1MB01E_-- From rboucher@gmail.com Wed Mar 7 18:14:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757A421E805F for ; Wed, 7 Mar 2012 18:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze+uZGbCqx5h for ; Wed, 7 Mar 2012 18:14:38 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D513921E805C for ; Wed, 7 Mar 2012 18:14:37 -0800 (PST) Received: by iazz13 with SMTP id z13so9282iaz.31 for ; Wed, 07 Mar 2012 18:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; bh=FkkSarRrtZnjGPzilkkwESIIU7atnozh9OWqNtrmWwg=; b=h3g0c9qXAvQSTxm8p46xJwdc0rO9rQZlzf7hTkLphB8IN9X6u+pRboeV86hBp39tqI 1x4x16QRMyE1XIQLI9ZjqpRvbvh42LLVhZDRvE3/UXJvAG6VPyr5J1mhXu/+I2eywKt1 vUJ67Nvk+9WspDIyH4utCtDgHhcD1HQ95Jx2rQywc4bfhPC0pALCuItUohtXIWyyJ9NW nODaWkA5BZGoByU705w7I8BD9oouT63Nx87+y6VliCoQ+Nv4B2n9Cl8QFTs7MFJt067b /6v759HhHm+G8wtlpLYoC3qcC7sP2Y7MPbboMtVsilq0P8+yvVQkkRxNz7/O5Qta3W9Q N1qA== Received: by 10.50.191.233 with SMTP id hb9mr3714623igc.44.1331172877562; Wed, 07 Mar 2012 18:14:37 -0800 (PST) Received: from ip-192-168-1-92.us-west-1.compute.internal (sf-84.stripe.com. [173.247.202.84]) by mx.google.com with ESMTPS id e2sm8936996igp.11.2012.03.07.18.14.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Mar 2012 18:14:36 -0800 (PST) From: Ross Boucher Content-Type: multipart/signed; boundary="Apple-Mail=_42A1F361-752E-4ADF-838E-083603A16B1E"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 7 Mar 2012 18:14:34 -0800 Message-Id: To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [OAUTH-WG] Multiple access tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:14:38 -0000 --Apple-Mail=_42A1F361-752E-4ADF-838E-083603A16B1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The spec doesn't seem to have any recommendations on this point, but = should an OAuth v2 API always return the same access token if the same = client makes multiple requests? Is there any benefit to not generating a = new access token for each request? Similarly, if you do generate new = access tokens (as I am doing now), should you also generate new refresh = tokens? An unrelated question about revoking access tokens when the same = authorization code is used more than once: should refresh tokens also be = revoked? And, if so, should any tokens issued with that refresh token = then also be revoked? It seems simpler (if slightly less correct) to = just revoke all access tokens for that specific client/resource pair in = that case, rather than tracking the ancestry of all tokens. Thanks, Ross= --Apple-Mail=_42A1F361-752E-4ADF-838E-083603A16B1E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKDCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSUwggQNoAMC AQICEHhaMDZMR5ypExZJg/LXXGswDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwNjE3MDAwMDAwWhcNMTIwNjE2MjM1OTU5WjAjMSEwHwYJKoZI hvcNAQkBFhJyYm91Y2hlckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCZZNWQQZ4VOQLdlzFu8WNyc8pv/fKUqWxpx8Dnj/iedgPzNB4tiEhbeeVw3oPnPupOfBclfNM3 uXTT/zzBWn+sayIb2RokjJPoJHJov5ZLzBDcHBRPEmaScjFw1fuoUvTqS2E7RIzLxsqBXD7gPckl /Rq/uABPWD1zwyuhyMJX1h8vyzNwUMMRwL0MaFGxiVURSRvLL3bQlcFCb1WWhJDDQN33VPrFJbJH znXNyadnQCy2bcK4Yme3sh6rDkdSUpMIRGawyjVfpZGG/hc3+MNSVbhLUGeQHCyr42snb0iL3TEx 6sQDYTVT3RgOsatMdHjOy4dafMleQwBds4sagbbVAgMBAAGjggHiMIIB3jAfBgNVHSMEGDAWgBR6 E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUJNsLz5Q4nHALO7c1EeVDF3lL31kwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUF BwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRw Oi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2Rv Y2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYI KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAdBgNVHREEFjAUgRJyYm91Y2hlckBn bWFpbC5jb20wDQYJKoZIhvcNAQEFBQADggEBAGblVXcw0o5MFQdSenk1j7TTcufVTr7GI9gM4//6 lOfTQwEvkD84dZp5As6EKKhmXlhZTM4f+vXL1uUoHyozv5kQja06qGYuPLNhccgo7N3QvIH0CZON 0FUYtfvRVPo4r1UrT9NWQkdgU+Gy1Mom9We7dAhgnY5FYCAOfmA7x3gVOACoA0VormrHMLtEKsn5 CHdMiqO/vr0nuPlmBoABE8L5W5OcoypoO3DP8bvJog6tQ1yG1FUpz+Rzcahkwi/eN+mo8ftAlqPJ qiPOh10grXqtI5+XHPETG8peKsZfW+hRzynfrQkrFZ5sQJ0cBk0lVNXY9dKA9b3ZGsb0IuEuAAUx ggOrMIIDpwIBATCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMT MENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQeFowNkxH nKkTFkmD8tdcazAJBgUrDgMCGgUAoIIB1zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAzMDgwMjE0MzVaMCMGCSqGSIb3DQEJBDEWBBT8uJRQPBVEsZidDLLIbOO0 cBO8aDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhB4WjA2TEecqRMWSYPy11xrMIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQeFowNkxHnKkTFkmD8tdcazANBgkqhkiG9w0BAQEFAASC AQBv6xyKRQaTmmkLz9mCf0Jwfyc8Zx++OQS/+3BeTFxnFYJqWwG68xosYuiP54SdrUNPd5IQjylW 4+2b5V/RwUsk7uMFnuC+7UpUcZUHQ65yb6wy18vwImHiD7w03ZubUt7Ib7b/qsQjBA/8GwK4OWQM wUhpFq5J/EoqYh79kUudAABAMhtuWs/Z/n8I+mXOVHm3BEZQvOGEd9PeTyeD1FzCsHWCUzhohNYL Z+hSDzU/buZ9L53bLpTQx0IjTx4+Wosn53dxJN8xYPCQYiDJSNcII5Mm//55KPp+t3YXOcpibvsf GKAxFC7PPeuG9sZgFVlRQB07VtPnh0pRMEBB7AnNAAAAAAAA --Apple-Mail=_42A1F361-752E-4ADF-838E-083603A16B1E-- From eran@hueniverse.com Wed Mar 7 18:15:14 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C301121E805E for ; Wed, 7 Mar 2012 18:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZtLrgomX+Z5 for ; Wed, 7 Mar 2012 18:15:14 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 52DA521E8053 for ; Wed, 7 Mar 2012 18:15:14 -0800 (PST) Received: (qmail 29307 invoked from network); 7 Mar 2012 23:39:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Mar 2012 23:39:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 7 Mar 2012 16:18:25 -0700 From: Eran Hammer To: John Bradley Date: Wed, 7 Mar 2012 16:18:17 -0700 Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AczlNNN25d70S7GxRlKDI7eb2HdniAXg6QXA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4072@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4F1F3D84.1030300@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723453AAB9682E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7D4DB9C9-7194-42A0-A573-4243FE27E512@ve7jtb.com> In-Reply-To: <7D4DB9C9-7194-42A0-A573-4243FE27E512@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Julian Reschke , "oauth@ietf.org" , "ietf@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:15:14 -0000 New text: The probability of an attacker guessing generated tokens (and oth= er credentials not intended for handling by end-users) MUST be less than or equal to= 2^(-128) and SHOULD be less than or equal to 2^(-160). Removed reference to RFC 1750. EH > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Monday, February 06, 2012 5:07 PM > To: Eran Hammer > Cc: Julian Reschke; ietf@ietf.org; The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: (T= he > OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard >=20 > RE new text in Draft 23 >=20 > http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-10.10 >=20 > Generated tokens and other credentials not intended for handling by > end-users MUST be constructed from a cryptographically strong random > or pseudo-random number sequence ([RFC1750]) generated by the > authorization server. >=20 > Given that many implementations may elect to use signed tokens, such as > SAML or JWT (JOSE) this should not be a MUST. >=20 > Giving people sensible defaults such as the probability of an attacker > guessing a valid access token for the protected resource should be less t= han > 2^(-128). >=20 > The probability of generating hash colisions randomly is a odd metric, 2= ^(- > 128) for a SHA256 as I recall. > Many factors play into what is secure, token lifetime etc. >=20 > I don't mind some reasonable defaults but adding a requirement for > unstructured tokens is a bit much. >=20 > Regards > John B. >=20 >=20 From haibin.song@huawei.com Wed Mar 7 18:20:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C527521F8527; Wed, 7 Mar 2012 18:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn2J0sneccck; Wed, 7 Mar 2012 18:20:45 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id EDF2921F8525; Wed, 7 Mar 2012 18:20:18 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J00N2ENTU3Q@szxga04-in.huawei.com>; Thu, 08 Mar 2012 10:20:18 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J006B6NTU3M@szxga04-in.huawei.com>; Thu, 08 Mar 2012 10:20:18 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHR02466; Thu, 08 Mar 2012 10:20:17 +0800 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 08 Mar 2012 10:20:11 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Thu, 08 Mar 2012 10:20:13 +0800 Date: Thu, 08 Mar 2012 02:20:44 +0000 From: Songhaibin In-reply-to: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4079@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Originating-IP: [10.138.41.129] To: Eran Hammer , Justin Richer Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 Thread-index: AczrxK1m0Cmrx5G1TqO2SHCpS5Hjof//wGMA//yqX4D/2ndaEP+0yFaA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3BB6B8.1030501@mitre.org> <90C41DD21FB7C64BB94121FBBC2E723453AFCD4079@P3PW5EX1MB01.EX1.SECURESERVER.NET> Cc: "draft-ietf-oauth-v2@tools.ietf.org" , "tsv-ads@tools.ietf.org" , Martin Stiemerling , "oauth@ietf.org" , "tsv-dir@ietf.org" Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:20:45 -0000 OK. I understand. Then I have no questions. Thank you for the answer. -Haibin > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Eran Hammer > Sent: Thursday, March 08, 2012 8:02 AM > To: Songhaibin; Justin Richer > Cc: draft-ietf-oauth-v2@tools.ietf.org; tsv-ads@tools.ietf.org; tsv-dir@ietf.org; > oauth@ietf.org; Martin Stiemerling > Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 > > > > > -----Original Message----- > > From: Songhaibin [mailto:haibin.song@huawei.com] > > Sent: Friday, February 17, 2012 12:53 AM > > To: Justin Richer > > Cc: tsv-ads@tools.ietf.org; draft-ietf-oauth-v2@tools.ietf.org; Martin > > Stiemerling; oauth@ietf.org; tsv-dir@ietf.org > > Subject: RE: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 > > > > Hi Justin, > > > > Thank you for the clarification. See in line. > > > > > -----Original Message----- > > > From: Justin Richer [mailto:jricher@mitre.org] > > > Sent: Wednesday, February 15, 2012 9:44 PM > > > To: Songhaibin > > > Cc: tsv-ads@tools.ietf.org; draft-ietf-oauth-v2@tools.ietf.org; Martin > > > Stiemerling; oauth@ietf.org; tsv-dir@ietf.org > > > Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 > > > > > > On 02/15/2012 04:33 AM, Songhaibin wrote: > > > > I've reviewed this document as part of the transport area > > > > directorate's ongoing > > > effort to review key IETF documents. These comments were written > > > primarily for the transport area directors, but are copied to the > > > document's authors for their information and to allow them to address > > > any issues raised. The authors should consider this review together with > > any other last-call comments they receive. > > > Please always CC tsv-dir@ietf.org if you reply to or forward this review. > > > > > > > > First, I should apologize for the delay in this review, I should > > > > have finished it two > > > days ago. I have some common security knowledge but not an expert. > > > > > > > > Summary > > > > > > > > This draft is basically ready for publication, but has nits that > > > > should be fixed > > > before publication. > > > > > > > > General issues need discussion: > > > > > > > > 1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: > > > > resource owner > > > password credentials, and client credentials. These two have the same > > > flow and many in common, and they are significantly different than the > > > authorization code grant type and implicit grant type described in > > > previous sections. And in section 1.3.4, it also says " Client > > > credentials are used as an authorization grant typically when the > > > client is acting on its own behalf (the client is also the resource > > > owner),...". Is it better to combine these two grant types as one "client > > credentials" grant type where the client can be the resource owner? > > > > > > No, they are quite distinct -- It all comes down to what you're > > > authenticating. The Resource Owner Password Credentials flow *also* > > > includes client credentials which are distinct from the resource > > > owner's own credentials. The client's credentials are going to be the > > > same for a given client across many different users, while the > > > Resource Owner's credentials are going to be different across > > > different users, but the same across different clients (for the same > > > resource owner). In most flows, the client's credentials identify just > > > the client, and the resource owner is identified through some other > > > means (a direct password, a redirected login to the authz endpoint). > > > In the Client Credentials flow, the client's credentials are the only ones that > > you have. > > > > > > > Okay, in the Resource Owner Password Credentials flow, it adds client > > credentials, but any client who was issued credentials from the authorization > > server can pass. How much security does the client credential in this flow > > add? > > It can allow the server to enforce policies, but more importantly, client > authentication is part of every access token request make to this endpoint as > part of the overall architecture. > > > > > 2. Two concepts confused me in section 2.4, I don't know if I am the > > > > only person > > > who is confusing here. One is user-agent-based application and another > > > is native application, why are they executed on the device used by the > > > resource owner? I think they can run on any device used by resource > > > consumer instead of resource owner. Resource owner is only used to grant > > access to resources. > > > > > > OAuth's main 3-legged pattern allows what's called "Alice-to-Alice > > > sharing", in that the Client is consuming on behalf of the resource > > > owner. In cases where you have an in-user-agent app or a native app, > > > the end user (resource owner) is going to be the one running it, and > > > the one authorizing it. > > > > > > > Yes, I understand that. But the document seems like resource owner is the > > "only" one who can run the UA app or native app? Or I missed something? > > It is the only one. Only the resource owner can grant access. > > EH > > > > > Thanks, > > -Haibin > > > > > > > > Thanks for your feedback, and I hope this can help clear up the intent > > > of the working group here. If you can suggest language that will > > > solidify these points further, it can help make sure this doesn't > > > further confuse people. > > > > > > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Mar 7 21:29:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD21521E8048 for ; Wed, 7 Mar 2012 21:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vatX7nTBQmtl for ; Wed, 7 Mar 2012 21:29:15 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 75A3121E8029 for ; Wed, 7 Mar 2012 21:29:15 -0800 (PST) Received: (qmail 31710 invoked from network); 8 Mar 2012 05:29:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 05:29:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 7 Mar 2012 22:28:06 -0700 From: Eran Hammer To: "matake@gmail" , Buhake Sindi Date: Wed, 7 Mar 2012 22:27:57 -0700 Thread-Topic: [OAUTH-WG] Quick question about error response for "response_type=unknown" Thread-Index: Aczwk5xj4w9FLHhvT2aZ4XFi7k1SUQMV5tYQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD409A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <58932B8B-2DDE-41D6-A91B-5036CC762C00@matake.jp> <1329757027.28055.YahooMailNeo@web31808.mail.mud.yahoo.com> <4F4284DD.3030006@alcatel-lucent.com> <1329798149.78115.YahooMailNeo@web31804.mail.mud.yahoo.com> <56F7111A-B65E-459A-BB8A-ED87CDF1EB4A@gmail.com> <8799A0DF-4BB9-4122-8CC0-D2A33C507A51@gmail.com> In-Reply-To: <8799A0DF-4BB9-4122-8CC0-D2A33C507A51@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD409AP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 05:29:19 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD409AP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.1.1 states: If an authorization request is missing the "response_type" parameter, the authorization server MUST return an error response as described in Section 4.1.2.1. The intention was to make this the catch-all scenario. While I do appreciat= e the issue here of the client using a response type that may require speci= al encoding of the error information in the response, it is pretty easy to = also support the authorization code response type error transport when usin= g a response type other than code and token. I have made the following change to clarify this: If an authorization request is missing the "response_type" parameter, [[or if the response type is not understood, ]] the authorization server MUST return an error response as described in Section 4.1.2.1. "Not understood" means the server does not know anything about it. It shoul= d know about code and token, even if one or both are not supported and prov= ide the required error response. This really is only about unknown extensio= ns. Then according to section 4.1.2.1, the error code should be 'unsupporte= d_response_type'. I have tried to make the change as small as possible, but if my explanation= isn't clear from the new text, please let me know and we'll get it clarifi= ed. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of m= atake@gmail Sent: Tuesday, February 21, 2012 4:23 AM To: Buhake Sindi Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Quick question about error response for "response_t= ype=3Dunknown" When server cannot understand the response_type, it can't know where the er= ror response should be included. ex.) A JS client used response_type=3Dcode%20id_token and expected all returned = parameters would be included in fragment. However server couldn't understand the response_type and returned error mes= sages in query. Then client won't be able to handle the error. Actually, clients expects returned parameters in query only when it uses re= sponse_type=3Dcode, at least in current proposed response_types. (I'm thinking "current proposed response_types" as "code", "token", "code t= oken", "token id_token", "code id_token" and "code token id_token") On 2012/02/21, at 20:42, Buhake Sindi wrote: Oops. Sorry, I believe I should have said, case 2. And why is case 2 impossible? The only time case 1 is valid in the redirect= _uri is invalid. Buhake Sindi On 21 February 2012 13:40, Buhake Sindi > wrote: Hi guys, OAuth 2, Draft 23, Paragraph 4.1.2.1 clearly states: If the request fails due to a missing, invalid, or mismatching redirection = URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform th= e resource owner of the error, and MUST NOT automatically redirect the user-agent to the invali= d redirection URI. So, Case 1 is the only accepted case here. Buhake Sindi On 21 February 2012 13:34, matake@gmail > wrote: So the answer is "Show the error to the user without redirecting back to th= e client", right? I'm now developing OAuth2 and OpenID Connect ruby library, and both of them= return errors case 1. redirect with error in query if response_type is "code" but it's no= t supported case 2. redirect with error in fragment if response_type is "token code", "= token id_token", "token code id_token" or "code id_token" but it's not supp= orted case 3. otherwise show error to the user without redirect since server cann= ot understand the response_type at all But other server might not understand some of response_types listed in case= 2 at all and choose case 3 in such case. (ie. OAuth servers which don't understand OpenID Connect won't understand "= id_token") So I'm afraid that it reduces interoperability, a bit. On 2012/02/21, at 13:22, William Mills wrote: I does allow some parts of your server config to be discovered. More of a = problem in error responses is usually echoing back the user data, or allowi= ng user enumeration for example. Care is required, but you don't have a to= n of options here. ________________________________ From: Igor Faynberg > To: oauth@ietf.org Sent: Monday, February 20, 2012 9:37 AM Subject: Re: [OAUTH-WG] Quick question about error response for "response_t= ype=3Dunknown" Could there be a potential security hole in providing an error response? (= Not that I see it, but many problems in the past had been caused by helpful= responese.) Igor On 2/20/2012 11:57 AM, William Mills wrote: Respond with an error in protocol. Thta won't include a redirect, and the = client has to know what to do. ________________________________ From: nov matake To: oauth WG Sent: Monday, February 20, 2012 6:11 AM Subject: [OAUTH-WG] Quick question about error response for "response_type= =3Dunknown" Hi OAuthers, My apologies if you already discussed this. When OAuth server received unknown response_type, how should the server han= dle the error? 1. Show the error to the user without redirecting back to the client 2. Redirect back to the client including the error in query 3. Redirect back to the client including the error in fragment Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for me= . -- nov _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- The Elite Gentleman --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD409AP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3= .1.1 states:

 

   If an authorization= request is missing the "response_type" parameter,

   the authorization server MU= ST return an error response as described

   in Section 4.1.2.1.

 

The intention was to make this the catch-all scenario. While I do apprec= iate the issue here of the client using a response type that may require sp= ecial encoding of the error information in the response, it is pretty easy = to also support the authorization code response type error transport when u= sing a response type other than code and token.

 

I have made the following change to clarify this:

<= p class=3DMsoNormal> 

   If an authorization request is missing the "respo= nse_type" parameter,

=    [[or if the response type is not understood, ]]

   the authorization server MU= ST return an error response as described

   in Section 4.1.2.1.

 

“Not understood” means the server does not know anything abo= ut it. It should know about code and token, even if one or both are not sup= ported and provide the required error response. This really is only about u= nknown extensions. Then according to section 4.1.2.1, the error code should= be ‘unsupported_response_type’.

 

I have tried to make the change as small as possible, but if my explanatio= n isn’t clear from the new text, please let me know and we’ll g= et it clarified.

&nbs= p;

EH

 

 

= From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = matake@gmail
Sent: Tuesday, February 21, 2012 4:23 AM
T= o: Buhake Sindi
Cc: oauth@ietf.org
Subject: Re: [OA= UTH-WG] Quick question about error response for "response_type=3Dunkno= wn"

 <= /o:p>

When server cannot understand the response_ty= pe, it can't know where the error response should be included.

 

ex.)

A JS client used r= esponse_type=3Dcode%20id_token and expected all returned parameters would b= e included in fragment.

Howev= er server couldn't understand the response_type and returned error messages= in query.

Then client won't = be able to handle the error.

=  

Actually, clients expe= cts returned parameters in query only when it uses response_type=3Dcode, at= least in current proposed response_types.

(I'm thinking "current proposed response_types" as&= nbsp;"code", "token", "code token", "tok= en id_token", "code id_token" and "code token id_token&= quot;)

 

<= /div>

 

On 2012/02/21, at 20:42, Buhake Sindi wrote:



Oops. Sorry, I believe I should have said, case 2= .

And why is case 2 impossible? The only time case 1 is valid in the= redirect_uri is invalid.

Buhake Sindi

On 21 February 2012 13:40, Buhake Sindi <buhake@googlemail.com> wrote:

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>Hi guys,

OAuth 2,= Draft 23, Paragraph 4.1.2.1 clearly states:

If the request fails due to a missing, invalid, or mismatching redirec= tion URI, or if the client
identifier is missing or invalid, the authori= zation server SHOULD inform the resource owner of
the error, and MUST NO= T automatically redirect the user-agent to the invalid redirection URI.


So, Case 1 is the only accepted ca= se here.

Buhake S= indi
 

 

On 21 February 2012 13:34, matake@gmail <matake@gmail.com> wrote:

<= div>

So the answer is "Show the error to the user = without redirecting back to the client", right?

I'm now developing OAuth2 and OpenID Connect ruby library= , and both of them return errors

 

case 1. redirect w= ith error in query if response_type is "code" but it's not suppor= ted

case 2. redirect with err= or in fragment if response_type is "token code", "token id_t= oken", "token code id_token" or "code id_token" bu= t it's not supported

case 3. = otherwise show error to the user without redirect since server cannot under= stand the response_type at all

 

But other server mig= ht not understand some of response_types listed in case 2 at all and choose= case 3 in such case.

(ie. OA= uth servers which don't understand OpenID Connect won't understand "id= _token")

 

So I'm afraid that it reduces interop= erability, a bit.

 

On 2012/02/21,= at 13:22, William Mills wrote:


I does allow some parts of your se= rver config to be discovered.  More of a problem in error responses is= usually echoing back the user data, or allowing user enumeration for examp= le.  Care is required, but you don't have a ton of options here.<= /o:p>

 

From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
To: oauth@ietf.org=
Sent: Monday, February 20, 2012 9:37 AM
Subject: = Re: [OAUTH-WG] Quick question about error response for "response_type= =3Dunknown"

 = ;

Could there be a potential securi= ty hole in providing an error response?  (Not that I see it, but many = problems in the past had been caused by helpful responese.)

Igor
=
On 2/20/2012 11:57 AM, William Mills wrote:

 

From:<= /span> nov matake <nov@matake.jp>To: oauth WG &l= t;oauth@ietf.org>
Sent: Monday, February 20, 2012 6:11 AM=
Subject: [OAUTH-WG] Quick question about error response for &quo= t;response_type=3Dunknown"


Hi OAuthers,

My apologies if= you already discussed this.

When OAuth server received unknown resp= onse_type, how should the server handle the error?

1. Show the error= to the user without redirecting back to the client
2. Redirect back to = the client including the error in query
3. Redirect back to the client i= ncluding the error in fragment

Since choosing 2 or 3 is impossible i= n this case, 1 seems reasonable for me.


--
nov
___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.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
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 


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






--
The Eli= te Gentleman

 

=
= --_000_90C41DD21FB7C64BB94121FBBC2E723453AFCD409AP3PW5EX1MB01E_-- From eran@hueniverse.com Wed Mar 7 21:30:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0888521E8050 for ; Wed, 7 Mar 2012 21:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMMN1tea2GLF for ; Wed, 7 Mar 2012 21:30:36 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id E72AB21E8029 for ; Wed, 7 Mar 2012 21:30:35 -0800 (PST) Received: (qmail 359 invoked from network); 8 Mar 2012 05:30:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 05:30:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 7 Mar 2012 22:29:48 -0700 From: Eran Hammer To: Songhaibin , "tsv-ads@tools.ietf.org" , "draft-ietf-oauth-v2@tools.ietf.org" Date: Wed, 7 Mar 2012 22:29:39 -0700 Thread-Topic: tsv-dir review of draft-ietf-oauth-v2-23 Thread-Index: AczrxK1m0Cmrx5G1TqO2SHCpS5HjoQQ+W/QAAASPNnAABwRTYA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD409B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD407B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Martin Stiemerling , "oauth@ietf.org" , "tsv-dir@ietf.org" Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 05:30:37 -0000 Should simple read "the attacker's user-agent is sent to". EH > -----Original Message----- > From: Songhaibin [mailto:haibin.song@huawei.com] > Sent: Wednesday, March 07, 2012 6:11 PM > To: Eran Hammer; tsv-ads@tools.ietf.org; draft-ietf-oauth-v2@tools.ietf.o= rg > Cc: tsv-dir@ietf.org; oauth@ietf.org; Martin Stiemerling > Subject: RE: tsv-dir review of draft-ietf-oauth-v2-23 >=20 > > > 5. Section 10.6, paragraph 2, second sentence, When the attacker is > > > sent to.../ When the authorization code request is sent to... > > > > Not sure what you mean. >=20 > I mean you may have to change "the attacker is sent to..." to "the > authorization code is sent to...". >=20 > BR, > -Haibin >=20 > > -----Original Message----- > > From: Eran Hammer [mailto:eran@hueniverse.com] > > Sent: Thursday, March 08, 2012 8:16 AM > > To: Songhaibin; tsv-ads@tools.ietf.org; > > draft-ietf-oauth-v2@tools.ietf.org > > Cc: tsv-dir@ietf.org; oauth@ietf.org; Martin Stiemerling > > Subject: RE: tsv-dir review of draft-ietf-oauth-v2-23 > > > > Thanks Haibin. > > > > > -----Original Message----- > > > From: Songhaibin [mailto:haibin.song@huawei.com] > > > Sent: Wednesday, February 15, 2012 1:33 AM > > > > > Nits: > > > 1. Section 3.1, paragraph 4, the last sentence is confusing, is it > > > the authorization server who sends the request to the authorization > endpoint? > > > Or is it the resource owner? > > > > The client. Added clarification in section 3. > > > > > 2. Section 3.1.1, paragraph 3, "...where the order of values does not > matter.." > > > I think a little clarification on the reason for this would be > > > better for people like me. > > > > I don't think we need to explain it, but it's to meet typical developer= s' > > expectations. > > > > > 3. Section 3.2, paragraph 4, the last sentence is confusing, is it > > > the authorization server who sends request to the token endpoint? > > > > Same as #1. > > > > > 4. Section 10.12, paragraph 4, should the terminology "end-user" be > > > changed to "resource owner"? There are same issues in other places > > > of this document. > > > > Changed some. Clarified end-user in the intro. > > > > > 5. Section 10.6, paragraph 2, second sentence, When the attacker is > > > sent to.../ When the authorization code request is sent to... > > > > Not sure what you mean. > > > > EH > > From internet-drafts@ietf.org Wed Mar 7 21:42:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9396721E805C; Wed, 7 Mar 2012 21:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dmust7-GZRFC; Wed, 7 Mar 2012 21:42:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0A921E804D; Wed, 7 Mar 2012 21:42:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308054218.5762.28475.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2012 21:42:18 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 05:42:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer David Recordon Dick Hardt Filename : draft-ietf-oauth-v2-24.txt Pages : 66 Date : 2012-03-07 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt From eran@hueniverse.com Wed Mar 7 21:47:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA71B21F84C9 for ; Wed, 7 Mar 2012 21:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJYvDhe0yF7s for ; Wed, 7 Mar 2012 21:47:10 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 0CC0721F84A0 for ; Wed, 7 Mar 2012 21:47:10 -0800 (PST) Received: (qmail 28845 invoked from network); 8 Mar 2012 05:47:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 05:47:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Mar 2012 22:46:39 -0700 From: Eran Hammer To: "oauth@ietf.org" Date: Wed, 7 Mar 2012 22:46:30 -0700 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt Thread-Index: Acz87kAwMvyR2W9VTxuy1Zp1WY9gvwAAH/xQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD409D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20120308054218.5762.28475.idtracker@ietfa.amsl.com> In-Reply-To: <20120308054218.5762.28475.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 05:47:11 -0000 This draft is ready to go to IESG Review. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Wednesday, March 07, 2012 9:42 PM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of > the IETF. >=20 > Title : The OAuth 2.0 Authorization Protocol > Author(s) : Eran Hammer > David Recordon > Dick Hardt > Filename : draft-ietf-oauth-v2-24.txt > Pages : 66 > Date : 2012-03-07 >=20 > The OAuth 2.0 authorization protocol enables a third-party > application to obtain limited access to an HTTP service, either on > behalf of a resource owner by orchestrating an approval interaction > between the resource owner and the HTTP service, or by allowing the > third-party application to obtain access on its own behalf. This > specification replaces and obsoletes the OAuth 1.0 protocol described > in RFC 5849. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Wed Mar 7 23:01:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FE721F861A for ; Wed, 7 Mar 2012 23:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKRFAcCu7mi6 for ; Wed, 7 Mar 2012 23:01:21 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7D01A21F8604 for ; Wed, 7 Mar 2012 23:01:20 -0800 (PST) Received: from [80.187.106.181] (helo=[31.243.207.121]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1S5XLi-0002i8-Pq; Thu, 08 Mar 2012 08:01:19 +0100 References: User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Torsten Lodderstedt Date: Thu, 08 Mar 2012 08:01:02 +0100 To: Ross Boucher ,OAuth WG Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] Multiple access tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 07:01:22 -0000 Hi, Ross Boucher schrieb: >The spec doesn't seem to have any recommendations on this point, but >should an OAuth v2 API always return the same access token if the same >client makes multiple requests? Is there any benefit to not generating >a new access token for each request? I don't see any. >Similarly, if you do generate new >access tokens (as I am doing now), should you also generate new refresh >tokens? Depends on the grant type. I would expect an authz server to generate new refresh tokens for "code", whether the authz server creates a new one for grant type "refresh_token" might depend on server impl. and client-specific policy (refresh token rotation). > >An unrelated question about revoking access tokens when the same >authorization code is used more than once: should refresh tokens also >be revoked? Does it make sense to not revoke refresh token? Otherwise, it could be used to obtain fresh access tokens. > And, if so, should any tokens issued with that refresh >token then also be revoked? It seems :-) sounds reasonable but not nessessarily feasable > simpler (if slightly less correct) >to just revoke all access tokens for that specific client/resource pair >in that case, rather than tracking the ancestry of all tokens. Generally, I would consider revoking access tokens more difficult then revoking refresh tokens. It depends on your token design. One can use handles for refresh tokens and self-contained access tokens and revoke refresh tokens only. In that case, I would limit the access token lifetime in order to force a periodic refresh. Regarding client/resource: Depends on whether you are able to really identify a particular client instance. Otherwise, you would revoke tokens for different (potentially a lot of) client installations using the same client_id. regards, Torsten. > >Thanks, >Ross_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Wed Mar 7 23:12:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D6021E8025 for ; Wed, 7 Mar 2012 23:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.234 X-Spam-Level: X-Spam-Status: No, score=-17.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 009IgdGnT8oT for ; Wed, 7 Mar 2012 23:12:10 -0800 (PST) Received: from nm15.bullet.mail.sp2.yahoo.com (nm15.bullet.mail.sp2.yahoo.com [98.139.91.85]) by ietfa.amsl.com (Postfix) with SMTP id 04C2921E8024 for ; Wed, 7 Mar 2012 23:12:10 -0800 (PST) Received: from [98.139.91.62] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 08 Mar 2012 07:12:07 -0000 Received: from [98.139.91.46] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 08 Mar 2012 07:12:07 -0000 Received: from [127.0.0.1] by omp1046.mail.sp2.yahoo.com with NNFMP; 08 Mar 2012 07:12:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 35303.54993.bm@omp1046.mail.sp2.yahoo.com Received: (qmail 5128 invoked by uid 60001); 8 Mar 2012 07:12:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1331190726; bh=d+BVRWElYdiVrUkhafepaBjntaoxryKbXrVx6QQviRA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=O66pOzI41nhezs/cVwYxS/NJ8DnLt2r3waFxVte/7by/Wg6PpSh9iVadY5KObcnZXQIfG3TUMLmym76IMJHrjBwCc2cBVyF/dnkItILDVCS71yfa1n8PK2SQSqGkAniXwC7lNEhx8lOnjEXNZ4XoPXfomkUUpd+FQwVNkIe54RY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rRibTzBz630KQ8ebfcuArQ0bLEJtDHY/7AO5rXa7IPhXoXqBB3f3ZgBv9jI8FxCiMx5QxjXWF7IJIBYXVicWNmkxPlHsvdQyI2V/nhDRnZUgsmWhtk3kdElbztJAZ5iN8nDf6X46bA1xcsTYiSR5X8t1j59xdCXWTMxK5VjHsNw=; X-YMail-OSG: by1VNdAVM1lnmbuJ.o6tlMy6afnLT8LRS4srGJwVmbx3TxZ p7VMKdRmhc4UW2bVYamejcQT9RQP_BUOTqyZ7GnrUydr3N9V0fdxMYgYAsO1 6dLcuO3n1CSBIs76Q2PFPHr7oPYCG7O8BRjvM3Fi71KNCF99HOdpejif9WBv WrwXa32AKd9GKLt.aX7vn1fLuH_OWzyQ.EeArSwLZDrG0leijnxdhS4z2qsE UfCUePdYcLys36pdiiQ_FrE67BwXlkw.QB901ooA0Hum1kpjUHitIl6UWIWk FpUmyw35Rzq..cwhlhGY0BS_mly7sxju_xe1l3Hi0bSbgYwCqrlirzJu5XVH Ye5n1M.72QwLfj7eyeR6fhmItuPyzdL7ldsvSl1iLrPYdXoqhxd7q85Luk3R XFPWLgpuvWbXE8taFiOps6_agUzu8DsYqsCDH27d7UPAjxIVoAa4- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Wed, 07 Mar 2012 23:12:06 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: Message-ID: <1331190726.92627.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Wed, 7 Mar 2012 23:12:06 -0800 (PST) From: William Mills To: Ross Boucher , OAuth WG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Multiple access tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 07:12:10 -0000 You might want to put issuance time and other info in an access token.=A0 T= he spec is silent on your first question.=0A=0AOn revocation: One of the re= asons for short lived access tokens is to only revoke the refresh token, wh= ich has to be presented at a central server type rather than trying to exte= nd revocation to all protected resources.=A0 So if you're in that model you= would not bother revoking the access token.=0A=0AThe use case I can see fo= r invalidating access tokens and still honoring refresh tokens is the case = where you might have had the access token symmetric secret compromised but = not the refresh token secret.=A0 That's not really user revocation though.= =A0 I don't se an actual user revocation of access that would not potential= ly kill both tokens and always kill the refresh token.=0A=0A=A0=0A=0A=0A=0A= =0A----- Original Message -----=0AFrom: Ross Boucher = =0ATo: OAuth WG =0ACc: =0ASent: Wednesday, March 7, 2012 6:= 14 PM=0ASubject: [OAUTH-WG] Multiple access tokens=0A=0AThe spec doesn't se= em to have any recommendations on this point, but should an OAuth v2 API al= ways return the same access token if the same client makes multiple request= s? Is there any benefit to not generating a new access token for each reque= st? Similarly, if you do generate new access tokens (as I am doing now), sh= ould you also generate new refresh tokens?=0A=0AAn unrelated question about= revoking access tokens when the same authorization code is used more than = once: should refresh tokens also be revoked? And, if so, should any tokens = issued with that refresh token then also be revoked? It seems simpler (if s= lightly less correct) to just revoke all access tokens for that specific cl= ient/resource pair in that case, rather than tracking the ancestry of all t= okens.=0A=0AThanks,=0ARoss=0A______________________________________________= _=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/list= info/oauth=0A From stephen.farrell@cs.tcd.ie Thu Mar 8 02:32:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E92B21F8607 for ; Thu, 8 Mar 2012 02:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTKYhkYgRqeO for ; Thu, 8 Mar 2012 02:32:22 -0800 (PST) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6632621F8611 for ; Thu, 8 Mar 2012 02:32:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7F6C31535F8; Thu, 8 Mar 2012 10:32:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1331202739; bh=M74KYrCYc6SFZZ Qd0spmqAomni86geUQKr20xHawPwQ=; b=F6tkZu6pX4wgoLkyeo49pWv7CHPNcF hp/2sGFcoNsaNc5vzqvczRJ8CXk9e3sXS7l2GQoj9Nqe2nZoZKnRJgA+EBrhaNcW 7U3OhgjvscyFKRKBPfGdBE31aJ8rkQnK589TxXC/GcYDtdV3GoFRLBID57I00KVn xRgM9ntL/EwiD3Yz/QX9/dKFzSNuLDxfUi6624dB5z+YWkgwNaDZodEYmwBlkH7p Ue3AXW7XGSpFHEX7AVPOz1O/XBdD0nLflZhA3FDowOfHZw6+6Y+RKh1UaJvCZu0o uyYlf16KsPMMbBXzr66n3+U98UeBWq8+ya9v1ruUfXo/mqXLTwZhBF0g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id iHKqnrz-N57T; Thu, 8 Mar 2012 10:32:19 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 322CF1535F9; Thu, 8 Mar 2012 10:32:18 +0000 (GMT) Message-ID: <4F588AB2.4050003@cs.tcd.ie> Date: Thu, 08 Mar 2012 10:32:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Eran Hammer References: <20120308054218.5762.28475.idtracker@ietfa.amsl.com> <90C41DD21FB7C64BB94121FBBC2E723453AFCD409D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFCD409D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 10:32:23 -0000 Thanks Eran, A question... Is this text in 3.1.2.5 correct? If third-party scripts are included, the client MUST NOT ensure that its own scripts (used to extract and remove the credentials from the URI) will execute first. "MUST NOT ensure" is a really odd construct. Maybe s/NOT//? S On 03/08/2012 05:46 AM, Eran Hammer wrote: > This draft is ready to go to IESG Review. > > EH > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: Wednesday, March 07, 2012 9:42 PM >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt >> >> >> 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 : The OAuth 2.0 Authorization Protocol >> Author(s) : Eran Hammer >> David Recordon >> Dick Hardt >> Filename : draft-ietf-oauth-v2-24.txt >> Pages : 66 >> Date : 2012-03-07 >> >> The OAuth 2.0 authorization protocol enables a third-party >> application to obtain limited access to an HTTP service, either on >> behalf of a resource owner by orchestrating an approval interaction >> between the resource owner and the HTTP service, or by allowing the >> third-party application to obtain access on its own behalf. This >> specification replaces and obsoletes the OAuth 1.0 protocol described >> in RFC 5849. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt >> >> _______________________________________________ >> 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 stephen.farrell@cs.tcd.ie Thu Mar 8 02:37:50 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227CC21F86AB for ; Thu, 8 Mar 2012 02:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNB-ei4pAqo4 for ; Thu, 8 Mar 2012 02:37:49 -0800 (PST) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3638D21F86AA for ; Thu, 8 Mar 2012 02:37:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A0BFA153B7E for ; Thu, 8 Mar 2012 10:37:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1331203068; bh=W3TLtFPLOjAsEpakdT+6TK4u Mc0rQsSpNxh0faWov+g=; b=WCbt1CuP1EMKqnn8St1D4a4AG7FCiU8DaDeZ1OlD AejvY3LmKLgC8UYNTqqAY3EOAg4vdchW6Fl4AWrYTj2CybHM3c0WboWhSkuVxOVA ibrjSF8fUCTfH6rq5+0tJMlppK0YTI2BrQ5WEHQjc3uUc6k331NVUY7fI+jAEzsZ h95dhagAhDtR+hFfzWZTB7hFtxxLDenv+tqj0dbTVELlp01sTtfwqG5nA2Z3rytO pG+2pR1mHjjiAIYGsRSKXxUcY3g12Y1GCuuJoQssSuV+r/QraOSZtYTmZ/oCaMhH su00SEjxJnXJW0/qWui69V1/aqqUWzZR1lTOsh0ZSxgngg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id OXk33bPeBFeV for ; Thu, 8 Mar 2012 10:37:48 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 663FC1535F9 for ; Thu, 8 Mar 2012 10:37:48 +0000 (GMT) Message-ID: <4F588BFC.1000902@cs.tcd.ie> Date: Thu, 08 Mar 2012 10:37:48 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] progressing base and bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 10:37:50 -0000 First, thanks all, but especially editors and chairs, for your efforts on these. I'll be putting them on an IESG telechat agenda very shortly. That'll be for after the Paris meeting though, but only because we have a monster 700 pages of I-Ds to go through for next week's telechat due to outgoing ADs clearing the decks before they escape. So these'll likely be considered by the IESG for the April 12th telechat. Cheers, S. From ht@inf.ed.ac.uk Thu Mar 8 03:45:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21F921F8648; Thu, 8 Mar 2012 03:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ2943PhRPfp; Thu, 8 Mar 2012 03:45:35 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9761F21F8647; Thu, 8 Mar 2012 03:45:34 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q28BifJH019389; Thu, 8 Mar 2012 11:44:46 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q28BiemO013576; Thu, 8 Mar 2012 11:44:40 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q28BiejW003264; Thu, 8 Mar 2012 11:44:40 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q28BidJX003259; Thu, 8 Mar 2012 11:44:39 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Barry Leiba References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 08 Mar 2012 11:44:39 +0000 In-Reply-To: (Barry Leiba's message of "Wed, 7 Mar 2012 18:53:37 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "apps-discuss@ietf.org" , "oauth@ietf.org" , "dr@fb.com" Subject: Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 11:45:36 -0000 Barry Leiba writes: > Henry says... >>> No, I appreciate that you want to use registered short names in >>> the protocol, that's just fine.  My problem is that you have left >>> users, developers etc. with no way to discover what shortnames >>> have been registered short of a non- trivial and error-prone >>> informal search effort. >>> . . . > > Eran says... >> Not sure I understand what you are asking for, but what would the >> IANA instruction include to support this? > > Yeh, I'm not understanding this either. The spec establishes an > access-token-type registry, and anyone will be able to look in that > registry the same way they look in any other IANA registry, such as > media-types. It looks like Henry is asking for this to use some sort > of type/subtype mechanism, as media-types does, wherein when a new > token type is registered, that registration or subsequent ones can > create subtypes of that token type. No, sorry, not at all about subtyping or anyting like that. Sorry this is proving difficult to communicate! Start again. Consider the situation five years from now, when OAUTH2 is a great success, and there are dozens of entries in its various registries. 1) Suppose you're a developer, setting out to implement OAUTH2. You need to know what access token types, etc. to implement; 2) Or you're a user, wondering what access token types are available, so you can decide which suit your requirements best; 3) Or you're a service provider, and you come up with a new token type and want to check if the name you have in mind is already in use. You have read the spec., and the _only_ concrete thing it tells you about the registers is the name of an email list. So you have to go to the email archives and search for . . . what exactly? Different in the three cases above, and in none of them is it obvious how to know what counts as success. So what I'm asking for is more mechanism, documented in the spec. in terms of what the registry itself will provide, which is, in each case, a URI which will not only resolve to a list of the registered shortnames, but will also support retrieval for any registered short name by appending it. So for example for the access token type registry, the spec. should tell me that retrieving  http://www.iana.org/oath2/access-token-types will give me a page listing all the registered access token types, and also  http://www.iana.org/oath2/access-token-types/bearer will return the registration details for the bearer type. This will then make all of (1)--(3) easy. Better this time? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ve7jtb@ve7jtb.com Thu Mar 8 05:41:03 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA87B21F86A5 for ; Thu, 8 Mar 2012 05:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE5-BG3j7IQ5 for ; Thu, 8 Mar 2012 05:41:02 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B42A521F86A3 for ; Thu, 8 Mar 2012 05:41:02 -0800 (PST) Received: by ghbg16 with SMTP id g16so203465ghb.31 for ; Thu, 08 Mar 2012 05:41:02 -0800 (PST) Received: by 10.236.78.6 with SMTP id f6mr10911572yhe.109.1331214062313; Thu, 08 Mar 2012 05:41:02 -0800 (PST) Received: from [192.168.1.213] (190-20-3-127.baf.movistar.cl. [190.20.3.127]) by mx.google.com with ESMTPS id r68sm4818234yhm.18.2012.03.08.05.40.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 05:40:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_56237A7A-317B-4B7E-9660-496199DFA835"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4068@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 8 Mar 2012 10:40:56 -0300 Message-Id: <335B025F-D20A-4205-AF36-0D611638C464@ve7jtb.com> References: <90C41DD21FB7C64BB94121FBBC2E723453AAB9653D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F1E2639.10902@stpeter.im> <494090F8-EEC5-4156-B372-D06745E01552@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723453AFCD4068@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl+DVShLATTrvNDNokgL7yjlGA9AcLf6AK+WUF4Wpsk8YCRylwjm9zboidfKK2QDrdsE7vt Cc: OAuth WG Subject: Re: [OAUTH-WG] Server cret verification in 10.9 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:41:03 -0000 --Apple-Mail=_56237A7A-317B-4B7E-9660-496199DFA835 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, John B. On 2012-03-07, at 7:57 PM, Eran Hammer wrote: > New text: >=20 > In order to prevent man-in-the-middle attacks, the = authorization server MUST implement > and require TLS with server authentication as defined by = for > any request sent to the authorization and token endpoints. = The client MUST validate the > authorization server's TLS certificate as defined by , and in > accordance with its requirements for server identity = authentication. >=20 > EH >=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Tuesday, January 24, 2012 2:24 PM >> To: Peter Saint-Andre >> Cc: Eran Hammer; OAuth WG >> Subject: Re: [OAUTH-WG] Server cret verification in 10.9 >>=20 >> We added the reference to RFC6125 in openID Connect. >>=20 >> The Client MUST perform a TLS/SSL server certificate check, per >> RFC 6125. >>=20 >> We wanted to be more general to allow for non http bindings in the = future. >>=20 >> If you don't do it in core, every spec that references core will = probably have >> to add it. >>=20 >> John B. >>=20 >>=20 >> On 2012-01-24, at 12:32 AM, Peter Saint-Andre wrote: >>=20 >>> On 1/20/12 4:46 PM, Eran Hammer wrote: >>>> Stephen asked: >>>>=20 >>>>> (13) 10.9 says that the client MUST verify the server's cert which = is >>>>> fine. However, does that need a reference to e.g. rfc 6125? Also, = do >>>>> you want to be explicit here about the TLS server cert and thereby >>>>> possibly rule out using DANE with the non PKI options that that WG >>>>> (may) produce? >>>>=20 >>>> Can someone help with this? I don't know enough to address. >>>=20 >>> The OAuth core spec currently says: >>>=20 >>> The client MUST validate the authorization server's >>> TLS certificate in accordance with its requirements >>> for server identity authentication. >>>=20 >>> RFC 2818 has guidance about endpoint identity, in Section 3.1: >>>=20 >>> http://tools.ietf.org/html/rfc2818#section-3.1 >>>=20 >>> RFC 6125 attempts to generalize the guidance from RFC 2818 and many >>> similar specs for use by new application protocols. Given that OAuth = as >>> defined by the core spec runs over HTTP, I think referencing RFC = 2818 >>> would make sense. So something like: >>>=20 >>> The client MUST validate the authorization server's >>> TLS certificate in accordance with the rules for >>> server identity authentication provided in Section 3.1 >>> of [RFC2818]. >>>=20 >>> Peter >>>=20 >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_56237A7A-317B-4B7E-9660-496199DFA835 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz MDgxMzQwNTdaMCMGCSqGSIb3DQEJBDEWBBRGqkorBiu7UiWyhNBxpts7wyqNVjCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQCrOxLgs//mBb5U+ZpgfPYnZVLq51c9zsITaqyFC2fAJzsizl/ET6HVm6Un4VkBec8MdLBiDY9c 80rGD3H8JelTJMFnRtl6plGCxbBh6zKiGZUJLhLDXYM06HGvgTIpczuRqqzxjrfHQrYHoHXuWJ7M d0tOZzDBrE2gVwKBt4Fg1sn+Qtukh/RyXrSn0XF0HRFU1vs+MZ7zKUvimp7XrAVxrUJvVAourNkH yKRFD+Z7hr9Sq1scuobTDUojF44D3bNeEngj+kDUNKhTaNS0Nt5+hr/MUMsO0yMy//fSDWThQw3p CnJere9RsFcAiArMZx9C6Hhysvhe6Ohc4+RiVzqLAAAAAAAA --Apple-Mail=_56237A7A-317B-4B7E-9660-496199DFA835-- From barryleiba.mailing.lists@gmail.com Thu Mar 8 06:50:39 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216D521F86B2; Thu, 8 Mar 2012 06:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wneCz8ooeztv; Thu, 8 Mar 2012 06:50:38 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4130D21F867E; Thu, 8 Mar 2012 06:50:31 -0800 (PST) Received: by yhpp34 with SMTP id p34so266218yhp.31 for ; Thu, 08 Mar 2012 06:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=znLGOONItsG7O0DL5MS8JS30AYedN96VpLxeVLeciGI=; b=KyUWpaWHLFprwDGeQx+bVfkoKojD7tuF/eixcT1SJDHKGoivXKUDEyH9Cj6YUAmBr6 q7VVUiFQaeUN9K1rJY2hkN/+LjKBaSkywDFk62K2VnpPZBmzjXo0Gfxv6sYx4Z3+nEIe ka5k8u1IKgyRnpIboSz1d4hp0yXwr1E7GlRpY+8KBNvLTVDh0f0Ro2iW5wvQC/eO7LZl MHfyVdZfQkHoIGGQZ0638yLja1L8qIpMhiRRv2rT0uc4DOJlXvxdbEqDD5qeKxctu9v0 LM3d15jfGx8PEiAJ+ZOGhsZc/WAhe1a/mHAZqBgsIf906/QcpX3ukXl21PFKBlaysfRF c5dw== MIME-Version: 1.0 Received: by 10.236.186.1 with SMTP id v1mr11401653yhm.4.1331218230000; Thu, 08 Mar 2012 06:50:30 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Thu, 8 Mar 2012 06:50:29 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 8 Mar 2012 09:50:29 -0500 X-Google-Sender-Auth: x1Ovk_RoB4LPHAPq1kor495P6no Message-ID: From: Barry Leiba To: "Henry S. Thompson" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dr@fb.com" , "oauth@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 14:50:39 -0000 > You have read the spec., and the _only_ concrete thing it tells you > about the registers is the name of an email list. =A0So you have to go > to the email archives and search for . . . what exactly? =A0Different in > the three cases above, and in none of them is it obvious how to know > what counts as success. The email list is just how you start the registration process. There will be an IANA registry for access token types. When IANA creates it, the name will be in the published RFC (I expect there'll be a section in the IANA registries page ( http://www.iana.org/protocols/ ) for "OAuth Parameters", and "Access Token Types" will be listed there; search that page for "DKIM" to see what it'll look like). The spec also says what will be *in* the registry. The RFC Editor specifically does NOT want the URL for the registry to be in the RFC (the URL might change). But the registry NAME will be there. Barry From andreassolberg@gmail.com Thu Mar 8 07:02:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B4521F86DC for ; Thu, 8 Mar 2012 07:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt1forKuKuFN for ; Thu, 8 Mar 2012 07:01:59 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 70E1821F86F3 for ; Thu, 8 Mar 2012 07:01:58 -0800 (PST) Received: by lagj5 with SMTP id j5so711180lag.31 for ; Thu, 08 Mar 2012 07:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=v8jO/anPoBfkmQ/Pa4xZ3MiPN42cZSFczAzmT4LkZYo=; b=yKcTf6QB6ECXqIwz2LEuDEvBmtOfYuFbIi1l+sclrhd+I3wVdEI8KqTorK7f5g4Wkm yeiFxKyOuED6DO2a/9PR6UyC6a/+6Xy8AKBQrA0t+TlSiZ7y0Ap8g2DNesWxhGlJ7Dr0 XEPByWYQusTrgLm3SdvX1zVH+U6yk+QyzqEiYtMuC2kzoAuFLbMDnrlpLc/lCxtfnRK8 28ACrRp+zOUujYZSCieOujxOdTOfOOMurJe/CguEEJd1gLtSMllwLImPQbcdPUSwneA1 MShwovgurH4NjxoY2Tbe2l+N0S0O++tMhUGheq+LqPOETnS9ZkAP2Dcie8J6ltrbX6cR W9zQ== Received: by 10.112.101.40 with SMTP id fd8mr2331519lbb.17.1331218917352; Thu, 08 Mar 2012 07:01:57 -0800 (PST) Received: from [192.168.10.100] (94-246-37.42.3p.ntebredband.no. [94.246.37.42]) by mx.google.com with ESMTPS id a8sm2564596lba.15.2012.03.08.07.01.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 07:01:56 -0800 (PST) Sender: =?UTF-8?Q?Andreas_=C3=85kre_Solberg?= From: =?iso-8859-1?Q?Andreas_=C5kre_Solberg?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 16:01:55 +0100 Message-Id: <078BBFC3-4A62-481B-A20D-DCC4D8A4ED8B@uninett.no> To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [OAUTH-WG] New OAuth 2.0 Javascript library X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:02:00 -0000 In case anyone find it useful, here is a new OAuth 2.0 javascript = library. https://github.com/andreassolberg/jso It would be useful for me if people tested it and reported any problems. = I have limited access to alternative OAuth 2.0 provider implementations, = so I've only tested a few of the commercial ones so far. You can argue that a javascript OAuth library has limited value, given = that you can eigther communicate with your own server (in which you = share cookies with anyway) or you have to do ugly things like JSONP. = Some situations where I think such a library might be useful anyway: * given an API with CORS support. * in native web apps running in example phone gap, running in file:// = context and are thereby not limited by same-origin.=20 * in situations where you bypass the token to your own proxying = webserver, but would like to setup the tokens etc using javascript for = more control of the user interface. Feedback is welcome. Andreas =C5kre Solberg, UNINETT AS http://rnd.feide.no From ht@inf.ed.ac.uk Thu Mar 8 07:05:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D3021F86BA; Thu, 8 Mar 2012 07:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfqjwCDmnfgI; Thu, 8 Mar 2012 07:05:35 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 059BD21F8551; Thu, 8 Mar 2012 07:05:20 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q28F56Ie018790; Thu, 8 Mar 2012 15:05:06 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q28F56vS021035; Thu, 8 Mar 2012 15:05:06 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q28F56Wh007733; Thu, 8 Mar 2012 15:05:06 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q28F55sD007728; Thu, 8 Mar 2012 15:05:05 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Barry Leiba References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 08 Mar 2012 15:05:05 +0000 In-Reply-To: (Barry Leiba's message of "Thu, 8 Mar 2012 09:50:29 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "dr@fb.com" , "oauth@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:05:37 -0000 Barry Leiba writes: >> You have read the spec., and the _only_ concrete thing it tells you >> about the registers is the name of an email list.  So you have to go >> to the email archives and search for . . . what exactly?  Different in >> the three cases above, and in none of them is it obvious how to know >> what counts as success. > > The email list is just how you start the registration process. There > will be an IANA registry for access token types. When IANA creates > it, the name will be in the published RFC (I expect there'll be a > section in the IANA registries page ( http://www.iana.org/protocols/ ) > for "OAuth Parameters", and "Access Token Types" will be listed there; > search that page for "DKIM" to see what it'll look like). The spec > also says what will be *in* the registry. > > The RFC Editor specifically does NOT want the URL for the registry to > be in the RFC (the URL might change). But the registry NAME will be > there. OK, I now recognise a culture clash as the underlying point at issue, so this spec. is the wrong place to address it. Thanks for your patience, I hereby get out of the road on this point. I'll reply to Eran's message wrt any other outstanding points. . . ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From barryleiba@gmail.com Thu Mar 8 07:10:08 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F8021F85DB; Thu, 8 Mar 2012 07:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDZpbh9ALuMR; Thu, 8 Mar 2012 07:10:07 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABC821F8604; Thu, 8 Mar 2012 07:10:07 -0800 (PST) Received: by obbta4 with SMTP id ta4so886264obb.31 for ; Thu, 08 Mar 2012 07:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3J1Im/GiMtiATrixmUfahKNCeQbOvuvD6ILPoablnNQ=; b=f6YXAdhXddwteJ9/n9uwab9w6c4p/WheL0LcozgD1x2ZpiSfy1bQyW4hE7c8Z9DhWI zENDY6k0S1M9c+lLU4ZJ/TASC/yYAjK1S0srzt/Lpx19iCPygnzII4iSjnj1dVmAltmd l8LAk4I6whSTOeWqhRmhYXyjdw3xMEIkxtRL8jIcAzN319ysoz8jJof/x26m1j69ZVL4 UOtJwBDsD7rIOsJN53xgtaAaKIT5sQBgl1RlmAT5ne9x5DCj2XyW622WQuTOrLTR1eK5 PQ1ZRUu2Y81fFQIdukbwNeNJeP46kjo0VfMSi06dCOzw4RVTIiJqKOaSiRN++HQdZi4P DKEg== MIME-Version: 1.0 Received: by 10.182.225.69 with SMTP id ri5mr251720obc.74.1331219407266; Thu, 08 Mar 2012 07:10:07 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.60.125.37 with HTTP; Thu, 8 Mar 2012 07:10:07 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 8 Mar 2012 10:10:07 -0500 X-Google-Sender-Auth: HngQ-PbSdvN3j6XCYJyT1tj2qH0 Message-ID: From: Barry Leiba To: "Henry S. Thompson" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dr@fb.com" , "oauth@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:10:08 -0000 > OK, I now recognise a culture clash as the underlying point at issue, > so this spec. is the wrong place to address it. Ah... so if the issue is how IANA makes registry information available, then please go to the "happiana" mailing list ( https://www.ietf.org/mailman/listinfo/happiana ) and see if you can work with Michelle and the other IANA folks on it. Barry From ht@inf.ed.ac.uk Thu Mar 8 07:13:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A2A21F8763; Thu, 8 Mar 2012 07:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gODZmQ2QeO5W; Thu, 8 Mar 2012 07:13:17 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id A0DA521F8642; Thu, 8 Mar 2012 07:13:16 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q28FDDKe024732; Thu, 8 Mar 2012 15:13:13 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q28FDCDY021329; Thu, 8 Mar 2012 15:13:12 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q28FDC5G007944; Thu, 8 Mar 2012 15:13:12 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q28FDCZX007939; Thu, 8 Mar 2012 15:13:12 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Barry Leiba References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 08 Mar 2012 15:13:12 +0000 In-Reply-To: (Barry Leiba's message of "Thu, 8 Mar 2012 10:10:07 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "dr@fb.com" , "oauth@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:13:17 -0000 Barry Leiba writes: >> OK, I now recognise a culture clash as the underlying point at issue, >> so this spec. is the wrong place to address it. > > Ah... so if the issue is how IANA makes registry information > available Precisely. > then please go to the "happiana" mailing list ( > https://www.ietf.org/mailman/listinfo/happiana ) and see if you can > work with Michelle and the other IANA folks on it. Indeed. I should have realised that that was the right level sooner: as I said, thanks for your patience. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From Michael.Jones@microsoft.com Thu Mar 8 07:32:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEE821F86BE for ; Thu, 8 Mar 2012 07:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCI46jtH8r3g for ; Thu, 8 Mar 2012 07:32:05 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id DC8A721F86BB for ; Thu, 8 Mar 2012 07:32:04 -0800 (PST) Received: from mail48-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Mar 2012 15:32:04 +0000 Received: from mail48-ch1 (localhost [127.0.0.1]) by mail48-ch1-R.bigfish.com (Postfix) with ESMTP id 3A6C5160598; Thu, 8 Mar 2012 15:32:04 +0000 (UTC) X-SpamScore: -24 X-BigFish: VS-24(z3f54kz9371I542M4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h93fh) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail48-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail48-ch1 (localhost.localdomain [127.0.0.1]) by mail48-ch1 (MessageSwitch) id 1331220721854495_20300; Thu, 8 Mar 2012 15:32:01 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail48-ch1.bigfish.com (Postfix) with ESMTP id CEB262004C; Thu, 8 Mar 2012 15:32:01 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Mar 2012 15:31:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.124]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0283.004; Thu, 8 Mar 2012 15:31:56 +0000 From: Mike Jones To: Stephen Farrell Thread-Topic: ID Tracker State Update Notice: Thread-Index: AQHM/RuuB0RAqTDO60mFRiYIqBVjj5Zghizw Date: Thu, 8 Mar 2012 15:31:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943663DF10C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20120308110715.31992.10927.idtracker@ietfa.amsl.com> In-Reply-To: <20120308110715.31992.10927.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:32:05 -0000 SGkgU3RlcGhlbiwNCg0KSSB3YW50ZWQgdG8gdmVyaWZ5IHRoYXQsIGRlc3BpdGUgdGhpcyBzdGF0 ZSBjaGFuZ2UsIHRoYXQgaXQncyBzdGlsbCBPSyBmb3IgbWUgdG8gbWFrZSB0aGUgZWRpdG9yaWFs IGNoYW5nZSBzdWdnZXN0ZWQgYnkgdGhlIFdHIHRvIHRoZSBCZWFyZXIgc3BlYyB0byBjaGFuZ2Ug dGhlIGI2NHRva2VuIGV4YW1wbGUuDQoNCgkJCQlUaGFua3MsDQoJCQkJLS0gTWlrZQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBTZWNyZXRhcmlhdCBbbWFpbHRvOmll dGYtc2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIE1hcmNoIDA4 LCAyMDEyIDM6MDcgQU0NClRvOiBvYXV0aC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWll dGYtb2F1dGgtdjItYmVhcmVyQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBJRCBUcmFja2VyIFN0 YXRlIFVwZGF0ZSBOb3RpY2U6IDxkcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0xNy50eHQ+DQoN ClN0YXRlIGNoYW5nZWQgdG8gSUVTRyBFdmFsdWF0aW9uIGZyb20gV2FpdGluZyBmb3IgQUQgR28t QWhlYWQgSUQgVHJhY2tlciBVUkw6IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXIvDQoNCg== From internet-drafts@ietf.org Thu Mar 8 07:37:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E03D21F8778; Thu, 8 Mar 2012 07:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMPAyJh0PN3q; Thu, 8 Mar 2012 07:37:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE1521F8714; Thu, 8 Mar 2012 07:37:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308153711.20540.37998.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 07:37:11 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-25.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:37:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer David Recordon Dick Hardt Filename : draft-ietf-oauth-v2-25.txt Pages : 66 Date : 2012-03-08 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-25.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-25.txt From stephen.farrell@cs.tcd.ie Thu Mar 8 07:55:03 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9532021F847E for ; Thu, 8 Mar 2012 07:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aitnfSw1FctJ for ; Thu, 8 Mar 2012 07:55:02 -0800 (PST) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8266321F847C for ; Thu, 8 Mar 2012 07:55:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A08D61535F8; Thu, 8 Mar 2012 15:55:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1331222101; bh=QpApaUkfEiE34j 01/H7eaWE+UJWefbkItX2Q6xSRHW8=; b=NJPHA8fnwJnXtBsZSd9EX6RPt1OvYa fp6R3bdxGDsuxN/AnwJqLYeb+QuVAyog6rOtMPhmsaeUyp64S6fqUDOFngU3iqrc P+rYTo+8HAjxVKItx1lv17mf8Z22pOM7jfzG0TnoFVnNTAJk+O7Za0+NAJIxUmCP 1b9miHdVN6NU1NhGK9yQQRKgq8bLdvUXYhe9kIREXwQ93WccUm2Ig2zjkudNICot tHQXduazAI2zGgIMD8OsQJetbCG93fliZ1UdBtoDm0ciXMrZtpI7Xj+aBYNnpkl+ O63LB82su52O4vVSOTVkC6I4O0P2GPxqRsC3ji5HaRwKC/hgZ5JOhfcA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 8BpTL4d+Oksq; Thu, 8 Mar 2012 15:55:01 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 04D7F1535F9; Thu, 8 Mar 2012 15:55:00 +0000 (GMT) Message-ID: <4F58D654.1060204@cs.tcd.ie> Date: Thu, 08 Mar 2012 15:55:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mike Jones References: <20120308110715.31992.10927.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B1680429673943663DF10C@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663DF10C@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:55:03 -0000 Hi Mike, On 03/08/2012 03:31 PM, Mike Jones wrote: > Hi Stephen, > > I wanted to verify that, despite this state change, that it's still OK for me to make the editorial change suggested by the WG to the Bearer spec to change the b64token example. Sure. Changes the WG want that don't conflict with anything hammered out in WGLC or IETF LC between now and about a week before the IESG telechat (i.e. ~April 5th) are fine IMO but best to be guided by the WG chairs - in this case I don't recall the change you mean but I bet the WG chairs do. In other words, just check with the chairs before posting new revs is a good plan from now on. Cheers, S. > > Thanks, > -- Mike > > -----Original Message----- > From: IETF Secretariat [mailto:ietf-secretariat-reply@ietf.org] > Sent: Thursday, March 08, 2012 3:07 AM > To: oauth-chairs@tools.ietf.org; draft-ietf-oauth-v2-bearer@tools.ietf.org > Subject: ID Tracker State Update Notice: > > State changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > From ve7jtb@ve7jtb.com Thu Mar 8 08:13:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DFB21F854E for ; Thu, 8 Mar 2012 08:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9c+fGH4OYxR for ; Thu, 8 Mar 2012 08:13:29 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21DFF21F852E for ; Thu, 8 Mar 2012 08:13:28 -0800 (PST) Received: by yenm5 with SMTP id m5so353606yen.31 for ; Thu, 08 Mar 2012 08:13:28 -0800 (PST) Received: by 10.236.185.42 with SMTP id t30mr10838763yhm.105.1331223207198; Thu, 08 Mar 2012 08:13:27 -0800 (PST) Received: from 201-188-194-239.bam.movistar.cl ([201.188.194.239]) by mx.google.com with ESMTPS id n10sm3759581ani.8.2012.03.08.08.13.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 08:13:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_412498E1-4386-4610-9617-F3A2197AA9FD"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4072@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 8 Mar 2012 13:13:21 -0300 Message-Id: References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4F1F3D84.1030300@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723453AAB9682E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7D4DB9C9-7194-42A0-A573-4243FE27E512@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723453AFCD4072@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnnJ9hoB1F7pQlT2Mc6MI1pCEtev+DQ834bClprPrNOELatEmCEyfpAAHP6xtcz0B89ubKE Cc: Julian Reschke , "oauth@ietf.org" , "ietf@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:13:30 -0000 --Apple-Mail=_412498E1-4386-4610-9617-F3A2197AA9FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks that is better. Without knowing the lifetime of the token these are per guess = probabilities. Effectively 128bits for a random value and 256bits for a HMAC or other = signature. For tokens intended for handling by end-users it may be useful to give = some advice. In general you don't want an attacker having more than a one in 2^14 = chance of guessing a valid code for a AS during the lifetime of the = code(NIST LoA 2). For a code randomly generated from a 94 character code set 4 characters = gets you 26.3 bits of entropy. 5 characters requires limiting an attacker to 2^12.3 (5,042) guesses per = token lifetime.=20 For a code randomly generated from a 94 character code set 5 characters = gets you 32.9 bits of entropy. 5 characters requires limiting an attacker to 2^18.9 (489,178) guesses = per token lifetime.=20 If the token is single use and the client uses it right away that is = easy, however in a worst case scenario the token might live 10min? That would be 8.4 attempts per second as a max for a 4 character code or = 815 per second for 5 characters. That is all way too much to explain however I would recommend as a = general rule: Credentials intended for handling by end users SHOULD be a minimum of 5 = randomly generated charters from a set of 94 or otherwise contain a = minimum entropy of 2^32.9. That is probably high enough that the AS will notice an attack, lower = entropy may pass under the radar. =20 Also the chances of an attacker being successful go up proportionally to = the number simultaneous codes in flight at any point (it becomes a non = targeted attack). =20 It isn't something that I will loose sleep over, It gives me something = else to profile:) Thanks=20 John B. On 2012-03-07, at 8:18 PM, Eran Hammer wrote: > New text: >=20 > The probability of an attacker guessing generated tokens (and = other credentials not > intended for handling by end-users) MUST be less than or = equal to 2^(-128) and SHOULD be > less than or equal to 2^(-160). >=20 > Removed reference to RFC 1750. >=20 > EH >=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Monday, February 06, 2012 5:07 PM >> To: Eran Hammer >> Cc: Julian Reschke; ietf@ietf.org; The IESG; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Last Call: = (The >> OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard >>=20 >> RE new text in Draft 23 >>=20 >> http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-10.10 >>=20 >> Generated tokens and other credentials not intended for handling by >> end-users MUST be constructed from a cryptographically strong = random >> or pseudo-random number sequence ([RFC1750]) generated by the >> authorization server. >>=20 >> Given that many implementations may elect to use signed tokens, such = as >> SAML or JWT (JOSE) this should not be a MUST. >>=20 >> Giving people sensible defaults such as the probability of an = attacker >> guessing a valid access token for the protected resource should be = less than >> 2^(-128). >>=20 >> The probability of generating hash colisions randomly is a odd = metric, 2^(- >> 128) for a SHA256 as I recall. >> Many factors play into what is secure, token lifetime etc. >>=20 >> I don't mind some reasonable defaults but adding a requirement for >> unstructured tokens is a bit much. >>=20 >> Regards >> John B. >>=20 >>=20 >=20 --Apple-Mail=_412498E1-4386-4610-9617-F3A2197AA9FD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz MDgxNjEzMjFaMCMGCSqGSIb3DQEJBDEWBBQef3mDeDCjKu8tZa9JZ7ue/VYveTCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAexJNRq7wYCUOOP2pYQwFyBilvjp4KELC5AivyDoODeWpEBJGx4aRhjqfTd5Pt+RgKE9IPOGzS 4RZDiKtyyt53qcaWtoRrtAj+IFXu8370W/xREU0mEkqIbAZc4uCfvlLwqlCEuPDGONrOnWSdKgm/ cfmhmKNSsC/76S9L8QU2f004WcU3WiDt3EC7DZ3Ef/q3PQ+WzNzIk0ZXIHE/Gonw90BJx6NG1eli GqQ73NxBBYT7y0zohXF4Sh22mGi5faRxg9FJ2RVtF8YvJ59zPsz7ajQaFiXrv9Y06u9iq8BC/llT wlsXGx2VUoVKqo6cB28pt79VQ7jqcZpz9t8EAPgJAAAAAAAA --Apple-Mail=_412498E1-4386-4610-9617-F3A2197AA9FD-- From eran@hueniverse.com Thu Mar 8 09:36:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650A821F86B1 for ; Thu, 8 Mar 2012 09:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaioqDcDZ7wa for ; Thu, 8 Mar 2012 09:36:19 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7C32A21F86AA for ; Thu, 8 Mar 2012 09:36:19 -0800 (PST) Received: (qmail 27079 invoked from network); 8 Mar 2012 15:25:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 15:25:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 8 Mar 2012 08:20:07 -0700 From: Eran Hammer To: Stephen Farrell Date: Thu, 8 Mar 2012 08:19:58 -0700 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt Thread-Index: Acz9FsWLKwJ7ev1pSeiWI93ygu2IZQAKBqOA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD40C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20120308054218.5762.28475.idtracker@ietfa.amsl.com> <90C41DD21FB7C64BB94121FBBC2E723453AFCD409D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F588AB2.4050003@cs.tcd.ie> In-Reply-To: <4F588AB2.4050003@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:36:20 -0000 Yep. Forgot to drop the NOT. Want a new -25? EH > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, March 08, 2012 2:32 AM > To: Eran Hammer > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt >=20 >=20 > Thanks Eran, >=20 > A question... >=20 > Is this text in 3.1.2.5 correct? >=20 > If third-party > scripts are included, the client MUST NOT ensure that its own scripts > (used to extract and remove the credentials from the URI) will > execute first. >=20 > "MUST NOT ensure" is a really odd construct. Maybe s/NOT//? >=20 > S >=20 >=20 > On 03/08/2012 05:46 AM, Eran Hammer wrote: > > This draft is ready to go to IESG Review. > > > > EH > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of internet-drafts@ietf.org > >> Sent: Wednesday, March 07, 2012 9:42 PM > >> To: i-d-announce@ietf.org > >> Cc: oauth@ietf.org > >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt > >> > >> > >> 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 : The OAuth 2.0 Authorization Protocol > >> Author(s) : Eran Hammer > >> David Recordon > >> Dick Hardt > >> Filename : draft-ietf-oauth-v2-24.txt > >> Pages : 66 > >> Date : 2012-03-07 > >> > >> The OAuth 2.0 authorization protocol enables a third-party > >> application to obtain limited access to an HTTP service, either on > >> behalf of a resource owner by orchestrating an approval interactio= n > >> between the resource owner and the HTTP service, or by allowing th= e > >> third-party application to obtain access on its own behalf. This > >> specification replaces and obsoletes the OAuth 1.0 protocol descri= bed > >> in RFC 5849. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> This Internet-Draft can be retrieved at: > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt > >> > >> _______________________________________________ > >> 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 eran@hueniverse.com Thu Mar 8 09:38:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152D821F86AD for ; Thu, 8 Mar 2012 09:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0FP4pAdfK-J for ; Thu, 8 Mar 2012 09:38:34 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 480D221F86BA for ; Thu, 8 Mar 2012 09:38:34 -0800 (PST) Received: (qmail 329 invoked from network); 8 Mar 2012 15:32:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 15:32:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 8 Mar 2012 08:24:15 -0700 From: Eran Hammer To: Stephen Farrell Date: Thu, 8 Mar 2012 08:24:08 -0700 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt Thread-Index: Acz9FsWLKwJ7ev1pSeiWI93ygu2IZQAKLK1g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD40CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20120308054218.5762.28475.idtracker@ietfa.amsl.com> <90C41DD21FB7C64BB94121FBBC2E723453AFCD409D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F588AB2.4050003@cs.tcd.ie> In-Reply-To: <4F588AB2.4050003@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:38:35 -0000 I pushed -25 just in case with this fix. > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, March 08, 2012 2:32 AM > To: Eran Hammer > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt >=20 >=20 > Thanks Eran, >=20 > A question... >=20 > Is this text in 3.1.2.5 correct? >=20 > If third-party > scripts are included, the client MUST NOT ensure that its own scripts > (used to extract and remove the credentials from the URI) will > execute first. >=20 > "MUST NOT ensure" is a really odd construct. Maybe s/NOT//? >=20 > S >=20 >=20 > On 03/08/2012 05:46 AM, Eran Hammer wrote: > > This draft is ready to go to IESG Review. > > > > EH > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of internet-drafts@ietf.org > >> Sent: Wednesday, March 07, 2012 9:42 PM > >> To: i-d-announce@ietf.org > >> Cc: oauth@ietf.org > >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt > >> > >> > >> 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 : The OAuth 2.0 Authorization Protocol > >> Author(s) : Eran Hammer > >> David Recordon > >> Dick Hardt > >> Filename : draft-ietf-oauth-v2-24.txt > >> Pages : 66 > >> Date : 2012-03-07 > >> > >> The OAuth 2.0 authorization protocol enables a third-party > >> application to obtain limited access to an HTTP service, either on > >> behalf of a resource owner by orchestrating an approval interactio= n > >> between the resource owner and the HTTP service, or by allowing th= e > >> third-party application to obtain access on its own behalf. This > >> specification replaces and obsoletes the OAuth 1.0 protocol descri= bed > >> in RFC 5849. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> This Internet-Draft can be retrieved at: > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt > >> > >> _______________________________________________ > >> 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 barryleiba.mailing.lists@gmail.com Thu Mar 8 09:39:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2158321F86D3 for ; Thu, 8 Mar 2012 09:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S8edguw+F2T for ; Thu, 8 Mar 2012 09:39:32 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 638C021F86C6 for ; Thu, 8 Mar 2012 09:39:32 -0800 (PST) Received: by yhpp34 with SMTP id p34so432881yhp.31 for ; Thu, 08 Mar 2012 09:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=At4JzSy6iYSl4NdQXDZfk6QC7Ybcar0SZcCT8uchVGg=; b=vxtsY6iNnl4VQvSjmaLM5/UdXo+8IwDJElWpEhdNA9oqpPYTY6RlmXmzpH+JYkjA3B n4Xa/5hSh6NNuBvC/Xnv4sAgqFIjcQJxRz0mWzKY1jhnTMuRlQBVbJ6FEiGzg5DZhLQg Ws0ie87BY/oXx47mdzNoz5LK/j5ZOgVE79Gm/d5Ida3PS/0A8pSVTB4Sk6lM9fiuS5uy 86xj1R+UfuaPiDZ0FmFFz87UbW/pIJ/5Kdv1bE0x/WPR6oyNu54UWtSvsoBokjIfEpCa Rq10vjEbVCyYp33zV5LpMXlC/6JncVvIql4BOXZAmyK6oRwzpbnJUiP9yS9TfJJi86xp TuTg== MIME-Version: 1.0 Received: by 10.236.181.193 with SMTP id l41mr12008391yhm.38.1331228371959; Thu, 08 Mar 2012 09:39:31 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Thu, 8 Mar 2012 09:39:31 -0800 (PST) Date: Thu, 8 Mar 2012 12:39:31 -0500 X-Google-Sender-Auth: nw55ws9SI1gzgc-Xw8rxFsiQlsM Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Reminder: Contacting the chairs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:39:33 -0000 Because we're in the middle of a chair change, we're having people contact the chairs by sending email to Hannes and me. (1) This leaves Derek out. (2) If you do this after the Paris meeting, you'll be sending email to someone who's not an OAuth chair any more. You can fix this by *always* using the tools alias when you need to contact the chairs of this or any working group: Use that instead of our individual email addresses. Replace "oauth" with the name of another working group to contact that group's chairs. And don't forget the "tools." in there. Barry, OAuth chair for a couple more weeks From david@davidjfox.com Thu Mar 8 11:35:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDD421F84C3 for ; Thu, 8 Mar 2012 11:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTkSx6QFgP3o for ; Thu, 8 Mar 2012 11:35:45 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E228221F84B9 for ; Thu, 8 Mar 2012 11:35:44 -0800 (PST) Received: by obbta4 with SMTP id ta4so1201104obb.31 for ; Thu, 08 Mar 2012 11:35:44 -0800 (PST) Received: by 10.60.4.162 with SMTP id l2mr3521416oel.3.1331235344548; Thu, 08 Mar 2012 11:35:44 -0800 (PST) Received: from [192.168.0.195] (c-24-14-127-202.hsd1.il.comcast.net. [24.14.127.202]) by mx.google.com with ESMTPS id yv3sm3818044obb.3.2012.03.08.11.35.43 (version=SSLv3 cipher=OTHER); Thu, 08 Mar 2012 11:35:43 -0800 (PST) Message-ID: <4F590A14.8050909@davidjfox.com> Date: Thu, 08 Mar 2012 13:35:48 -0600 From: David Fox User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl7seFFc80R6gFzRpQqpMGQ9Okhr7K77IL1U7VQ9muWtmlhF+emSlo3l+eT9luLh2dvF1lt Subject: [OAUTH-WG] Question about particular OAuth use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:35:46 -0000 Hello all, I have a question about a possible use case of OAuth. The standard use case which is outlined thoroughly in the spec, is a client asking a resource owner for access to their information from the resource server. But, what about the case where a client/resource owner wants to share a particular resource with another, and potentially unregistered, user? An example illustrating what I mean: An application allows users to upload various templates of documents. And, by using an API, a user can send various types of media (e.g., tweets, FB pictures) to be inserted into said templates, thus creating new documents on the fly. Now, imagine a user in this application has various customers they wish to give access to a certain template. To achieve this, the user creates a token for each customer -- which could be locked down to a certain template, IP, domain, number of uses etc -- and delivers each token to the corresponding customer. Has anything like this been mentioned before? And if so, what was the suggested "dance?" From what I know, I'd imagine using bearer tokens and locking them to some of the conditions listed above would be best, but I'd like a more professional opinion. Thanks, -David Fox PS, after re-reading the spec, I found a typo: Section 2.1: http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.1 The authorization server MAY provider tools to manage such complex clients through a single administration interface. I believe this should be: The authorization server MAY provide tools to manage such complex clients through a single administration interface. From zachary.zeltsan@alcatel-lucent.com Thu Mar 8 11:56:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C9121F8678 for ; Thu, 8 Mar 2012 11:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mrTmFCzqMRh for ; Thu, 8 Mar 2012 11:56:27 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9915321F8677 for ; Thu, 8 Mar 2012 11:56:27 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q28JuPwh011227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Mar 2012 13:56:26 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q28JuOlu017116 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Mar 2012 13:56:25 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 8 Mar 2012 13:56:24 -0600 From: "Zeltsan, Zachary (Zachary)" To: "'David Fox'" , "'OAuth WG'" Date: Thu, 8 Mar 2012 13:56:22 -0600 Thread-Topic: [OAUTH-WG] Question about particular OAuth use case Thread-Index: Acz9Yq0oYM09GTokTvyIc/EiLKN4FwAAZCeA Message-ID: <5710F82C0E73B04FA559560098BF95B1250DC23F7F@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4F590A14.8050909@davidjfox.com> In-Reply-To: <4F590A14.8050909@davidjfox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] Question about particular OAuth use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:56:28 -0000 David, A use case that is similar to yours is described in=20 http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02, section 3.8. OAuth 2.0 does not directly support this use case. Zachary=20 =20 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= avid Fox Sent: Thursday, March 08, 2012 2:36 PM To: OAuth WG Subject: [OAUTH-WG] Question about particular OAuth use case Hello all, I have a question about a possible use case of OAuth. The standard use case which is outlined thoroughly in the spec, is a=20 client asking a resource owner for access to their information from the=20 resource server. But, what about the case where a client/resource owner=20 wants to share a particular resource with another, and potentially=20 unregistered, user? An example illustrating what I mean: An application allows users to upload various templates of documents.=20 And, by using an API, a user can send various types of media (e.g.,=20 tweets, FB pictures) to be inserted into said templates, thus creating=20 new documents on the fly. Now, imagine a user in this application has various customers they wish=20 to give access to a certain template. To achieve this, the user creates=20 a token for each customer -- which could be locked down to a certain=20 template, IP, domain, number of uses etc -- and delivers each token to=20 the corresponding customer. Has anything like this been mentioned before? And if so, what was the=20 suggested "dance?" From what I know, I'd imagine using bearer tokens and locking them to=20 some of the conditions listed above would be best, but I'd like a more=20 professional opinion. Thanks, -David Fox PS, after re-reading the spec, I found a typo: Section 2.1: http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.1 The authorization server MAY provider tools to manage such complex=20 clients through a single administration interface. I believe this should be: The authorization server MAY provide tools to manage such complex=20 clients through a single administration interface. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From rboucher@gmail.com Thu Mar 8 15:15:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BD321F85B1 for ; Thu, 8 Mar 2012 15:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw0TYC2G3lFJ for ; Thu, 8 Mar 2012 15:15:45 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBA9721F85AF for ; Thu, 8 Mar 2012 15:15:42 -0800 (PST) Received: by iazz13 with SMTP id z13so1501512iaz.31 for ; Thu, 08 Mar 2012 15:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=0XmdxrOpesVnTZ9P5ACGJldrFmLw4PiItAqKh0kUghw=; b=sX7C41SxlLviokgmYwp5jMBYzFpYjU0INeeCrE45TxOwzEo12qH5wLv7gOP1jDewPl YHFHLfZIHDvpNuxH3ru5xCBbQ5V0uxshw9C4R6tOkdlGnWw23HGd+pt/Dtnf1bb4F41q 9A6iwD+voHGmJZW4sSkdbVIoBIbwahwvJhfgYAm4TBSTlO2Cj5QiEM8IHkzzg7Tw++So wJCuDxnjQssuGQXy3hUZ3ymbrufAXOzYECasfsP6yK5J1Ao+kP4AR7FryQribF4YQIjk IbHVwb4rAgUK1aIZott5p76kqyKXLTkjqIfRKNpx8RYT9l8kkRKFZVyrarQ4+w1s3S2i iSoA== Received: by 10.50.154.130 with SMTP id vo2mr19966783igb.34.1331248542486; Thu, 08 Mar 2012 15:15:42 -0800 (PST) Received: from ip-192-168-1-92.us-west-1.compute.internal (sf-84.stripe.com. [173.247.202.84]) by mx.google.com with ESMTPS id cw5sm36945igc.17.2012.03.08.15.15.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 15:15:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_7047F5B3-B744-4693-B260-FA8DAF845893"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ross Boucher In-Reply-To: <1331190726.92627.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Thu, 8 Mar 2012 15:15:39 -0800 Message-Id: <4CDF0B28-5927-4584-8CAB-98ECCCD42843@gmail.com> References: <1331190726.92627.YahooMailNeo@web31805.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1257) Cc: OAuth WG Subject: Re: [OAUTH-WG] Multiple access tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 23:15:47 -0000 --Apple-Mail=_7047F5B3-B744-4693-B260-FA8DAF845893 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 If the refresh token is revoked, the client application would seem to = have no way to gain access to the third party resource again except = through another explicit user generated authentication. Is that correct? = On some level this may be desirable, since a compromised auth code also = implies that whatever out of band authentication method is being used by = the client has also been compromised. But then that would be true for = all refresh tokens ever issued, rather than just ones stemming from the = "poisoned" auth code. (Also, worth noting that I wasn't talking about user revocation, which = definitely should revoke the refresh token).=20 On Mar 7, 2012, at 11:12 PM, William Mills wrote: > You might want to put issuance time and other info in an access token. = The spec is silent on your first question. >=20 > On revocation: One of the reasons for short lived access tokens is to = only revoke the refresh token, which has to be presented at a central = server type rather than trying to extend revocation to all protected = resources. So if you're in that model you would not bother revoking the = access token. >=20 > The use case I can see for invalidating access tokens and still = honoring refresh tokens is the case where you might have had the access = token symmetric secret compromised but not the refresh token secret. = That's not really user revocation though. I don't se an actual user = revocation of access that would not potentially kill both tokens and = always kill the refresh token. >=20 > =20 >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: Ross Boucher > To: OAuth WG > Cc:=20 > Sent: Wednesday, March 7, 2012 6:14 PM > Subject: [OAUTH-WG] Multiple access tokens >=20 > The spec doesn't seem to have any recommendations on this point, but = should an OAuth v2 API always return the same access token if the same = client makes multiple requests? Is there any benefit to not generating a = new access token for each request? Similarly, if you do generate new = access tokens (as I am doing now), should you also generate new refresh = tokens? >=20 > An unrelated question about revoking access tokens when the same = authorization code is used more than once: should refresh tokens also be = revoked? And, if so, should any tokens issued with that refresh token = then also be revoked? It seems simpler (if slightly less correct) to = just revoke all access tokens for that specific client/resource pair in = that case, rather than tracking the ancestry of all tokens. >=20 > Thanks, > Ross > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_7047F5B3-B744-4693-B260-FA8DAF845893 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKDCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSUwggQNoAMC AQICEHhaMDZMR5ypExZJg/LXXGswDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwNjE3MDAwMDAwWhcNMTIwNjE2MjM1OTU5WjAjMSEwHwYJKoZI hvcNAQkBFhJyYm91Y2hlckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCZZNWQQZ4VOQLdlzFu8WNyc8pv/fKUqWxpx8Dnj/iedgPzNB4tiEhbeeVw3oPnPupOfBclfNM3 uXTT/zzBWn+sayIb2RokjJPoJHJov5ZLzBDcHBRPEmaScjFw1fuoUvTqS2E7RIzLxsqBXD7gPckl /Rq/uABPWD1zwyuhyMJX1h8vyzNwUMMRwL0MaFGxiVURSRvLL3bQlcFCb1WWhJDDQN33VPrFJbJH znXNyadnQCy2bcK4Yme3sh6rDkdSUpMIRGawyjVfpZGG/hc3+MNSVbhLUGeQHCyr42snb0iL3TEx 6sQDYTVT3RgOsatMdHjOy4dafMleQwBds4sagbbVAgMBAAGjggHiMIIB3jAfBgNVHSMEGDAWgBR6 E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUJNsLz5Q4nHALO7c1EeVDF3lL31kwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUF BwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRw Oi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2Rv Y2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYI KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAdBgNVHREEFjAUgRJyYm91Y2hlckBn bWFpbC5jb20wDQYJKoZIhvcNAQEFBQADggEBAGblVXcw0o5MFQdSenk1j7TTcufVTr7GI9gM4//6 lOfTQwEvkD84dZp5As6EKKhmXlhZTM4f+vXL1uUoHyozv5kQja06qGYuPLNhccgo7N3QvIH0CZON 0FUYtfvRVPo4r1UrT9NWQkdgU+Gy1Mom9We7dAhgnY5FYCAOfmA7x3gVOACoA0VormrHMLtEKsn5 CHdMiqO/vr0nuPlmBoABE8L5W5OcoypoO3DP8bvJog6tQ1yG1FUpz+Rzcahkwi/eN+mo8ftAlqPJ qiPOh10grXqtI5+XHPETG8peKsZfW+hRzynfrQkrFZ5sQJ0cBk0lVNXY9dKA9b3ZGsb0IuEuAAUx ggOrMIIDpwIBATCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMT MENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQeFowNkxH nKkTFkmD8tdcazAJBgUrDgMCGgUAoIIB1zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAzMDgyMzE1MzlaMCMGCSqGSIb3DQEJBDEWBBSeG5TUmxgsptbSJRRm6d43 A/1L2zCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhB4WjA2TEecqRMWSYPy11xrMIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQeFowNkxHnKkTFkmD8tdcazANBgkqhkiG9w0BAQEFAASC AQBCI98RQuhz6bkCn64IAKR70ODLUItnNI8qspveX/TFhUUDfdBjxSu0i5t37E1NXen5G/8e0fHZ Hv6WlpXBBk17SJBgWbrt+NL0RI7DRZiAcUTcS0dnTycleVNwZzYKFFyxjKNXcHjA4u6T5xy63GwW g0IIihl2yVMb30+fPQxcwfNFd5W9ixXa+8dp8pogIK/XBoGQe0YJ92xbtZ6e5zvys/ax3hy3PfPj zWAMcO6kEO2LCLrA0RvgWFDEw1QAWs3wvUQ95usjW2deBX9OsjbYvjEd11ScD8kJgNg573V/pEfX VMwfcZrANPDppQdRdU4L15MWauC8VLtWcfKre6bDAAAAAAAA --Apple-Mail=_7047F5B3-B744-4693-B260-FA8DAF845893-- From eran@hueniverse.com Thu Mar 8 15:27:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FC421E8050 for ; Thu, 8 Mar 2012 15:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODXY+rj6tmcz for ; Thu, 8 Mar 2012 15:27:48 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id ED9E021E802D for ; Thu, 8 Mar 2012 15:27:47 -0800 (PST) Received: (qmail 10349 invoked from network); 8 Mar 2012 20:35:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Mar 2012 20:35:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 8 Mar 2012 12:00:20 -0700 From: Eran Hammer To: OAuth WG Date: Thu, 8 Mar 2012 12:00:11 -0700 Thread-Topic: comments on oauth-v2-http-mac-00 Thread-Index: AczHmJ/13itPaFhIQo2FiHtR4prqow1xPJlg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4124@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20222.52252.98949.989974@hagen.valhalla> In-Reply-To: <20222.52252.98949.989974@hagen.valhalla> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] FW: comments on oauth-v2-http-mac-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 23:27:49 -0000 Sending to the full list. -----Original Message----- From: Roger Crew [mailto:crew@cs.stanford.edu]=20 Sent: Saturday, December 31, 2011 12:47 AM To: Eran Hammer-Lahav; Adam Barth; Ben Adida Subject: comments on oauth-v2-http-mac-00 Hi, I have some comments on the now-expired http_hmac draft (oauth-v2-http-mac-= 00), which I figured might be useful, on the assumption you're now working = on a new draft... As for my role, I'm an implementer (... I need a server-side oauth2 framewo= rk, preferably in Perl, and the Perl community / CPAN doesn't really have a= nything here yet, so I'm trying to fill in the gaps...). There are three issues I have with http-hmac draft 00 (and I'll also apolog= ize in advance if any of these have already been beaten to death in prior W= G discussion; I've only been able to look at the last six months of archive= s --- the joys of coming to the party late...). In decreasing order of severity: - - - - - I. Section 3.3.1:=20 =20 would be better if the request-URI portion (item #3) of=20 the normalized request string were ALWAYS just the=20 absolute_path+query_string (i.e., 'abs_path' as defined in 2616, no scheme, no authority; what *normal= ly* gets sent by browsers when proxies are not in use). The problem is that "request-URI as defined by [RFC 2616 5.1.2]" means the = full URI in the case where a proxy is being used, which then means that the= http_hmac implementation has to be able to get at the browser config or ot= herwise have sufficient knowledge of the local network topology to know whe= ther the request is indeed going to be sent via a proxy server (and hence w= hether to include the scheme+authority in the normalized request for the ha= sh computation) -- among other things, this makes life rather difficult for= javascript clients.... ... never mind that the authority (host+port) is already taken care of by i= tems #4 and #5, and the scheme may as well be fixed at "http" (since if https is available there's mostly no reason to be using http_hmac= in the first place). As far as I can tell, there's just no reason to be i= ncluding the full authority a second time in item #3 (and especially not if= the proxy is going to be messing with it). - - - - - II. Section 5.1:=20 In token-issue messages, mac_key should be encoded. (E.g., have the mac_key parameter of OAuth2 token response=20 be the base64url-without-padding encoding of the key,=20 NOT the key itself) Bottom line here is it needs to be possible for the key to be an arbitrary = octet string. This is a security issue since having the character set be r= estricted to 93 printable ASCII characters effectively reduces all key leng= ths by nearly 20%. (It's probably best to think of this in terms of an att= acker doing a brute force search and how big a space s/he needs to cover: 93^n is roughly 256^(0.817n) So for, say, HMAC-SHA1, where the key length is 20 bytes, a plainstring key= will actually need to be at least 25 bytes to achieve the same level of pr= otection.) At the very least, this needs to be mentioned under Security Considerations= , so that if you really *do* need keys to be plainstring for some reason, i= mplementers will at least know to lengthen them accordingly. But you're also assuming that the character set restriction for the key wil= l not be exploitable in some way beyond the reduction of the search space (= i.e., due to some yet-to-be-discovered weakness in the SHA family) -- I'll = admit this seems unlikely, but I'm not sure I'd want to bet the farm on tha= t, especially once SHA1 gets nearer the end of its useful life as the vario= us weaknesses turn up... Better to just have the extra (trivial) encoding/decoding steps be specifie= d. That way the key can be anything at all, and whatever weaknesses might = exist in HMAC-SHA{1,256} will be the same as for everybody else that uses t= hese algorithms (i.e., you won't be introducing potential new ones...) - - - - - III. Sections 3.3.2, 3.3.3 (and 5.1 if you agree with the previous point): Use base64url (rfc4648) without padding instead of straight=20 base64 (rfc2045) to encode arbitrary octet strings Straight base64 was designed for use in email. Base64url-no-padding is bet= ter in HTTP contexts for not using '+', '/', and '=3D'. =20 And I'll grant this doesn't necessarily matter for the Authorization header= , but it *does* matter for the POST body and URI parameter lists, being abl= e to pass http_hmac tokens as parameters is an obvious and useful extension= (the bearer spec already does this), and it's less confusing if you have a= uniform specification where you're using the same encoding everywhere. Meanwhile, '=3D'-padding is only necessary in cases where it otherwise migh= t not be clear where the string ends -- again true in email contexts, but d= efinitely NOT the case for HTTP quoted string syntax. - - - - - I also had things to say about 'body_hash', but I now see that you're dropp= ing that (to which my general reaction is basically, YAY, THANK YOU... 'ext= ' should be enough to play with). and thanks for your time. -- Roger Crew crew@cs.stanford.edu From torsten@lodderstedt.net Sat Mar 10 03:52:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D744121F861C for ; Sat, 10 Mar 2012 03:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6prHTSrSJa5 for ; Sat, 10 Mar 2012 03:52:37 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9994B21F85A8 for ; Sat, 10 Mar 2012 03:52:35 -0800 (PST) Received: from [91.2.79.237] (helo=[192.168.71.36]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1S6Kqf-0002vp-4W; Sat, 10 Mar 2012 12:52:33 +0100 Message-ID: <4F5B407D.3060902@lodderstedt.net> Date: Sat, 10 Mar 2012 12:52:29 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ross Boucher References: <1331190726.92627.YahooMailNeo@web31805.mail.mud.yahoo.com> <4CDF0B28-5927-4584-8CAB-98ECCCD42843@gmail.com> In-Reply-To: <4CDF0B28-5927-4584-8CAB-98ECCCD42843@gmail.com> Content-Type: multipart/alternative; boundary="------------030006010201060307080601" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: OAuth WG Subject: Re: [OAUTH-WG] Multiple access tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 11:52:38 -0000 This is a multi-part message in MIME format. --------------030006010201060307080601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 09.03.2012 00:15, schrieb Ross Boucher: > If the refresh token is revoked, the client application would seem to have no way to gain access to the third party resource again except through another explicit user generated authentication. Is that correct? On some level this may be desirable, since a compromised auth code also implies that whatever out of band authentication method is being used by the client has also been compromised. But then that would be true for all refresh tokens ever issued, rather than just ones stemming from the "poisoned" auth code. Why? my assumption would be that the attacker gained access to that particular authorization code (e.g. by wire tapping). This does not mean other refresh tokens for the same or other users have been comprimized as well. regards, Torsten. > > (Also, worth noting that I wasn't talking about user revocation, which definitely should revoke the refresh token). > > On Mar 7, 2012, at 11:12 PM, William Mills wrote: > >> You might want to put issuance time and other info in an access token. The spec is silent on your first question. >> >> On revocation: One of the reasons for short lived access tokens is to only revoke the refresh token, which has to be presented at a central server type rather than trying to extend revocation to all protected resources. So if you're in that model you would not bother revoking the access token. >> >> The use case I can see for invalidating access tokens and still honoring refresh tokens is the case where you might have had the access token symmetric secret compromised but not the refresh token secret. That's not really user revocation though. I don't se an actual user revocation of access that would not potentially kill both tokens and always kill the refresh token. >> >> >> >> >> >> >> ----- Original Message ----- >> From: Ross Boucher >> To: OAuth WG >> Cc: >> Sent: Wednesday, March 7, 2012 6:14 PM >> Subject: [OAUTH-WG] Multiple access tokens >> >> The spec doesn't seem to have any recommendations on this point, but should an OAuth v2 API always return the same access token if the same client makes multiple requests? Is there any benefit to not generating a new access token for each request? Similarly, if you do generate new access tokens (as I am doing now), should you also generate new refresh tokens? >> >> An unrelated question about revoking access tokens when the same authorization code is used more than once: should refresh tokens also be revoked? And, if so, should any tokens issued with that refresh token then also be revoked? It seems simpler (if slightly less correct) to just revoke all access tokens for that specific client/resource pair in that case, rather than tracking the ancestry of all tokens. >> >> Thanks, >> Ross >> _______________________________________________ >> 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 --------------030006010201060307080601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Am 09.03.2012 00:15, schrieb Ross Boucher: 
If the refresh token is revoked, the client application would seem to have no way to gain access to the third party resource again except through another explicit user generated authentication. Is that correct? On some level this may be desirable, since a compromised auth code also implies that whatever out of band authentication method is being used by the client has also been compromised. But then that would be true for all refresh tokens ever issued, rather than just ones stemming from the "poisoned" auth code.

Why? my assumption would be that the attacker gained access to that particular authorization code (e.g. by wire tapping). This does not mean other refresh tokens for the same or other users have been comprimized as well.

regards,
Torsten.


(Also, worth noting that I wasn't talking about user revocation, which definitely should revoke the refresh token). 

On Mar 7, 2012, at 11:12 PM, William Mills wrote:


You might want to put issuance time and other info in an access token.  The spec is silent on your first question.

On revocation: One of the reasons for short lived access tokens is to only revoke the refresh token, which has to be presented at a central server type rather than trying to extend revocation to all protected resources.  So if you're in that model you would not bother revoking the access token.

The use case I can see for invalidating access tokens and still honoring refresh tokens is the case where you might have had the access token symmetric secret compromised but not the refresh token secret.  That's not really user revocation though.  I don't se an actual user revocation of access that would not potentially kill both tokens and always kill the refresh token.

 




----- Original Message -----
From: Ross Boucher <rboucher@gmail.com>
To: OAuth WG <oauth@ietf.org>
Cc: 
Sent: Wednesday, March 7, 2012 6:14 PM
Subject: [OAUTH-WG] Multiple access tokens

The spec doesn't seem to have any recommendations on this point, but should an OAuth v2 API always return the same access token if the same client makes multiple requests? Is there any benefit to not generating a new access token for each request? Similarly, if you do generate new access tokens (as I am doing now), should you also generate new refresh tokens?

An unrelated question about revoking access tokens when the same authorization code is used more than once: should refresh tokens also be revoked? And, if so, should any tokens issued with that refresh token then also be revoked? It seems simpler (if slightly less correct) to just revoke all access tokens for that specific client/resource pair in that case, rather than tracking the ancestry of all tokens.

Thanks,
Ross
_______________________________________________
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


    

  


--------------030006010201060307080601--

From Michael.Jones@microsoft.com  Sat Mar 10 09:49:58 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D7321F8581 for ; Sat, 10 Mar 2012 09:49:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.758
X-Spam-Level: 
X-Spam-Status: No, score=-3.758 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2V2oB0kxnkt for ; Sat, 10 Mar 2012 09:49:53 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2D17E21F857A for ; Sat, 10 Mar 2012 09:49:53 -0800 (PST)
Received: from mail125-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Sat, 10 Mar 2012 17:49:52 +0000
Received: from mail125-ch1 (localhost [127.0.0.1])	by mail125-ch1-R.bigfish.com (Postfix) with ESMTP id 6DA5C1E0174; Sat, 10 Mar 2012 17:49:52 +0000 (UTC)
X-SpamScore: -39
X-BigFish: VS-39(zzbb2dI9371I1458K542Mc85dh1418M98dK4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail125-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail125-ch1 (localhost.localdomain [127.0.0.1]) by mail125-ch1 (MessageSwitch) id 1331401790391512_26324; Sat, 10 Mar 2012 17:49:50 +0000 (UTC)
Received: from CH1EHSMHS027.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253])	by mail125-ch1.bigfish.com (Postfix) with ESMTP id 5B4D660049;	Sat, 10 Mar 2012 17:49:50 +0000 (UTC)
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 10 Mar 2012 17:49:49 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0283.004; Sat, 10 Mar 2012 17:49:48 +0000
From: Mike Jones 
To: Paul Madsen , Brian Campbell 
Thread-Topic: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
Thread-Index: Acz+5iVDrCTPgxV5SN6Lz5LGZyUUHQ==
Date: Sat, 10 Mar 2012 17:49:47 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366402261@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366402261TK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: oauth 
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Mar 2012 17:49:58 -0000

--_000_4E1F6AAD24975D4BA5B168042967394366402261TK5EX14MBXC284r_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I plan to make the change to the example access token value to mF_9.B5f-4.1=
JqM before Monday's submission deadline, per the requests for b64token synt=
ax clarification.  I'm also considering adding an access token response exa=
mple, pre the requests in this thread.  I would propose adding the followin=
g new text for this in a new Section 4 (before the current Security Conside=
rations).  This is largely parallel to what is done in Section 5.1 of the M=
AC spec.

4.  Example Access Token Response

Typically a bearer token is returned to the client as part of an OAuth 2.0 =
[I-D.ietf-oauth-v2] access token response. An example of such as response i=
s:


     HTTP/1.1 200 OK

     Content-Type: application/json;charset=3DUTF-8

     Cache-Control: no-store

     Pragma: no-cache



     {

       "access_token":"mF_9.B5f-4.1JqM",

       "token_type":"Bearer",

       "expires_in":3600,

       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"

     }

Please send either +1s or objections to this text by mid-day Monday.  Unles=
s I receive several +1s, to be conservative at this point, I will not be in=
cluding it in Monday's draft.

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P=
aul Madsen
Sent: Wednesday, March 07, 2012 1:34 PM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oa=
uth-v2-bearer

+1

On 3/7/12 4:08 PM, Brian Campbell wrote:

Yeah, it is case insensitive. I just went with the upper case B

because that's how it was written in =A75.1.1 of

draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually

defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.

Either one would be fine.



I agree that an example response from the token endpoint would be

worthwhile.  Something like the following might help tie together with

the Authorization header example (proposed earlier). It could maybe be

worked in near the top of =A72?



     HTTP/1.1 200 OK

     Content-Type: application/json;charset=3DUTF-8

     Cache-Control: no-store

     Pragma: no-cache



     {

       "access_token":"vF_9.5dCf-t4.qbcmT_k1b",

       "token_type":"example",

       "expires_in":3600,

       "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA",

     }



It'd probably make sense to change the examples in the body =A72.2***

and query =A72.3**** to use the same access token value too.





* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1

** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1

*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2

**** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3





On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer  wrote:

Makes sense to me, except that I think the token_type value is typically

lowercase "bearer", though it's defined to be case insensitive in

Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value o=
f

this field for the Bearer token type ever got defined anywhere. Section 7.1

references the bearer spec as defining the value of the "token_type"

parameter, and passes its example as if by reference. Would be worthwhile

giving an example of a token endpoint response, such as what's found in

OAuth-v2-23 section 5.1.



 -- Justin





On 03/07/2012 12:16 PM, Brian Campbell wrote:



I'd like to propose the following changes and additions, derived

largely from Bill and James suggestions, to

draft-ietf-oauth-v2-bearer-17.  These changes have no normative impact

and only aim to add additional clarity and explanation the workings

and implications of the current spec.  I'm definitely open to changes

or improvements in the wording here (not my strong suit by any means)

but I think it's important that these general ideas be conveyed in the

draft.





=3D=3D>  Insert the following text at the beginning of =A72:



To make a protected resource request, the client must be in possession

of a valid bearer token. Typically a bearer token is returned to the

client as part of an access token response as defined in OAuth 2.0

[I-D.ietf-oauth-v2]. When the "token_type" parameter of the access

token response is "Bearer", the string value of the "access_token"

parameter becomes the bearer access token used to make protected

resource requests.



=3D=3D>  Change the value of the token in the Authorization header example =
to

this:



Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b



=3D=3D>  Insert the following text before the last paragraph of =A72.1:



Note that the name b64token does not imply base64 encoding but rather

is the name for an ABNF syntax definition from HTTP/1.1, Part 7

[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"

string value from an access token response MUST match the b64token

ABNF so it can be used with the Bearer HTTP scheme.





Thanks,

Brian









On Tue, Mar 6, 2012 at 11:45 AM, William Mills

 wrote:



Yeah, something as simple as, "Note that the name 'b64token' does not

imply

base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would

do

it.



-bill



________________________________

From: Brian Campbell

To: Mike Jones

Cc: oauth

Sent: Tuesday, March 6, 2012 8:23 AM



Subject: Re: [OAUTH-WG] question about the b64token syntax in

draft-ietf-oauth-v2-bearer



Thanks Mike, I think changing the example would be helpful.



However I think that including some text along the lines of what James

suggested would also be very valuable. I agree that the connection

between OAuth and Bearer could and should be made more explicit. And

that the implications of the b64token syntax, particularly on what AS

can use to construct ATs, could/should be made more clear.



I can propose some specific text (building on James') if others in the WG

agree?





On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones

wrote:



I'm fine with changing the example to make it clearer that b64token

allows

a wider range of characters than just those legal for base64 and

base64url

encodings of data values.



I'll add it to my to-do list for any additional edits for the Bearer

spec.



                               -- Mike



-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf

Of

Manger, James H

Sent: Monday, March 05, 2012 3:33 PM

To: Brian Campbell; oauth

Subject: Re: [OAUTH-WG] question about the b64token syntax in

draft-ietf-oauth-v2-bearer



Brian,



On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer

Tokens"* I've encountered several people (including myself) who have

made the assumption that the name b64token implies that some kind of

base64 encoding/decoding on the access token is taking place between

the client and RS.



Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,

however, I see that b64token is just an ABNF syntax definition

allowing for characters typically used in base64, base64url, etc.. So

the b64token doesn't define any encoding or decoding but rather just

defines what characters can be used in the part of the Authorization

header that will contain the access token.



Do I read this correctly?



Yes.



If so, I feel like some additional clarifying text in the Bearer

Tokens draft might help avoid what is (based on my small sample) a

common point of misunderstanding.



Changing the example bearer token should be a simple way to avoid some

confusion by showing that it does not have to be base64 encoding. How

about

changing:

 Authorization: Bearer vF9dft4qmT

to

 Authorization: Bearer vF9.dft4.qmT



The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't

quite manage to be precise about how OAuth and Bearer connect. It could

explicitly state that the string value of the "access_token" member of

an

access token response is the bearer token. The "access_token" string

value

(after unescaping any JSON-escapes) MUST match the b64token ABNF so it

can

be used with the Bearer HTTP scheme. Such text could be put in =A75.1.1

where

the "Bearer" OAuth access token type is defined.





Also, does the use of b64token implicitly limit the allowed characters

that an AS can use to construct a bearer access token?



Yes.





* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1

**

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1



--

James Manger

_______________________________________________

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

--_000_4E1F6AAD24975D4BA5B168042967394366402261TK5EX14MBXC284r_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I plan to make the change=
 to the example access token value to
mF_9=
.B5f-4.1JqM before Monday’s submiss=
ion deadline, per the requests for b64token syntax clarification.  I&#=
8217;m also
 considering adding an access token response example, pre the requests in t=
his thread.  I would propose adding the following new text for this in=
 a new Section 4 (before the current Security Considerations).  This i=
s largely parallel to what is done in Section
 5.1 of the MAC spec.


 <=
/p>

4.  Example Access Token Response=



 


Typically a bearer token is returned to the cl=
ient as part of an OAuth 2.0 [I-D.ietf-oauth-v2] access token response. An =
example of such as response is:


 


     HTTP/1.1 200 OK

     Content-Type: application/json;char=
set=3DUTF-8


     Cache-Control: no-store<=
/span>


     Pragma: no-cache<=
/p>

 


     {


       "access_token"=
;:"mF_9.B5f-4.1JqM",


       "token_type":=
"Bearer",


       "expires_in":=
3600,


       "refresh_token&quo=
t;:"tGzv3JOkF0XG5Qx2TlKWIA"


     }


 <=
/p>

Please send either +1=
s or objections to this text by mid-day Monday.  Unless I receive seve=
ral +1s, to be conservative at this point, I will not be including
 it in Monday’s draft.


 <=
/p>

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


 <=
/p>





From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf=
.org]
On Behalf Of Paul Madsen

Sent: Wednesday, March 07, 2012 1:34 PM

To: Brian Campbell

Cc: oauth

Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-=
ietf-oauth-v2-bearer






 


+1



On 3/7/12 4:08 PM, Brian Campbell wrote: 


Yeah, it is case insensitive. I just went with the upper case B


because that's how it was written in =A75.1.1 of


draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually


defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.<=
/o:p>


Either one would be fine.


 


I agree that an example response from the token endpoint would be=



worthwhile.  Something like the following might help tie together=
 with


the Authorization header example (proposed earlier). It could maybe be=



worked in near the top of =A72?


 


     HTTP/1.1 200 OK


     Content-Type: application/json;charset=3DUTF-=
8


     Cache-Control: no-store


     Pragma: no-cache


 


     {


       "access_token":"vF=
_9.5dCf-t4.qbcmT_k1b",


       "token_type":"exam=
ple",


       "expires_in":3600,=



       "refresh_token":"s=
tGzv3xOdkF0X35Qp2TlKWIA",


     }


 


It'd probably make sense to change the examples in the body =A72.2***<=
o:p>


and query =A72.3**** to use the same access token value too.


 


 


* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#sec=
tion-5.1.1


** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1


*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#sec=
tion-2.2


**** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#se=
ction-2.3


 


 


On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer <jricher@mitre.org> wrote:




Makes sense to me, except that I think the token_type value is typical=
ly


lowercase "bearer", though it's defined to be case insensiti=
ve in


Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the va=
lue of


this field for the Bearer token type ever got defined anywhere. Sectio=
n 7.1


references the bearer spec as defining the value of the "token_ty=
pe"


parameter, and passes its example as if by reference. Would be worthwh=
ile


giving an example of a token endpoint response, such as what's found i=
n


OAuth-v2-23 section 5.1.


 


 -- Justin


 


 


On 03/07/2012 12:16 PM, Brian Campbell wrote:




 


I'd like to propose the following changes and additions, derived<=
/o:p>


largely from Bill and James suggestions, to


draft-ietf-oauth-v2-bearer-17.  These changes have no normative i=
mpact


and only aim to add additional clarity and explanation the workings


and implications of the current spec.  I'm definitely open to cha=
nges


or improvements in the wording here (not my strong suit by any means)<=
o:p>


but I think it's important that these general ideas be conveyed in the=



draft.


 


 


=3D=3D>  Insert the following text at the beginning of =A72:


 


To make a protected resource request, the client must be in possession=



of a valid bearer token. Typically a bearer token is returned to the


client as part of an access token response as defined in OAuth 2.0


[I-D.ietf-oauth-v2]. When the "token_type" parameter of the =
access


token response is "Bearer", the string value of the "ac=
cess_token"


parameter becomes the bearer access token used to make protected<=
/o:p>


resource requests.


 


=3D=3D>  Change the value of the token in the Authorization he=
ader example to


this:


 


Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b


 


=3D=3D>  Insert the following text before the last paragraph o=
f =A72.1:


 


Note that the name b64token does not imply base64 encoding but rather<=
o:p>


is the name for an ABNF syntax definition from HTTP/1.1, Part 7


[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token=
"


string value from an access token response MUST match the b64token


ABNF so it can be used with the Bearer HTTP scheme.


 


 


Thanks,


Brian


 


 


 


 


On Tue, Mar 6, 2012 at 11:45 AM, William Mills<wmills@yahoo-inc.com>


 wrote:




 


Yeah, something as simple as, "Note that the name 'b64token' does=
 not


imply


base64 encoding, see the definition in [[INSERT REFERENCE HERE]]."=
; would


do


it.


 


-bill


 


________________________________


From: Brian Campbell<=
bcampbell@pingidentity.com>


To: Mike Jones<Micha=
el.Jones@microsoft.com>


Cc: oauth<oauth@ietf.org><=
o:p>


Sent: Tuesday, March 6, 2012 8:23 AM


 


Subject: Re: [OAUTH-WG] question about the b64token syntax in


draft-ietf-oauth-v2-bearer


 


Thanks Mike, I think changing the example would be helpful.=



 


However I think that including some text along the lines of what James=



suggested would also be very valuable. I agree that the connection


between OAuth and Bearer could and should be made more explicit. And


that the implications of the b64token syntax, particularly on what AS<=
o:p>


can use to construct ATs, could/should be made more clear.<=
/pre>

 


I can propose some specific text (building on James') if others in the=
 WG


agree?


 


 


On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones<Michael.Jones@microsoft.com>


wrote:




 


I'm fine with changing the example to make it clearer that b64token


allows


a wider range of characters than just those legal for base64 and<=
/o:p>


base64url


encodings of data values.


 


I'll add it to my to-do list for any additional edits for the Bearer


spec.


 


                    =
           -- Mike


 


-----Original Message-----


From: oauth-bounces@ietf.org=
 [mailto:oauth-bounces@ietf.o=
rg] On Behalf


Of


Manger, James H


Sent: Monday, March 05, 2012 3:33 PM


To: Brian Campbell; oauth


Subject: Re: [OAUTH-WG] question about the b64token syntax in


draft-ietf-oauth-v2-bearer


 


Brian,


 




On casual reading of "The OAuth 2.0 Authorization Protocol: Beare=
r


Tokens"* I've encountered several people (including myself) who h=
ave


made the assumption that the name b64token implies that some kind of


base64 encoding/decoding on the access token is taking place between


the client and RS.


 


Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"=
;**,


however, I see that b64token is just an ABNF syntax definition


allowing for characters typically used in base64, base64url, etc.. So<=
o:p>


the b64token doesn't define any encoding or decoding but rather just


defines what characters can be used in the part of the Authorization


header that will contain the access token.


 


Do I read this correctly?




 


Yes.


 




If so, I feel like some additional clarifying text in the Bearer<=
/o:p>


Tokens draft might help avoid what is (based on my small sample) a


common point of misunderstanding.




 


Changing the example bearer token should be a simple way to avoid some=



confusion by showing that it does not have to be base64 encoding. How<=
o:p>


about


changing:


 Authorization: Bearer vF9dft4qmT


to


 Authorization: Bearer vF9.dft4.qmT


 


The Bearer spec has lots of (unnecessary) text about OAuth, but doesn'=
t


quite manage to be precise about how OAuth and Bearer connect. It coul=
d


explicitly state that the string value of the "access_token"=
 member of


an


access token response is the bearer token. The "access_token"=
; string


value


(after unescaping any JSON-escapes) MUST match the b64token ABNF so it=



can


be used with the Bearer HTTP scheme. Such text could be put in =A75.1.=
1


where


the "Bearer" OAuth access token type is defined.<=
/pre>

 


 




Also, does the use of b64token implicitly limit the allowed characters=



that an AS can use to construct a bearer access token?



 


Yes.


 


 




* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#secti=
on-2.1


**


http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section=
-2.1




 


--


James Manger


_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth


 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth


 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth




 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth






--_000_4E1F6AAD24975D4BA5B168042967394366402261TK5EX14MBXC284r_--

From Michael.Jones@microsoft.com  Sat Mar 10 09:52:19 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5634421F85A0 for ; Sat, 10 Mar 2012 09:52:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.254
X-Spam-Level: 
X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[AWL=1.344,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+Lf9vIMTY1D for ; Sat, 10 Mar 2012 09:52:14 -0800 (PST)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 517D521F8599 for ; Sat, 10 Mar 2012 09:52:14 -0800 (PST)
Received: from mail86-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Sat, 10 Mar 2012 17:52:13 +0000
Received: from mail86-tx2 (localhost [127.0.0.1])	by mail86-tx2-R.bigfish.com (Postfix) with ESMTP id 8846F1A0125; Sat, 10 Mar 2012 17:52:13 +0000 (UTC)
X-SpamScore: -39
X-BigFish: VS-39(zzbb2dI9371I1458K542Mc85dh1418M98dK4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail86-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail86-tx2 (localhost.localdomain [127.0.0.1]) by mail86-tx2 (MessageSwitch) id 1331401931313222_19203; Sat, 10 Mar 2012 17:52:11 +0000 (UTC)
Received: from TX2EHSMHS046.bigfish.com (unknown [10.9.14.242])	by mail86-tx2.bigfish.com (Postfix) with ESMTP id 3E286A0043; Sat, 10 Mar 2012 17:52:11 +0000 (UTC)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS046.bigfish.com (10.9.99.146) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 10 Mar 2012 17:52:10 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0283.004; Sat, 10 Mar 2012 17:52:09 +0000
From: Mike Jones 
To: Hannes Tschofenig , Barry Leiba 
Thread-Topic: OK to post updated Bearer spec changing and adding examples?
Thread-Index: Acz+5oMVvRgdTq3QTHKs5zQd2PxV0A==
Date: Sat, 10 Mar 2012 17:52:08 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366404286@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366404286TK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "oauth@ietf.org" 
Subject: [OAUTH-WG] OK to post updated Bearer spec changing and adding examples?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Mar 2012 17:52:19 -0000

--_000_4E1F6AAD24975D4BA5B168042967394366404286TK5EX14MBXC284r_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

OAuth Chairs,

Do you approve of posting an updated Bearer spec as below, assuming the wor=
king group does not object by mid-day Monday?

                                                            -- Mike

From: Mike Jones
Sent: Saturday, March 10, 2012 9:50 AM
To: 'Paul Madsen'; Brian Campbell
Cc: oauth
Subject: RE: [OAUTH-WG] question about the b64token syntax in draft-ietf-oa=
uth-v2-bearer

I plan to make the change to the example access token value to mF_9.B5f-4.1=
JqM before Monday's submission deadline, per the requests for b64token synt=
ax clarification.  I'm also considering adding an access token response exa=
mple, pre the requests in this thread.  I would propose adding the followin=
g new text for this in a new Section 4 (before the current Security Conside=
rations).  This is largely parallel to what is done in Section 5.1 of the M=
AC spec.

4.  Example Access Token Response

Typically a bearer token is returned to the client as part of an OAuth 2.0 =
[I-D.ietf-oauth-v2] access token response. An example of such as response i=
s:


     HTTP/1.1 200 OK

     Content-Type: application/json;charset=3DUTF-8

     Cache-Control: no-store

     Pragma: no-cache



     {

       "access_token":"mF_9.B5f-4.1JqM",

       "token_type":"Bearer",

       "expires_in":3600,

       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"

     }

Please send either +1s or objections to this text by mid-day Monday.  Unles=
s I receive several +1s, to be conservative at this point, I will not be in=
cluding it in Monday's draft.

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Paul =
Madsen
Sent: Wednesday, March 07, 2012 1:34 PM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oa=
uth-v2-bearer

+1

On 3/7/12 4:08 PM, Brian Campbell wrote:

Yeah, it is case insensitive. I just went with the upper case B

because that's how it was written in =A75.1.1 of

draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually

defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.

Either one would be fine.



I agree that an example response from the token endpoint would be

worthwhile.  Something like the following might help tie together with

the Authorization header example (proposed earlier). It could maybe be

worked in near the top of =A72?



     HTTP/1.1 200 OK

     Content-Type: application/json;charset=3DUTF-8

     Cache-Control: no-store

     Pragma: no-cache



     {

       "access_token":"vF_9.5dCf-t4.qbcmT_k1b",

       "token_type":"example",

       "expires_in":3600,

       "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA",

     }



It'd probably make sense to change the examples in the body =A72.2***

and query =A72.3**** to use the same access token value too.





* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1

** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1

*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2

**** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3





On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer  wrote:

Makes sense to me, except that I think the token_type value is typically

lowercase "bearer", though it's defined to be case insensitive in

Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value o=
f

this field for the Bearer token type ever got defined anywhere. Section 7.1

references the bearer spec as defining the value of the "token_type"

parameter, and passes its example as if by reference. Would be worthwhile

giving an example of a token endpoint response, such as what's found in

OAuth-v2-23 section 5.1.



 -- Justin





On 03/07/2012 12:16 PM, Brian Campbell wrote:



I'd like to propose the following changes and additions, derived

largely from Bill and James suggestions, to

draft-ietf-oauth-v2-bearer-17.  These changes have no normative impact

and only aim to add additional clarity and explanation the workings

and implications of the current spec.  I'm definitely open to changes

or improvements in the wording here (not my strong suit by any means)

but I think it's important that these general ideas be conveyed in the

draft.





=3D=3D>  Insert the following text at the beginning of =A72:



To make a protected resource request, the client must be in possession

of a valid bearer token. Typically a bearer token is returned to the

client as part of an access token response as defined in OAuth 2.0

[I-D.ietf-oauth-v2]. When the "token_type" parameter of the access

token response is "Bearer", the string value of the "access_token"

parameter becomes the bearer access token used to make protected

resource requests.



=3D=3D>  Change the value of the token in the Authorization header example =
to

this:



Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b



=3D=3D>  Insert the following text before the last paragraph of =A72.1:



Note that the name b64token does not imply base64 encoding but rather

is the name for an ABNF syntax definition from HTTP/1.1, Part 7

[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"

string value from an access token response MUST match the b64token

ABNF so it can be used with the Bearer HTTP scheme.





Thanks,

Brian









On Tue, Mar 6, 2012 at 11:45 AM, William Mills

 wrote:



Yeah, something as simple as, "Note that the name 'b64token' does not

imply

base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would

do

it.



-bill



________________________________

From: Brian Campbell

To: Mike Jones

Cc: oauth

Sent: Tuesday, March 6, 2012 8:23 AM



Subject: Re: [OAUTH-WG] question about the b64token syntax in

draft-ietf-oauth-v2-bearer



Thanks Mike, I think changing the example would be helpful.



However I think that including some text along the lines of what James

suggested would also be very valuable. I agree that the connection

between OAuth and Bearer could and should be made more explicit. And

that the implications of the b64token syntax, particularly on what AS

can use to construct ATs, could/should be made more clear.



I can propose some specific text (building on James') if others in the WG

agree?





On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones

wrote:



I'm fine with changing the example to make it clearer that b64token

allows

a wider range of characters than just those legal for base64 and

base64url

encodings of data values.



I'll add it to my to-do list for any additional edits for the Bearer

spec.



                               -- Mike



-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf

Of

Manger, James H

Sent: Monday, March 05, 2012 3:33 PM

To: Brian Campbell; oauth

Subject: Re: [OAUTH-WG] question about the b64token syntax in

draft-ietf-oauth-v2-bearer



Brian,



On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer

Tokens"* I've encountered several people (including myself) who have

made the assumption that the name b64token implies that some kind of

base64 encoding/decoding on the access token is taking place between

the client and RS.



Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,

however, I see that b64token is just an ABNF syntax definition

allowing for characters typically used in base64, base64url, etc.. So

the b64token doesn't define any encoding or decoding but rather just

defines what characters can be used in the part of the Authorization

header that will contain the access token.



Do I read this correctly?



Yes.



If so, I feel like some additional clarifying text in the Bearer

Tokens draft might help avoid what is (based on my small sample) a

common point of misunderstanding.



Changing the example bearer token should be a simple way to avoid some

confusion by showing that it does not have to be base64 encoding. How

about

changing:

 Authorization: Bearer vF9dft4qmT

to

 Authorization: Bearer vF9.dft4.qmT



The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't

quite manage to be precise about how OAuth and Bearer connect. It could

explicitly state that the string value of the "access_token" member of

an

access token response is the bearer token. The "access_token" string

value

(after unescaping any JSON-escapes) MUST match the b64token ABNF so it

can

be used with the Bearer HTTP scheme. Such text could be put in =A75.1.1

where

the "Bearer" OAuth access token type is defined.





Also, does the use of b64token implicitly limit the allowed characters

that an AS can use to construct a bearer access token?



Yes.





* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1

**

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1



--

James Manger

_______________________________________________

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

--_000_4E1F6AAD24975D4BA5B168042967394366404286TK5EX14MBXC284r_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











OAuth Chairs,<=
/span>


 <=
/p>

Do you approve of posting=
 an updated Bearer spec as below, assuming the working group does not objec=
t by mid-day Monday?


 <=
/p>

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


 <=
/p>





From: Mike Jones


Sent: Saturday, March 10, 2012 9:50 AM

To: 'Paul Madsen'; Brian Campbell

Cc: oauth

Subject: RE: [OAUTH-WG] question about the b64token syntax in draft-=
ietf-oauth-v2-bearer






 


I plan to make the change=
 to the example access token value to
mF_9.B5f-4.1JqM<=
/span> before Monday’s submission deadline=
, per the requests for b64token syntax clarification.  I’m also =
considering
 adding an access token response example, pre the requests in this thread.&=
nbsp; I would propose adding the following new text for this in a new Secti=
on 4 (before the current Security Considerations).  This is largely pa=
rallel to what is done in Section 5.1 of the
 MAC spec.


 <=
/p>

4.  Example Access Token Response


 


Typically a bearer token is returned to the client as part=
 of an OAuth 2.0 [I-D.ietf-oauth-v2] access token response. An example of s=
uch as response is:


 


     HTTP/1.1 200 OK

     Content-Type: application/json;char=
set=3DUTF-8


     Cache-Control: no-store<=
/span>


     Pragma: no-cache<=
/p>

 


     {


       "access_token"=
;:"mF_9.B5f-4.1JqM",


       "token_type":=
"Bearer",


       "expires_in":=
3600,


       "refresh_token&quo=
t;:"tGzv3JOkF0XG5Qx2TlKWIA"


     }


 <=
/p>

Please send either +1=
s or objections to this text by mid-day Monday.  Unless I receive seve=
ral +1s, to be conservative at this point, I will not be including
 it in Monday’s draft.


 <=
/p>

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


 <=
/p>





From:
oauth-bounces@ietf.org 
[mailto:oauth-bounces@ietf.org] On Behalf Of Paul Madsen

Sent: Wednesday, March 07, 2012 1:34 PM

To: Brian Campbell

Cc: oauth

Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-=
ietf-oauth-v2-bearer






 


+1



On 3/7/12 4:08 PM, Brian Campbell wrote: 


Yeah, it is case insensitive. I just went with the upper case B


because that's how it was written in =A75.1.1 of


draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually


defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.<=
/o:p>


Either one would be fine.


 


I agree that an example response from the token endpoint would be=



worthwhile.  Something like the following might help tie together=
 with


the Authorization header example (proposed earlier). It could maybe be=



worked in near the top of =A72?


 


     HTTP/1.1 200 OK


     Content-Type: application/json;charset=3DUTF-=
8


     Cache-Control: no-store


     Pragma: no-cache


 


     {


       "access_token":"vF=
_9.5dCf-t4.qbcmT_k1b",


       "token_type":"exam=
ple",


       "expires_in":3600,=



       "refresh_token":"s=
tGzv3xOdkF0X35Qp2TlKWIA",


     }


 


It'd probably make sense to change the examples in the body =A72.2***<=
o:p>


and query =A72.3**** to use the same access token value too.


 


 


* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#sec=
tion-5.1.1


** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1


*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#sec=
tion-2.2


**** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#se=
ction-2.3


 


 


On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer <jricher@mitre.org> wrote:




Makes sense to me, except that I think the token_type value is typical=
ly


lowercase "bearer", though it's defined to be case insensiti=
ve in


Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the va=
lue of


this field for the Bearer token type ever got defined anywhere. Sectio=
n 7.1


references the bearer spec as defining the value of the "token_ty=
pe"


parameter, and passes its example as if by reference. Would be worthwh=
ile


giving an example of a token endpoint response, such as what's found i=
n


OAuth-v2-23 section 5.1.


 


 -- Justin


 


 


On 03/07/2012 12:16 PM, Brian Campbell wrote:




 


I'd like to propose the following changes and additions, derived<=
/o:p>


largely from Bill and James suggestions, to


draft-ietf-oauth-v2-bearer-17.  These changes have no normative i=
mpact


and only aim to add additional clarity and explanation the workings


and implications of the current spec.  I'm definitely open to cha=
nges


or improvements in the wording here (not my strong suit by any means)<=
o:p>


but I think it's important that these general ideas be conveyed in the=



draft.


 


 


=3D=3D>  Insert the following text at the beginning of =A72:


 


To make a protected resource request, the client must be in possession=



of a valid bearer token. Typically a bearer token is returned to the


client as part of an access token response as defined in OAuth 2.0


[I-D.ietf-oauth-v2]. When the "token_type" parameter of the =
access


token response is "Bearer", the string value of the "ac=
cess_token"


parameter becomes the bearer access token used to make protected<=
/o:p>


resource requests.


 


=3D=3D>  Change the value of the token in the Authorization he=
ader example to


this:


 


Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b


 


=3D=3D>  Insert the following text before the last paragraph o=
f =A72.1:


 


Note that the name b64token does not imply base64 encoding but rather<=
o:p>


is the name for an ABNF syntax definition from HTTP/1.1, Part 7


[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token=
"


string value from an access token response MUST match the b64token


ABNF so it can be used with the Bearer HTTP scheme.


 


 


Thanks,


Brian


 


 


 


 


On Tue, Mar 6, 2012 at 11:45 AM, William Mills<wmills@yahoo-inc.com>


 wrote:




 


Yeah, something as simple as, "Note that the name 'b64token' does=
 not


imply


base64 encoding, see the definition in [[INSERT REFERENCE HERE]]."=
; would


do


it.


 


-bill


 


________________________________


From: Brian Campbell<=
bcampbell@pingidentity.com>


To: Mike Jones<Micha=
el.Jones@microsoft.com>


Cc: oauth<oauth@ietf.org><=
o:p>


Sent: Tuesday, March 6, 2012 8:23 AM


 


Subject: Re: [OAUTH-WG] question about the b64token syntax in


draft-ietf-oauth-v2-bearer


 


Thanks Mike, I think changing the example would be helpful.=



 


However I think that including some text along the lines of what James=



suggested would also be very valuable. I agree that the connection


between OAuth and Bearer could and should be made more explicit. And


that the implications of the b64token syntax, particularly on what AS<=
o:p>


can use to construct ATs, could/should be made more clear.<=
/pre>

 


I can propose some specific text (building on James') if others in the=
 WG


agree?


 


 


On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones<Michael.Jones@microsoft.com>


wrote:




 


I'm fine with changing the example to make it clearer that b64token


allows


a wider range of characters than just those legal for base64 and<=
/o:p>


base64url


encodings of data values.


 


I'll add it to my to-do list for any additional edits for the Bearer


spec.


 


                    =
           -- Mike


 


-----Original Message-----


From: oauth-bounces@ietf.org=
 [mailto:oauth-bounces@ietf.o=
rg] On Behalf


Of


Manger, James H


Sent: Monday, March 05, 2012 3:33 PM


To: Brian Campbell; oauth


Subject: Re: [OAUTH-WG] question about the b64token syntax in


draft-ietf-oauth-v2-bearer


 


Brian,


 




On casual reading of "The OAuth 2.0 Authorization Protocol: Beare=
r


Tokens"* I've encountered several people (including myself) who h=
ave


made the assumption that the name b64token implies that some kind of


base64 encoding/decoding on the access token is taking place between


the client and RS.


 


Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"=
;**,


however, I see that b64token is just an ABNF syntax definition


allowing for characters typically used in base64, base64url, etc.. So<=
o:p>


the b64token doesn't define any encoding or decoding but rather just


defines what characters can be used in the part of the Authorization


header that will contain the access token.


 


Do I read this correctly?




 


Yes.


 




If so, I feel like some additional clarifying text in the Bearer<=
/o:p>


Tokens draft might help avoid what is (based on my small sample) a


common point of misunderstanding.




 


Changing the example bearer token should be a simple way to avoid some=



confusion by showing that it does not have to be base64 encoding. How<=
o:p>


about


changing:


 Authorization: Bearer vF9dft4qmT


to


 Authorization: Bearer vF9.dft4.qmT


 


The Bearer spec has lots of (unnecessary) text about OAuth, but doesn'=
t


quite manage to be precise about how OAuth and Bearer connect. It coul=
d


explicitly state that the string value of the "access_token"=
 member of


an


access token response is the bearer token. The "access_token"=
; string


value


(after unescaping any JSON-escapes) MUST match the b64token ABNF so it=



can


be used with the Bearer HTTP scheme. Such text could be put in =A75.1.=
1


where


the "Bearer" OAuth access token type is defined.<=
/pre>

 


 




Also, does the use of b64token implicitly limit the allowed characters=



that an AS can use to construct a bearer access token?



 


Yes.


 


 




* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#secti=
on-2.1


**


http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section=
-2.1




 


--


James Manger


_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth


 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth


 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth




 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth






--_000_4E1F6AAD24975D4BA5B168042967394366404286TK5EX14MBXC284r_--

From barryleiba@gmail.com  Sat Mar 10 09:58:46 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA2921F849A for ; Sat, 10 Mar 2012 09:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.984
X-Spam-Level: 
X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qflY0rLFo29z for ; Sat, 10 Mar 2012 09:58:45 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0537321F8483 for ; Sat, 10 Mar 2012 09:58:44 -0800 (PST)
Received: by iazz13 with SMTP id z13so4468766iaz.31 for ; Sat, 10 Mar 2012 09:58:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BoI+dfMLmuIJboEZRaZIj/tTenHmo9dZDTuFIOg51Mw=; b=UH223sir6VmmE7YammxYgffsvqPkjuKOoFoM/wsNa1cs8F2MUQ8m+tH43bptBChUxf MJmL3dzZSFPfNeGJ/Zcvy+knjIDM6Ps8iwGCqyIj0CvIqYcBe8jv8pcm1Kn6Ht0vV4TT MLYdfl3iELUZS3BC8M/o04KxWjS/r8oGTRfO+tBWGLfyrt1JDTmiVdROa5cSnE085r+h bmlATsvR8NPMD+88gi7rNW8bfj8WVstl/svuJgBRkHK9xdFMfP4mloYs2xDx1tlwQm8S zTcR4AAHPwQPJJQ+EZs7MyttXpSP1UHIkDlTuYUqVKLKR+O3hMQy39fUcYi71PxVCgHK Qe9A==
MIME-Version: 1.0
Received: by 10.182.75.103 with SMTP id b7mr2469968obw.54.1331402324403; Sat, 10 Mar 2012 09:58:44 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.60.125.37 with HTTP; Sat, 10 Mar 2012 09:58:44 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366404286@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B168042967394366404286@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Sat, 10 Mar 2012 12:58:44 -0500
X-Google-Sender-Auth: zX_hYQNpOUw8cZyuTavOE3Qm9_A
Message-ID: 
From: Barry Leiba 
To: Mike Jones 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: oauth-chairs@tools.ietf.org, "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OK to post updated Bearer spec changing and adding examples?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Mar 2012 17:58:46 -0000

> OAuth Chairs,

Changed CC address; please see my list message:
http://www.ietf.org/mail-archive/web/oauth/current/msg08531.html

> Do you approve of posting an updated Bearer spec as below, assuming the
> working group does not object by mid-day Monday?

Yes, that makes sense.

Barry, still chairing for a short time yet

---------------------------------------------------------------------------=
---------------------------
From: Mike Jones
Sent: Saturday, March 10, 2012 9:50 AM
To: 'Paul Madsen'; Brian Campbell
Cc: oauth
Subject: RE: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer



I plan to make the change to the example access token value to
mF_9.B5f-4.1JqM before Monday=92s submission deadline, per the requests
for b64token syntax clarification.  I=92m also considering adding an
access token response example, pre the requests in this thread.  I
would propose adding the following new text for this in a new Section
4 (before the current Security Considerations).  This is largely
parallel to what is done in Section 5.1 of the MAC spec.



4.  Example Access Token Response



Typically a bearer token is returned to the client as part of an OAuth
2.0 [I-D.ietf-oauth-v2] access token response. An example of such as
response is:



     HTTP/1.1 200 OK

     Content-Type: application/json;charset=3DUTF-8

     Cache-Control: no-store

     Pragma: no-cache



     {

       "access_token":"mF_9.B5f-4.1JqM",

       "token_type":"Bearer",

       "expires_in":3600,

       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"

     }



Please send either +1s or objections to this text by mid-day Monday.
Unless I receive several +1s, to be conservative at this point, I will
not be including it in Monday=92s draft.



                                                            -- Mike



From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of Paul Madsen
Sent: Wednesday, March 07, 2012 1:34 PM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer



+1

On 3/7/12 4:08 PM, Brian Campbell wrote:

Yeah, it is case insensitive. I just went with the upper case B

because that's how it was written in =A75.1.1 of

draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually

defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.

Either one would be fine.



I agree that an example response from the token endpoint would be

worthwhile.  Something like the following might help tie together with

the Authorization header example (proposed earlier). It could maybe be

worked in near the top of =A72?



     HTTP/1.1 200 OK

     Content-Type: application/json;charset=3DUTF-8

     Cache-Control: no-store

     Pragma: no-cache



     {

       "access_token":"vF_9.5dCf-t4.qbcmT_k1b",

       "token_type":"example",

       "expires_in":3600,

       "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA",

     }



It'd probably make sense to change the examples in the body =A72.2***

and query =A72.3**** to use the same access token value too.





* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1

** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1

*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2

**** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3





On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer  wrote:

    Makes sense to me, except that I think the token_type value is typicall=
y

    lowercase "bearer", though it's defined to be case insensitive in

    Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the val=
ue of

    this field for the Bearer token type ever got defined anywhere. Section=
 7.1

    references the bearer spec as defining the value of the "token_type"

    parameter, and passes its example as if by reference. Would be worthwhi=
le

    giving an example of a token endpoint response, such as what's found in

    OAuth-v2-23 section 5.1.



     -- Justin





    On 03/07/2012 12:16 PM, Brian Campbell wrote:



        I'd like to propose the following changes and additions, derived

        largely from Bill and James suggestions, to

        draft-ietf-oauth-v2-bearer-17.  These changes have no normative imp=
act

        and only aim to add additional clarity and explanation the workings

        and implications of the current spec.  I'm definitely open to chang=
es

        or improvements in the wording here (not my strong suit by any mean=
s)

        but I think it's important that these general ideas be conveyed in =
the

        draft.





        =3D=3D>  Insert the following text at the beginning of =A72:



        To make a protected resource request, the client must be in possess=
ion

        of a valid bearer token. Typically a bearer token is returned to th=
e

        client as part of an access token response as defined in OAuth 2.0

        [I-D.ietf-oauth-v2]. When the "token_type" parameter of the access

        token response is "Bearer", the string value of the "access_token"

        parameter becomes the bearer access token used to make protected

        resource requests.



        =3D=3D>  Change the value of the token in the Authorization header
example to

        this:



        Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b



        =3D=3D>  Insert the following text before the last paragraph of =A7=
2.1:



        Note that the name b64token does not imply base64 encoding but rath=
er

        is the name for an ABNF syntax definition from HTTP/1.1, Part 7

        [I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"

        string value from an access token response MUST match the b64token

        ABNF so it can be used with the Bearer HTTP scheme.





        Thanks,

        Brian









        On Tue, Mar 6, 2012 at 11:45 AM, William Mills

         wrote:



            Yeah, something as simple as, "Note that the name
'b64token' does not

            imply

            base64 encoding, see the definition in [[INSERT REFERENCE
HERE]]." would

            do

            it.



            -bill



            ________________________________

            From: Brian Campbell

            To: Mike Jones

            Cc: oauth

            Sent: Tuesday, March 6, 2012 8:23 AM



            Subject: Re: [OAUTH-WG] question about the b64token syntax in

            draft-ietf-oauth-v2-bearer



            Thanks Mike, I think changing the example would be helpful.



            However I think that including some text along the lines
of what James

            suggested would also be very valuable. I agree that the connect=
ion

            between OAuth and Bearer could and should be made more explicit=
. And

            that the implications of the b64token syntax, particularly
on what AS

            can use to construct ATs, could/should be made more clear.



            I can propose some specific text (building on James') if
others in the WG

            agree?





            On Mon, Mar 5, 2012 at 5:32 PM, Mike
Jones

            wrote:



                I'm fine with changing the example to make it clearer
that b64token

                allows

                a wider range of characters than just those legal for base6=
4 and

                base64url

                encodings of data values.



                I'll add it to my to-do list for any additional edits
for the Bearer

                spec.



                                               -- Mike



                -----Original Message-----

                From: oauth-bounces@ietf.org
[mailto:oauth-bounces@ietf.org] On Behalf

                Of

                Manger, James H

                Sent: Monday, March 05, 2012 3:33 PM

                To: Brian Campbell; oauth

                Subject: Re: [OAUTH-WG] question about the b64token syntax =
in

                draft-ietf-oauth-v2-bearer



                Brian,



                    On casual reading of "The OAuth 2.0 Authorization
Protocol: Bearer

                    Tokens"* I've encountered several people
(including myself) who have

                    made the assumption that the name b64token implies
that some kind of

                    base64 encoding/decoding on the access token is
taking place between

                    the client and RS.



                    Digging a bit deeper in to "HTTP/1.1, part 7:
Authentication"**,

                    however, I see that b64token is just an ABNF
syntax definition

                    allowing for characters typically used in base64,
base64url, etc.. So

                    the b64token doesn't define any encoding or
decoding but rather just

                    defines what characters can be used in the part of
the Authorization

                    header that will contain the access token.



                    Do I read this correctly?



                Yes.



                    If so, I feel like some additional clarifying text
in the Bearer

                    Tokens draft might help avoid what is (based on my
small sample) a

                    common point of misunderstanding.



                Changing the example bearer token should be a simple
way to avoid some

                confusion by showing that it does not have to be
base64 encoding. How

                about

                changing:

                 Authorization: Bearer vF9dft4qmT

                to

                 Authorization: Bearer vF9.dft4.qmT



                The Bearer spec has lots of (unnecessary) text about
OAuth, but doesn't

                quite manage to be precise about how OAuth and Bearer
connect. It could

                explicitly state that the string value of the
"access_token" member of

                an

                access token response is the bearer token. The
"access_token" string

                value

                (after unescaping any JSON-escapes) MUST match the
b64token ABNF so it

                can

                be used with the Bearer HTTP scheme. Such text could
be put in =A75.1.1

                where

                the "Bearer" OAuth access token type is defined.





                    Also, does the use of b64token implicitly limit
the allowed characters

                    that an AS can use to construct a bearer access token?



                Yes.





                    *
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1

                    **


http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1



                --

                James Manger

From James.H.Manger@team.telstra.com  Sun Mar 11 03:05:31 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3EA21F8681 for ; Sun, 11 Mar 2012 03:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.156
X-Spam-Level: 
X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=-1.255, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6pmF40PM45h for ; Sun, 11 Mar 2012 03:05:31 -0700 (PDT)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 158B821F8672 for ; Sun, 11 Mar 2012 03:05:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.73,566,1325422800"; d="scan'208";a="64607916"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 11 Mar 2012 21:05:26 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6645"; a="54454385"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipccni.tcif.telstra.com.au with ESMTP; 11 Mar 2012 21:05:27 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Sun, 11 Mar 2012 21:05:26 +1100
From: "Manger, James H" 
To: "michael.jones@microsoft.com" 
Date: Sun, 11 Mar 2012 21:05:25 +1100
Thread-Topic: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
Thread-Index: Acz/bnqhTxUYvFRIRTWDermAdL9ROQ==
Message-ID: <14D58DEC-B867-47C2-A5E6-1C67F7595F94@team.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 10:05:32 -0000

KzENCg0KLS0NCkphbWVzIE1hbmdlcg0KDQotLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tRnJvbTog
Ik1pa2UgSm9uZXMiIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IERhdGU6IFN1biwgTWFy
IDExLCAyMDEyIDQ6NTAgYW0gU3ViamVjdDogW09BVVRILVdHXSBxdWVzdGlvbiBhYm91dCB0aGUg
YjY0dG9rZW4gc3ludGF4IGluIGRyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyIFRvOiAiUGF1bCBN
YWRzZW4iIDxwYXVsLm1hZHNlbkBnbWFpbC5jb20+LCAiQnJpYW4gQ2FtcGJlbGwiIDxiY2FtcGJl
bGxAcGluZ2lkZW50aXR5LmNvbT4gQ2M6ICJvYXV0aCIgPG9hdXRoQGlldGYub3JnPg0KDQpJIHBs
YW4gdG8gbWFrZSB0aGUgY2hhbmdlIHRvIHRoZSBleGFtcGxlIGFjY2VzcyB0b2tlbiB2YWx1ZSB0
b21GXzkuQjVmLTQuMUpxTSBiZWZvcmUgTW9uZGF54oCZcyBzdWJtaXNzaW9uIGRlYWRsaW5lLCBw
ZXIgdGhlIHJlcXVlc3RzIGZvciBiNjR0b2tlbiBzeW50YXggY2xhcmlmaWNhdGlvbi4gSeKAmW0g
YWxzbyBjb25zaWRlcmluZyBhZGRpbmcgYW4gYWNjZXNzIHRva2VuIHJlc3BvbnNlIGV4YW1wbGUs
IHByZSB0aGUgcmVxdWVzdHMgaW4gdGhpcyB0aHJlYWQuIEkgd291bGQgcHJvcG9zZSBhZGRpbmcg
dGhlIGZvbGxvd2luZyBuZXcgdGV4dCBmb3IgdGhpcyBpbiBhIG5ldyBTZWN0aW9uIDQgKGJlZm9y
ZSB0aGUgY3VycmVudCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucykuIFRoaXMgaXMgbGFyZ2VseSBw
YXJhbGxlbCB0byB3aGF0IGlzIGRvbmUgaW4gU2VjdGlvbiA1LjEgb2YgdGhlIE1BQyBzcGVjLg0K
DQo0LiBFeGFtcGxlIEFjY2VzcyBUb2tlbiBSZXNwb25zZQ0KDQpUeXBpY2FsbHkgYSBiZWFyZXIg
dG9rZW4gaXMgcmV0dXJuZWQgdG8gdGhlIGNsaWVudCBhcyBwYXJ0IG9mIGFuIE9BdXRoIDIuMCBb
SS1ELmlldGYtb2F1dGgtdjJdIGFjY2VzcyB0b2tlbiByZXNwb25zZS4gQW4gZXhhbXBsZSBvZiBz
dWNoIGFzIHJlc3BvbnNlIGlzOg0KDQpIVFRQLzEuMSAyMDAgT0sNCg0KQ29udGVudC1UeXBlOiBh
cHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRGLTgNCg0KQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUN
Cg0KUHJhZ21hOiBuby1jYWNoZQ0KDQp7DQoNCiJhY2Nlc3NfdG9rZW4iOiJtRl85LkI1Zi00LjFK
cU0iLA0KDQoidG9rZW5fdHlwZSI6IkJlYXJlciIsDQoNCiJleHBpcmVzX2luIjozNjAwLA0KDQoi
cmVmcmVzaF90b2tlbiI6InRHenYzSk9rRjBYRzVReDJUbEtXSUEiDQoNCn0NCg0KUGxlYXNlIHNl
bmQgZWl0aGVyICsxcyBvciBvYmplY3Rpb25zIHRvIHRoaXMgdGV4dCBieSBtaWQtZGF5IE1vbmRh
eS4gVW5sZXNzIEkgcmVjZWl2ZSBzZXZlcmFsICsxcywgdG8gYmUgY29uc2VydmF0aXZlIGF0IHRo
aXMgcG9pbnQsIEkgd2lsbCBub3QgYmUgaW5jbHVkaW5nIGl0IGluIE1vbmRheeKAmXMgZHJhZnQu
DQoNCi0tIE1pa2UNCg==

From paul.madsen@gmail.com  Sun Mar 11 04:19:10 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A7421F8549 for ; Sun, 11 Mar 2012 04:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.306
X-Spam-Level: 
X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1Rlmc9AVPAq for ; Sun, 11 Mar 2012 04:19:09 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8376421F84D6 for ; Sun, 11 Mar 2012 04:19:00 -0700 (PDT)
Received: by iazz13 with SMTP id z13so5656331iaz.31 for ; Sun, 11 Mar 2012 04:19:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type; bh=ZKTpcBDYkEwlgfkjABJPvpU/sXCDLe6H+HMTU/WxdBk=; b=DNYaftAF+IogyEbBPPSeJjoX+BUyMhLe+aCPO95s+EvwJZU3bVZZSAZFo8Fgd0LZHm HCK9E02fcWCYa8PrSiGZh9utYi8HX8LUAtLgZJIgBC9+JvVUxje5dn1EcLFXaxsdrcZ6 Aw2YdfkHxIpoSUhAvz4OAQtU6OQSKEvlX7IeVDzLoXtndo7vfSlUUtnv6YikQgiPQE24 qhzuA4s6HG5LJrLdE5p6IwoMTzc2HJtnuWLBoKpiKYcor2EZvjeUsbomjcybDmXcgni8 8lHO2ZUgBlJEzRy1Blil9zoZTwJgmaCgZVVbtpDGxsPnWuXOJeodCr67oOyWV6rEIwA1 CVRw==
Received: by 10.50.219.163 with SMTP id pp3mr13448754igc.1.1331464740228; Sun, 11 Mar 2012 04:19:00 -0700 (PDT)
Received: from pmadsen-mbp.local (bas1-kanata16-1088758938.dsl.bell.ca. [64.229.36.154]) by mx.google.com with ESMTPS id ke7sm3099572igc.10.2012.03.11.04.18.57 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 04:18:58 -0700 (PDT)
Message-ID: <4F5C8A20.4050005@gmail.com>
Date: Sun, 11 Mar 2012 07:18:56 -0400
From: Paul Madsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
References: <14D58DEC-B867-47C2-A5E6-1C67F7595F94@team.telstra.com>
In-Reply-To: <14D58DEC-B867-47C2-A5E6-1C67F7595F94@team.telstra.com>
Content-Type: multipart/alternative; boundary="------------020704060304060201040304"
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 11:19:10 -0000

This is a multi-part message in MIME format.
--------------020704060304060201040304
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

+1

On 3/11/12 6:05 AM, Manger, James H wrote:
> +1
>
> --
> James Manger
>
> ----- Reply message -----From: "Mike Jones"  Date: Sun, Mar 11, 2012 4:50 am Subject: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer To: "Paul Madsen", "Brian Campbell"  Cc: "oauth"
>
> I plan to make the change to the example access token value tomF_9.B5f-4.1JqM before Monday’s submission deadline, per the requests for b64token syntax clarification. I’m also considering adding an access token response example, pre the requests in this thread. I would propose adding the following new text for this in a new Section 4 (before the current Security Considerations). This is largely parallel to what is done in Section 5.1 of the MAC spec.
>
> 4. Example Access Token Response
>
> Typically a bearer token is returned to the client as part of an OAuth 2.0 [I-D.ietf-oauth-v2] access token response. An example of such as response is:
>
> HTTP/1.1 200 OK
>
> Content-Type: application/json;charset=UTF-8
>
> Cache-Control: no-store
>
> Pragma: no-cache
>
> {
>
> "access_token":"mF_9.B5f-4.1JqM",
>
> "token_type":"Bearer",
>
> "expires_in":3600,
>
> "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
>
> }
>
> Please send either +1s or objections to this text by mid-day Monday. Unless I receive several +1s, to be conservative at this point, I will not be including it in Monday’s draft.
>
> -- Mike
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------020704060304060201040304
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    +1

    

    On 3/11/12 6:05 AM, Manger, James H wrote:
    

      
+1

--
James Manger

----- Reply message -----From: "Mike Jones" <Michael.Jones@microsoft.com> Date: Sun, Mar 11, 2012 4:50 am Subject: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer To: "Paul Madsen" <paul.madsen@gmail.com>, "Brian Campbell" <bcampbell@pingidentity.com> Cc: "oauth" <oauth@ietf.org>

I plan to make the change to the example access token value tomF_9.B5f-4.1JqM before Monday’s submission deadline, per the requests for b64token syntax clarification. I’m also considering adding an access token response example, pre the requests in this thread. I would propose adding the following new text for this in a new Section 4 (before the current Security Considerations). This is largely parallel to what is done in Section 5.1 of the MAC spec.

4. Example Access Token Response

Typically a bearer token is returned to the client as part of an OAuth 2.0 [I-D.ietf-oauth-v2] access token response. An example of such as response is:

HTTP/1.1 200 OK

Content-Type: application/json;charset=UTF-8

Cache-Control: no-store

Pragma: no-cache

{

"access_token":"mF_9.B5f-4.1JqM",

"token_type":"Bearer",

"expires_in":3600,

"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"

}

Please send either +1s or objections to this text by mid-day Monday. Unless I receive several +1s, to be conservative at this point, I will not be including it in Monday’s draft.

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


    

  


--------------020704060304060201040304--

From ve7jtb@ve7jtb.com  Sun Mar 11 06:08:59 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC8E21F8546 for ; Sun, 11 Mar 2012 06:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level: 
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg88Yg7+2bKb for ; Sun, 11 Mar 2012 06:08:57 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AAB8021F854C for ; Sun, 11 Mar 2012 06:08:55 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so3741942vcb.31 for ; Sun, 11 Mar 2012 06:08:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=CH+sXVAyNlasNORlKHwTFaQbJ8+K2Fl/JitBqMuYtbU=; b=Xx7Y4Fjx04+rkeZD+t3tEUHmXbRrgGPgxkcCuQuaFHt8Em6eavtq/Wu6MSadgDx6mu 0BObplqVv89QqAeCOiNtxmkjoC+j8zdHhJ5jkzrRqmvL0OQdobiZ0qRbmEkswh6mIfrv P36Yyq7S+X7DNYFLxfgpGXDcb319SJHjsaHAHcOetzLX3l2Wb6miG8hjOGrq1VEIID3K VkXyDGTsuULQK0i2328jQrPlHaRZtrDsH3+LVYR8uO6o1RVEQnxLOKaQAyDWl+aAgEFz B33oxB6od69G6yGcjzIt+R0uSntGMsb7wsJxK0Oc2xS1zWcmrkEmuZK+9cBB96KNvtei Ojzw==
Received: by 10.52.95.3 with SMTP id dg3mr12088400vdb.127.1331471334887; Sun, 11 Mar 2012 06:08:54 -0700 (PDT)
Received: from [10.31.18.44] (173-163-203-241-Richmond.hfc.comcastbusiness.net. [173.163.203.241]) by mx.google.com with ESMTPS id fd10sm22071005vdc.1.2012.03.11.06.08.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 06:08:53 -0700 (PDT)
References: <4E1F6AAD24975D4BA5B168042967394366402261@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366402261@TK5EX14MBXC284.redmond.corp.microsoft.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-48FFFB66-388D-47EF-B7AF-8C89EFC59DE9
Message-Id: <6C7AC84B-F4F3-4069-9144-65B193D0F882@ve7jtb.com>
X-Mailer: iPhone Mail (9B179)
From: John Bradley 
Date: Sun, 11 Mar 2012 09:08:52 -0400
To: Mike Jones 
X-Gm-Message-State: ALoCoQlX78qVharjkv03E7xw7xA8DAKqdkIDXO5b7GukFInIR7j42SOntxs0WT5r+xdygy7zYqZm
Cc: oauth 
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 13:08:59 -0000

--Apple-Mail-48FFFB66-388D-47EF-B7AF-8C89EFC59DE9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1

Sent from my iPhone

On 2012-03-10, at 12:49 PM, Mike Jones  wrote:

> I plan to make the change to the example access token value to mF_9.B5f-4.=
1JqM before Monday=E2=80=99s submission deadline, per the requests for b64to=
ken syntax clarification.  I=E2=80=99m also considering adding an access tok=
en response example, pre the requests in this thread.  I would propose addin=
g the following new text for this in a new Section 4 (before the current Sec=
urity Considerations).  This is largely parallel to what is done in Section 5=
.1 of the MAC spec.
> =20
> 4.  Example Access Token Response
> =20
> Typically a bearer token is returned to the client as part of an OAuth 2.0=
 [I-D.ietf-oauth-v2] access token response. An example of such as response i=
s:
> =20
>      HTTP/1.1 200 OK
>      Content-Type: application/json;charset=3DUTF-8
>      Cache-Control: no-store
>      Pragma: no-cache
> =20
>      {
>        "access_token":"mF_9.B5f-4.1JqM",
>        "token_type":"Bearer",
>        "expires_in":3600,
>        "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
>      }
> =20
> Please send either +1s or objections to this text by mid-day Monday.  Unle=
ss I receive several +1s, to be conservative at this point, I will not be in=
cluding it in Monday=E2=80=99s draft.
> =20
>                                                             -- Mike
> =20
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P=
aul Madsen
> Sent: Wednesday, March 07, 2012 1:34 PM
> To: Brian Campbell
> Cc: oauth
> Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-o=
auth-v2-bearer
> =20
> +1
>=20
> On 3/7/12 4:08 PM, Brian Campbell wrote:
> Yeah, it is case insensitive. I just went with the upper case B
> because that's how it was written in =C2=A75.1.1 of
> draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually
> defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.
> Either one would be fine.
> =20
> I agree that an example response from the token endpoint would be
> worthwhile.  Something like the following might help tie together with
> the Authorization header example (proposed earlier). It could maybe be
> worked in near the top of =C2=A72?
> =20
>      HTTP/1.1 200 OK
>      Content-Type: application/json;charset=3DUTF-8
>      Cache-Control: no-store
>      Pragma: no-cache
> =20
>      {
>        "access_token":"vF_9.5dCf-t4.qbcmT_k1b",
>        "token_type":"example",
>        "expires_in":3600,
>        "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA",
>      }
> =20
> It'd probably make sense to change the examples in the body =C2=A72.2***
> and query =C2=A72.3**** to use the same access token value too.
> =20
> =20
> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1
> ** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1
> *** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2
> **** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3
> =20
> =20
> On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer  wrote:
> Makes sense to me, except that I think the token_type value is typically
> lowercase "bearer", though it's defined to be case insensitive in
> Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value o=
f
> this field for the Bearer token type ever got defined anywhere. Section 7.=
1
> references the bearer spec as defining the value of the "token_type"
> parameter, and passes its example as if by reference. Would be worthwhile
> giving an example of a token endpoint response, such as what's found in
> OAuth-v2-23 section 5.1.
> =20
>  -- Justin
> =20
> =20
> On 03/07/2012 12:16 PM, Brian Campbell wrote:
> =20
> I'd like to propose the following changes and additions, derived
> largely from Bill and James suggestions, to
> draft-ietf-oauth-v2-bearer-17.  These changes have no normative impact
> and only aim to add additional clarity and explanation the workings
> and implications of the current spec.  I'm definitely open to changes
> or improvements in the wording here (not my strong suit by any means)
> but I think it's important that these general ideas be conveyed in the
> draft.
> =20
> =20
> =3D=3D>  Insert the following text at the beginning of =C2=A72:
> =20
> To make a protected resource request, the client must be in possession
> of a valid bearer token. Typically a bearer token is returned to the
> client as part of an access token response as defined in OAuth 2.0
> [I-D.ietf-oauth-v2]. When the "token_type" parameter of the access
> token response is "Bearer", the string value of the "access_token"
> parameter becomes the bearer access token used to make protected
> resource requests.
> =20
> =3D=3D>  Change the value of the token in the Authorization header example=
 to
> this:
> =20
> Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b
> =20
> =3D=3D>  Insert the following text before the last paragraph of =C2=A72.1:=

> =20
> Note that the name b64token does not imply base64 encoding but rather
> is the name for an ABNF syntax definition from HTTP/1.1, Part 7
> [I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"
> string value from an access token response MUST match the b64token
> ABNF so it can be used with the Bearer HTTP scheme.
> =20
> =20
> Thanks,
> Brian
> =20
> =20
> =20
> =20
> On Tue, Mar 6, 2012 at 11:45 AM, William Mills
>  wrote:
> =20
> Yeah, something as simple as, "Note that the name 'b64token' does not
> imply
> base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would
> do
> it.
> =20
> -bill
> =20
> ________________________________
> From: Brian Campbell
> To: Mike Jones
> Cc: oauth
> Sent: Tuesday, March 6, 2012 8:23 AM
> =20
> Subject: Re: [OAUTH-WG] question about the b64token syntax in
> draft-ietf-oauth-v2-bearer
> =20
> Thanks Mike, I think changing the example would be helpful.
> =20
> However I think that including some text along the lines of what James
> suggested would also be very valuable. I agree that the connection
> between OAuth and Bearer could and should be made more explicit. And
> that the implications of the b64token syntax, particularly on what AS
> can use to construct ATs, could/should be made more clear.
> =20
> I can propose some specific text (building on James') if others in the WG
> agree?
> =20
> =20
> On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones
> wrote:
> =20
> I'm fine with changing the example to make it clearer that b64token
> allows
> a wider range of characters than just those legal for base64 and
> base64url
> encodings of data values.
> =20
> I'll add it to my to-do list for any additional edits for the Bearer
> spec.
> =20
>                                -- Mike
> =20
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of
> Manger, James H
> Sent: Monday, March 05, 2012 3:33 PM
> To: Brian Campbell; oauth
> Subject: Re: [OAUTH-WG] question about the b64token syntax in
> draft-ietf-oauth-v2-bearer
> =20
> Brian,
> =20
> On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
> Tokens"* I've encountered several people (including myself) who have
> made the assumption that the name b64token implies that some kind of
> base64 encoding/decoding on the access token is taking place between
> the client and RS.
> =20
> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,
> however, I see that b64token is just an ABNF syntax definition
> allowing for characters typically used in base64, base64url, etc.. So
> the b64token doesn't define any encoding or decoding but rather just
> defines what characters can be used in the part of the Authorization
> header that will contain the access token.
> =20
> Do I read this correctly?
> =20
> Yes.
> =20
> If so, I feel like some additional clarifying text in the Bearer
> Tokens draft might help avoid what is (based on my small sample) a
> common point of misunderstanding.
> =20
> Changing the example bearer token should be a simple way to avoid some
> confusion by showing that it does not have to be base64 encoding. How
> about
> changing:
>  Authorization: Bearer vF9dft4qmT
> to
>  Authorization: Bearer vF9.dft4.qmT
> =20
> The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't
> quite manage to be precise about how OAuth and Bearer connect. It could
> explicitly state that the string value of the "access_token" member of
> an
> access token response is the bearer token. The "access_token" string
> value
> (after unescaping any JSON-escapes) MUST match the b64token ABNF so it
> can
> be used with the Bearer HTTP scheme. Such text could be put in =C2=A75.1.1=

> where
> the "Bearer" OAuth access token type is defined.
> =20
> =20
> Also, does the use of b64token implicitly limit the allowed characters
> that an AS can use to construct a bearer access token?
> =20
> Yes.
> =20
> =20
> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1
> **
> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1
> =20
> --
> James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-48FFFB66-388D-47EF-B7AF-8C89EFC59DE9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


+1

Sent from my iPh=
one

On 2012-03-10, at 12:49 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:










I plan to make the change t=
o the example access token value to
mF_9.=
B5f-4.1JqM before Monday=E2=80=99s submissi=
on deadline, per the requests for b64token syntax clarification.  I=E2=80=
=99m also
 considering adding an access token response example, pre the requests in th=
is thread.  I would propose adding the following new text for this in a=
 new Section 4 (before the current Security Considerations).  This is l=
argely parallel to what is done in Section
 5.1 of the MAC spec.


 

4.  Example Access Token Response


 


Typically a bearer token is returned to the clie=
nt as part of an OAuth 2.0 [I-D.ietf-oauth-v2] access token response. An exa=
mple of such as response is:


 


     HTTP/1.1 200 OK
=


     Content-Type: application/json;charse=
t=3DUTF-8


     Cache-Control: no-store


     Pragma: no-cache

 


     {


       "access_token":"mF_9.B5f-=
4.1JqM",


       "token_type":"Bearer",


       "expires_in":3600,


       "refresh_token":"tGzv3JOk=
F0XG5Qx2TlKWIA"


     }


 

Please send either +1s or o=
bjections to this text by mid-day Monday.  Unless I receive several +1s=
, to be conservative at this point, I will not be including
 it in Monday=E2=80=99s draft.


 

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


 





From: oauth-bounce=
s@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Paul Madsen

Sent: Wednesday, March 07, 2012 1:34 PM

To: Brian Campbell

Cc: oauth

Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-i=
etf-oauth-v2-bearer






 


+1



On 3/7/12 4:08 PM, Brian Campbell wrote: 


Yeah, it is case insensitive. I just went with the upper case B


because that's how it was written in =C2=A75.1.1 of


draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually


defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.


Either one would be fine.


 


I agree that an example response from the token endpoint would be<=
/o:p>


worthwhile.  Something like the following might help tie together w=
ith


the Authorization header example (proposed earlier). It could maybe be<=
o:p>


worked in near the top of =C2=A72?


 


     HTTP/1.1 200 OK


     Content-Type: application/json;charset=3DUTF-8=



     Cache-Control: no-store


     Pragma: no-cache


 


     {


       "access_token":"vF_9.5dCf-t4.qbcmT=
_k1b",


       "token_type":"example",=



       "expires_in":3600,

       "refresh_token":"stGzv3xOdkF0X35Qp=
2TlKWIA",


     }


 


It'd probably make sense to change the examples in the body =C2=A72.2**=
*


and query =C2=A72.3**** to use the same access token value too.


 


 


* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#secti=
on-5.1.1


** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1=



*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#secti=
on-2.2


**** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#sect=
ion-2.3


 


 


On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer <jricher@mitre.org> wrote:




Makes sense to me, except that I think the token_type value is typicall=
y


lowercase "bearer", though it's defined to be case insensitive in<=
/o:p>


Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the val=
ue of


this field for the Bearer token type ever got defined anywhere. Section=
 7.1


references the bearer spec as defining the value of the "token_type"


parameter, and passes its example as if by reference. Would be worthwhi=
le


giving an example of a token endpoint response, such as what's found in=



OAuth-v2-23 section 5.1.


 


 -- Justin


 


 


On 03/07/2012 12:16 PM, Brian Campbell wrote:




 


I'd like to propose the following changes and additions, derived


largely from Bill and James suggestions, to


draft-ietf-oauth-v2-bearer-17.  These changes have no normative im=
pact


and only aim to add additional clarity and explanation the workings


and implications of the current spec.  I'm definitely open to chan=
ges


or improvements in the wording here (not my strong suit by any means)


but I think it's important that these general ideas be conveyed in the<=
o:p>


draft.


 


 


=3D=3D>  Insert the following text at the beginning of =C2=A72:=



 


To make a protected resource request, the client must be in possession<=
o:p>


of a valid bearer token. Typically a bearer token is returned to the


client as part of an access token response as defined in OAuth 2.0=



[I-D.ietf-oauth-v2]. When the "token_type" parameter of the access=



token response is "Bearer", the string value of the "access_token"=



parameter becomes the bearer access token used to make protected


resource requests.


 


=3D=3D>  Change the value of the token in the Authorization hea=
der example to


this:


 


Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b


 


=3D=3D>  Insert the following text before the last paragraph of=
 =C2=A72.1:


 


Note that the name b64token does not imply base64 encoding but rather


is the name for an ABNF syntax definition from HTTP/1.1, Part 7


[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"=



string value from an access token response MUST match the b64token=



ABNF so it can be used with the Bearer HTTP scheme.


 


 


Thanks,


Brian


 


 


 


 


On Tue, Mar 6, 2012 at 11:45 AM, William Mills<wmills@yahoo-inc.com>


 wrote:




 


Yeah, something as simple as, "Note that the name 'b64token' does not


imply


base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." woul=
d


do


it.


 


-bill


 


________________________________


From: Brian Campbell<b=
campbell@pingidentity.com>


To: Mike Jones<Michae=
l.Jones@microsoft.com>


Cc: oauth<oauth@ietf.org>


Sent: Tuesday, March 6, 2012 8:23 AM


 


Subject: Re: [OAUTH-WG] question about the b64token syntax in


draft-ietf-oauth-v2-bearer


 


Thanks Mike, I think changing the example would be helpful.<=
/pre>

 


However I think that including some text along the lines of what James<=
o:p>


suggested would also be very valuable. I agree that the connection=



between OAuth and Bearer could and should be made more explicit. And


that the implications of the b64token syntax, particularly on what AS


can use to construct ATs, could/should be made more clear.

 


I can propose some specific text (building on James') if others in the W=
G


agree?


 


 


On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones<Michael.Jones@microsoft.com>


wrote:




 


I'm fine with changing the example to make it clearer that b64token


allows


a wider range of characters than just those legal for base64 and


base64url


encodings of data values.


 


I'll add it to my to-do list for any additional edits for the Bearer


spec.


 


                    &=
nbsp;          -- Mike


 


-----Original Message-----


From: oauth-bounces@ietf.org<=
/a> [mailto:oauth-bounces@ietf.org=
] On Behalf


Of


Manger, James H


Sent: Monday, March 05, 2012 3:33 PM


To: Brian Campbell; oauth


Subject: Re: [OAUTH-WG] question about the b64token syntax in


draft-ietf-oauth-v2-bearer


 


Brian,


 




On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer=



Tokens"* I've encountered several people (including myself) who have


made the assumption that the name b64token implies that some kind of


base64 encoding/decoding on the access token is taking place between


the client and RS.


 


Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,


however, I see that b64token is just an ABNF syntax definition


allowing for characters typically used in base64, base64url, etc.. So


the b64token doesn't define any encoding or decoding but rather just


defines what characters can be used in the part of the Authorization


header that will contain the access token.


 


Do I read this correctly?




 


Yes.


 




If so, I feel like some additional clarifying text in the Bearer


Tokens draft might help avoid what is (based on my small sample) a=



common point of misunderstanding.




 


Changing the example bearer token should be a simple way to avoid some<=
o:p>


confusion by showing that it does not have to be base64 encoding. How


about


changing:


 Authorization: Bearer vF9dft4qmT


to


 Authorization: Bearer vF9.dft4.qmT


 


The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't=



quite manage to be precise about how OAuth and Bearer connect. It could=



explicitly state that the string value of the "access_token" member of<=
o:p>


an


access token response is the bearer token. The "access_token" string


value


(after unescaping any JSON-escapes) MUST match the b64token ABNF so it<=
o:p>


can


be used with the Bearer HTTP scheme. Such text could be put in =C2=A75.=
1.1


where


the "Bearer" OAuth access token type is defined.


 


 




Also, does the use of b64token implicitly limit the allowed characters<=
o:p>


that an AS can use to construct a bearer access token?
=




 


Yes.


 


 




* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section=
-2.1


**


http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2=
.1




 


--


James Manger


_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.iet=
f.org/mailman/listinfo/oauth


 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.iet=
f.org/mailman/listinfo/oauth


 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.iet=
f.org/mailman/listinfo/oauth




 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.iet=
f.org/mailman/listinfo/oauth






____________________=
___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=

--Apple-Mail-48FFFB66-388D-47EF-B7AF-8C89EFC59DE9--

From bcampbell@pingidentity.com  Sun Mar 11 06:50:15 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038D721F86A7 for ; Sun, 11 Mar 2012 06:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.857
X-Spam-Level: 
X-Spam-Status: No, score=-3.857 tagged_above=-999 required=5 tests=[AWL=-1.881, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PdLYznQtlyP for ; Sun, 11 Mar 2012 06:50:13 -0700 (PDT)
Received: from psmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) by ietfa.amsl.com (Postfix) with ESMTP id A42FB21F8697 for ; Sun, 11 Mar 2012 06:50:12 -0700 (PDT)
Received: from mail-vx0-f180.google.com ([209.85.220.180]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKT1ytk0JRwC4QCoQ1A3FZK0bboFGPZ9t5@postini.com; Sun, 11 Mar 2012 06:50:12 PDT
Received: by mail-vx0-f180.google.com with SMTP id fl10so4267714vcb.11 for ; Sun, 11 Mar 2012 06:50:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=cDOxrpFDYHZ8QVZuTiQ0Fge844OWTtaslrtJVTWF6xk=; b=EurFamer/nwjM1ZErD6KjiBqSJGuWBCm0Ll87QR9k7vUy7tlJLCKakFDheho8EhW9Z hkcSOXQyvHxk0lJ9nB6JAyEf62E9wo0IkEJGaOfC7cEeUzBDL0HPG/aBjiBXAoVCPzOV l11WEpYqXNes3F7d0xZns3OSp1+z8VkLUUJ0qvGjR6fTHYqUpw+eyEn1JvEMkeqUQ2ol c0QFI3qmKbDFSGYwdTV6dGR/DGvSOtZ5InLcs8sZByKL+ReQ5HN8hwtKd15CzwfGfQ+8 ZwXVCQhB+7raYwWcacsDYC6r3UKW1euOENhq/nbpMtOQ4LLAtMBqiIyEYHzGDYxW74sg H2Ew==
MIME-Version: 1.0
Received: by 10.52.93.18 with SMTP id cq18mr12146936vdb.40.1331473811766; Sun, 11 Mar 2012 06:50:11 -0700 (PDT)
Received: by 10.52.171.172 with HTTP; Sun, 11 Mar 2012 06:50:11 -0700 (PDT)
Received: by 10.52.171.172 with HTTP; Sun, 11 Mar 2012 06:50:11 -0700 (PDT)
In-Reply-To: <6C7AC84B-F4F3-4069-9144-65B193D0F882@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B168042967394366402261@TK5EX14MBXC284.redmond.corp.microsoft.com> <6C7AC84B-F4F3-4069-9144-65B193D0F882@ve7jtb.com>
Date: Sun, 11 Mar 2012 07:50:11 -0600
Message-ID: 
From: Brian Campbell 
To: John Bradley 
Content-Type: multipart/alternative; boundary=20cf3071c6aa93ff1a04baf7e76e
X-Gm-Message-State: ALoCoQnqEFfxBveM/PQU3sjH7Zi8XMJEzxsMitiAKwD5leggCNpGM2G9U8HiyjBsjwU8L7vkwLTH
Cc: oauth 
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 13:50:15 -0000

--20cf3071c6aa93ff1a04baf7e76e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

+1
On Mar 11, 2012 7:08 AM, "John Bradley"  wrote:

> +1
>
> Sent from my iPhone
>
> On 2012-03-10, at 12:49 PM, Mike Jones 
> wrote:
>
>  I plan to make the change to the example access token value to
> mF_9.B5f-4.1JqM before Monday=92s submission deadline, per the requests f=
or
> b64token syntax clarification.  I=92m also considering adding an access t=
oken
> response example, pre the requests in this thread.  I would propose addin=
g
> the following new text for this in a new Section 4 (before the current
> Security Considerations).  This is largely parallel to what is done in
> Section 5.1 of the MAC spec.****
>
> ** **
>
> *4.  Example Access Token Response*
>
> ** **
>
> Typically a bearer token is returned to the client as part of an OAuth 2.=
0
> [I-D.ietf-oauth-v2] access token response. An example of such as response
> is:****
>
> ** **
>
>      HTTP/1.1 200 OK****
>
>      Content-Type: application/json;charset=3DUTF-8****
>
>      Cache-Control: no-store****
>
>      Pragma: no-cache****
>
> ** **
>
>      {****
>
>        "access_token":"mF_9.B5f-4.1JqM",****
>
>        "token_type":"Bearer",****
>
>        "expires_in":3600,****
>
>        "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"****
>
>      }****
>
> ** **
>
> Please send either +1s or objections to this text by mid-day Monday.
> Unless I receive several +1s, to be conservative at this point, I will no=
t
> be including it in Monday=92s draft.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Paul Madsen
> *Sent:* Wednesday, March 07, 2012 1:34 PM
> *To:* Brian Campbell
> *Cc:* oauth
> *Subject:* Re: [OAUTH-WG] question about the b64token syntax in
> draft-ietf-oauth-v2-bearer****
>
> ** **
>
> +1
>
> On 3/7/12 4:08 PM, Brian Campbell wrote: ****
>
> Yeah, it is case insensitive. I just went with the upper case B****
>
> because that's how it was written in =A75.1.1 of****
>
> draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually****
>
> defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.****
>
> Either one would be fine.****
>
> ** **
>
> I agree that an example response from the token endpoint would be****
>
> worthwhile.  Something like the following might help tie together with***=
*
>
> the Authorization header example (proposed earlier). It could maybe be***=
*
>
> worked in near the top of =A72?****
>
> ** **
>
>      HTTP/1.1 200 OK****
>
>      Content-Type: application/json;charset=3DUTF-8****
>
>      Cache-Control: no-store****
>
>      Pragma: no-cache****
>
> ** **
>
>      {****
>
>        "access_token":"vF_9.5dCf-t4.qbcmT_k1b",****
>
>        "token_type":"example",****
>
>        "expires_in":3600,****
>
>        "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA",****
>
>      }****
>
> ** **
>
> It'd probably make sense to change the examples in the body =A72.2*******
>
> and query =A72.3**** to use the same access token value too.****
>
> ** **
>
> ** **
>
> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1*=
***
>
> ** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1****
>
> *** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2*=
***
>
> **** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3=
****
>
> ** **
>
> ** **
>
> On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer   wrote:****
>
>  Makes sense to me, except that I think the token_type value is typically=
****
>
> lowercase "bearer", though it's defined to be case insensitive in****
>
> Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value=
 of****
>
> this field for the Bearer token type ever got defined anywhere. Section 7=
.1****
>
> references the bearer spec as defining the value of the "token_type"****
>
> parameter, and passes its example as if by reference. Would be worthwhile=
****
>
> giving an example of a token endpoint response, such as what's found in**=
**
>
> OAuth-v2-23 section 5.1.****
>
> ** **
>
>  -- Justin****
>
> ** **
>
> ** **
>
> On 03/07/2012 12:16 PM, Brian Campbell wrote:****
>
>  ** **
>
> I'd like to propose the following changes and additions, derived****
>
> largely from Bill and James suggestions, to****
>
> draft-ietf-oauth-v2-bearer-17.  These changes have no normative impact***=
*
>
> and only aim to add additional clarity and explanation the workings****
>
> and implications of the current spec.  I'm definitely open to changes****
>
> or improvements in the wording here (not my strong suit by any means)****
>
> but I think it's important that these general ideas be conveyed in the***=
*
>
> draft.****
>
> ** **
>
> ** **
>
> =3D=3D>  Insert the following text at the beginning of =A72:****
>
> ** **
>
> To make a protected resource request, the client must be in possession***=
*
>
> of a valid bearer token. Typically a bearer token is returned to the****
>
> client as part of an access token response as defined in OAuth 2.0****
>
> [I-D.ietf-oauth-v2]. When the "token_type" parameter of the access****
>
> token response is "Bearer", the string value of the "access_token"****
>
> parameter becomes the bearer access token used to make protected****
>
> resource requests.****
>
> ** **
>
> =3D=3D>  Change the value of the token in the Authorization header exampl=
e to****
>
> this:****
>
> ** **
>
> Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b****
>
> ** **
>
> =3D=3D>  Insert the following text before the last paragraph of =A72.1:**=
**
>
> ** **
>
> Note that the name b64token does not imply base64 encoding but rather****
>
> is the name for an ABNF syntax definition from HTTP/1.1, Part 7****
>
> [I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"****
>
> string value from an access token response MUST match the b64token****
>
> ABNF so it can be used with the Bearer HTTP scheme.****
>
> ** **
>
> ** **
>
> Thanks,****
>
> Brian****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Tue, Mar 6, 2012 at 11:45 AM, William Mills ****
>
>  wrote:****
>
>  ** **
>
> Yeah, something as simple as, "Note that the name 'b64token' does not****
>
> imply****
>
> base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would*=
***
>
> do****
>
> it.****
>
> ** **
>
> -bill****
>
> ** **
>
> ________________________________****
>
> From: Brian Campbell ****
>
> To: Mike Jones =
****
>
> Cc: oauth ****
>
> Sent: Tuesday, March 6, 2012 8:23 AM****
>
> ** **
>
> Subject: Re: [OAUTH-WG] question about the b64token syntax in****
>
> draft-ietf-oauth-v2-bearer****
>
> ** **
>
> Thanks Mike, I think changing the example would be helpful.****
>
> ** **
>
> However I think that including some text along the lines of what James***=
*
>
> suggested would also be very valuable. I agree that the connection****
>
> between OAuth and Bearer could and should be made more explicit. And****
>
> that the implications of the b64token syntax, particularly on what AS****
>
> can use to construct ATs, could/should be made more clear.****
>
> ** **
>
> I can propose some specific text (building on James') if others in the WG=
****
>
> agree?****
>
> ** **
>
> ** **
>
> On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones <=
Michael.Jones@microsoft.com>****
>
> wrote:****
>
>  ** **
>
> I'm fine with changing the example to make it clearer that b64token****
>
> allows****
>
> a wider range of characters than just those legal for base64 and****
>
> base64url****
>
> encodings of data values.****
>
> ** **
>
> I'll add it to my to-do list for any additional edits for the Bearer****
>
> spec.****
>
> ** **
>
>                                -- Mike****
>
> ** **
>
> -----Original Message-----****
>
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org ] On Behalf****
>
> Of****
>
> Manger, James H****
>
> Sent: Monday, March 05, 2012 3:33 PM****
>
> To: Brian Campbell; oauth****
>
> Subject: Re: [OAUTH-WG] question about the b64token syntax in****
>
> draft-ietf-oauth-v2-bearer****
>
> ** **
>
> Brian,****
>
> ** **
>
>  On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer****
>
> Tokens"* I've encountered several people (including myself) who have****
>
> made the assumption that the name b64token implies that some kind of****
>
> base64 encoding/decoding on the access token is taking place between****
>
> the client and RS.****
>
> ** **
>
> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,****
>
> however, I see that b64token is just an ABNF syntax definition****
>
> allowing for characters typically used in base64, base64url, etc.. So****
>
> the b64token doesn't define any encoding or decoding but rather just****
>
> defines what characters can be used in the part of the Authorization****
>
> header that will contain the access token.****
>
> ** **
>
> Do I read this correctly?****
>
>  ** **
>
> Yes.****
>
> ** **
>
>  If so, I feel like some additional clarifying text in the Bearer****
>
> Tokens draft might help avoid what is (based on my small sample) a****
>
> common point of misunderstanding.****
>
>  ** **
>
> Changing the example bearer token should be a simple way to avoid some***=
*
>
> confusion by showing that it does not have to be base64 encoding. How****
>
> about****
>
> changing:****
>
>  Authorization: Bearer vF9dft4qmT****
>
> to****
>
>  Authorization: Bearer vF9.dft4.qmT****
>
> ** **
>
> The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't**=
**
>
> quite manage to be precise about how OAuth and Bearer connect. It could**=
**
>
> explicitly state that the string value of the "access_token" member of***=
*
>
> an****
>
> access token response is the bearer token. The "access_token" string****
>
> value****
>
> (after unescaping any JSON-escapes) MUST match the b64token ABNF so it***=
*
>
> can****
>
> be used with the Bearer HTTP scheme. Such text could be put in =A75.1.1**=
**
>
> where****
>
> the "Bearer" OAuth access token type is defined.****
>
> ** **
>
> ** **
>
>  Also, does the use of b64token implicitly limit the allowed characters**=
**
>
> that an AS can use to construct a bearer access token?****
>
>  ** **
>
> Yes.****
>
> ** **
>
> ** **
>
>  * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1**=
**
>
> ******
>
> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1****
>
>  ** **
>
> --****
>
> James Manger****
>
> _______________________________________________****
>
> OAuth mailing list****
>
> OAuth@ietf.org****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>
> ** **
>
>  _______________________________________________****
>
> OAuth mailing list****
>
> OAuth@ietf.org****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>
> ** **
>
>  _______________________________________________****
>
> OAuth mailing list****
>
> OAuth@ietf.org****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ** **
>
> ** **
>
>  _______________________________________________****
>
> OAuth mailing list****
>
> OAuth@ietf.org****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--20cf3071c6aa93ff1a04baf7e76e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


+1


On Mar 11, 2012 7:08 AM, "John Bradley"=
; <ve7jtb@ve7jtb.com> wrote:=



+1

Sent from my iPhone

O=
n 2012-03-10, at 12:49 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:<=
br>











I plan to make the change=
 to the example access token value to
mF_9.B5f-4.1JqM<=
/span> before Monday=92s submission deadline, pe=
r the requests for b64token syntax clarification.=A0 I=92m also
 considering adding an access token response example, pre the requests in t=
his thread.=A0 I would propose adding the following new text for this in a =
new Section 4 (before the current Security Considerations).=A0 This is larg=
ely parallel to what is done in Section
 5.1 of the MAC spec.


=A0<=
/p>

4.=A0 Example Access Token Response


=A0


Typically a bearer token is returned to the client as part=
 of an OAuth 2.0 [I-D.ietf-oauth-v2] access token response. An example of s=
uch as response is:



=A0


=A0=A0=A0=A0 HTTP/1.=
1 200 OK


=A0=A0=A0=A0 Content=
-Type: application/json;charset=3DUTF-8


=A0=A0=A0=A0 Cache-C=
ontrol: no-store


=A0=A0=A0=A0 Pragma:=
 no-cache


=A0


=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0 &=
quot;access_token":"mF_9.B5f-4.1JqM",

=A0=A0=A0=A0=A0=A0 &=
quot;token_type":"Bearer",


=A0=A0=A0=A0=A0=A0 &=
quot;expires_in":3600,


=A0=A0=A0=A0=A0=A0 &=
quot;refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"


=A0=A0=A0=A0 }


=A0<=
/p>

Please send either +1s or=
 objections to this text by mid-day Monday.=A0 Unless I receive several +1s=
, to be conservative at this point, I will not be including
 it in Monday=92s draft.


=A0<=
/p>

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


=A0<=
/p>





From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Paul Madsen

Sent: Wednesday, March 07, 2012 1:34 PM

To: Brian Campbell

Cc: oauth

Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-=
ietf-oauth-v2-bearer






=A0


+1



On 3/7/12 4:08 PM, Brian Campbell wrote: 


Yeah, it is case insensitive. I just went with the upper case B=



because that's how it was written in =A75.1.1 of

draft-ietf-oauth-v2-bearer-17* which is where I guess it's actuall=
y


defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.


Either one would be fine.


=A0


I agree that an example response from the token endpoint would be


worthwhile.=A0 Something like the following might help tie together wi=
th


the Authorization header example (proposed earlier). It could maybe be=



worked in near the top of =A72?


=A0


=A0=A0=A0=A0 HTTP/1.1 200 OK


=A0=A0=A0=A0 Content-Type: application/json;charset=3DUTF-8<=
/u>


=A0=A0=A0=A0 Cache-Control: no-store


=A0=A0=A0=A0 Pragma: no-cache


=A0


=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0 "access_token":"vF_9.5dCf-t4.qbcmT_k=
1b",


=A0=A0 =A0=A0=A0=A0"token_type":"example",<=
u>


=A0=A0=A0=A0=A0=A0 "expires_in":3600,


=A0=A0=A0=A0=A0=A0 "refresh_token":"stGzv3xOdkF0X35Qp2T=
lKWIA",


=A0=A0=A0=A0 }


=A0


It'd probably make sense to change the examples in the body =A72.2=
***


and query =A72.3**** to use the same access token value too.=



=A0


=A0


* http://tools.ietf.org/html/draft-ietf-oaut=
h-v2-bearer-17#section-5.1.1


** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#=
section-7.1


*** http://tools.ietf.org/html/draft-ietf-oaut=
h-v2-bearer-17#section-2.2


**** http://tools.ietf.org/html/draft-ietf-oau=
th-v2-bearer-17#section-2.3


=A0


=A0


On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer <jricher@mitre.org> wrote:=





Makes sense to me, except that I think the token_type value is typical=
ly


lowercase "bearer", though it's defined to be case insen=
sitive in


Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that th=
e value of


this field for the Bearer token type ever got defined anywhere. Sectio=
n 7.1


references the bearer spec as defining the value of the "token_ty=
pe"


parameter, and passes its example as if by reference. Would be worthwh=
ile


giving an example of a token endpoint response, such as what's fou=
nd in


OAuth-v2-23 section 5.1.


=A0


=A0-- Justin


=A0


=A0


On 03/07/2012 12:16 PM, Brian Campbell wrote:




=A0


I'd like to propose the following changes and additions, derived


largely from Bill and James suggestions, to


draft-ietf-oauth-v2-bearer-17. =A0These changes have no normative impa=
ct


and only aim to add additional clarity and explanation the workings=



and implications of the current spec. =A0I'm definitely open to ch=
anges


or improvements in the wording here (not my strong suit by any means)<=
u>


but I think it's important that these general ideas be conveyed in=
 the


draft.


=A0


=A0


=3D=3D> =A0Insert the following text at the beginning of =A72:


=A0


To make a protected resource request, the client must be in possession=



of a valid bearer token. Typically a bearer token is returned to the


client as part of an access token response as defined in OAuth 2.0<=
/u>


[I-D.ietf-oauth-v2]. When the "token_type" parameter of the =
access


token response is "Bearer", the string value of the "ac=
cess_token"


parameter becomes the bearer access token used to make protected


resource requests.


=A0


=3D=3D> =A0Change the value of the token in the Authorization heade=
r example to


this:


=A0


Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b


=A0


=3D=3D> =A0Insert the following text before the last paragraph of =
=A72.1:


=A0


Note that the name b64token does not imply base64 encoding but rather<=
u>


is the name for an ABNF syntax definition from HTTP/1.1, Part 7=



[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token=
"


string value from an access token response MUST match the b64token<=
/u>


ABNF so it can be used with the Bearer HTTP scheme.

=A0


=A0


Thanks,


Brian


=A0


=A0


=A0


=A0


On Tue, Mar 6, 2012 at 11:45 AM, William Mills<wmills@yahoo-inc.com>


=A0wrote:




=A0


Yeah, something as simple as, "Note that the name 'b64token&#=
39; does not


imply


base64 encoding, see the definition in [[INSERT REFERENCE HERE]]."=
; would


do


it.


=A0


-bill


=A0


________________________________


From: Brian Campbell<bcampbell@pingidentity.com>


To: Mike Jones<Michael.Jones@microsoft.com>


Cc: oauth<oauth=
@ietf.org>


Sent: Tuesday, March 6, 2012 8:23 AM


=A0


Subject: Re: [OAUTH-WG] question about the b64token syntax in


draft-ietf-oauth-v2-bearer


=A0


Thanks Mike, I think changing the example would be helpful.<=
/u>


=A0


However I think that including some text along the lines of what James=



suggested would also be very valuable. I agree that the connection<=
/u>


between OAuth and Bearer could and should be made more explicit. And


that the implications of the b64token syntax, particularly on what AS<=
u>


can use to construct ATs, could/should be made more clear.


=A0


I can propose some specific text (building on James') if others in=
 the WG


agree?


=A0


=A0


On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones<Michael.Jones@microsoft.com>


wrote:




=A0


I'm fine with changing the example to make it clearer that b64toke=
n


allows


a wider range of characters than just those legal for base64 and


base64url


encodings of data values.


=A0


I'll add it to my to-do list for any additional edits for the Bear=
er


spec.


=A0


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



=A0


-----Original Message-----


From: oaut=
h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf


Of


Manger, James H


Sent: Monday, March 05, 2012 3:33 PM


To: Brian Campbell; oauth


Subject: Re: [OAUTH-WG] question about the b64token syntax in


draft-ietf-oauth-v2-bearer


=A0


Brian,


=A0




On casual reading of "The OAuth 2.0 Authorization Protocol: Beare=
r


Tokens"* I've encountered several people (including myself) w=
ho have


made the assumption that the name b64token implies that some kind of


base64 encoding/decoding on the access token is taking place between


the client and RS.


=A0


Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"=
;**,


however, I see that b64token is just an ABNF syntax definition<=
u>


allowing for characters typically used in base64, base64url, etc.. So<=
u>


the b64token doesn't define any encoding or decoding but rather ju=
st


defines what characters can be used in the part of the Authorization


header that will contain the access token.


=A0


Do I read this correctly?




=A0


Yes.


=A0




If so, I feel like some additional clarifying text in the Bearer


Tokens draft might help avoid what is (based on my small sample) a<=
/u>


common point of misunderstanding.




=A0


Changing the example bearer token should be a simple way to avoid some=



confusion by showing that it does not have to be base64 encoding. How<=
u>


about


changing:


=A0Authorization: Bearer vF9dft4qmT


to


=A0Authorization: Bearer vF9.dft4.qmT


=A0


The Bearer spec has lots of (unnecessary) text about OAuth, but doesn&=
#39;t


quite manage to be precise about how OAuth and Bearer connect. It coul=
d


explicitly state that the string value of the "access_token"=
 member of


an


access token response is the bearer token. The "access_token"=
; string


value


(after unescaping any JSON-escapes) MUST match the b64token ABNF so it=



can


be used with the Bearer HTTP scheme. Such text could be put in =A75.1.=
1


where


the "Bearer" OAuth access token type is defined.


=A0


=A0




Also, does the use of b64token implicitly limit the allowed characters=



that an AS can use to construct a bearer access token?



=A0


Yes.


=A0


=A0




* http://tools.ietf.org/html/draft-ietf-oauth-=
v2-bearer-17#section-2.1


**


http://tools.ietf.org/html/draft-ietf-httpbis-=
p7-auth-18#section-2.1




=A0


--


James Manger


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth


=A0


=A0




_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth


=A0


=A0




_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth




=A0


=A0




_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth






___________________=
____________________________
OAuth mailing list
<=
span>OAuth@ietf.org=


https://www.ietf.org/mailman/listinfo/oauth


--20cf3071c6aa93ff1a04baf7e76e--

From nov@matake.jp  Sun Mar 11 08:25:32 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3767021F86C9 for ; Sun, 11 Mar 2012 08:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiMkpb-31xGp for ; Sun, 11 Mar 2012 08:25:31 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7D5821F8611 for ; Sun, 11 Mar 2012 08:25:31 -0700 (PDT)
Received: by dakl33 with SMTP id l33so4226140dak.31 for ; Sun, 11 Mar 2012 08:25:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=gquI7/5Ee1vcDzd32BQXnFSPKEMtKBLlhvCuNPOIBbs=; b=agdcQ1Or3XsjDHjHeLD6l6znKD8mS+k4NR0+UlGlft61EaR76P0vQ0lJeV4CXbpCpV mvmvozBTiJO2qJVnkl7A4FgoMN4kHXSNGkQnJJacCbhcJLYxhElXe3uc//XKjr4/B/Vi 3dqlNLFIql13uhpfqDnfCZfwaj8p+2XdRr1Z1GadPNNDY1Xy3mLDNcPLZqweNXzhGOg4 geKUMhfoggEZlJQhFK3nlj0w4PzkX3K4EIqayZ4THjALEnCOSuT6wmWdWkpla3czmygH j7GlTA/iBl2KEKpWZw+E1SMhU+gjunkjoux3OAJL76Qr5BsZuRqCi64K6IZ37z8aJZiJ alpA==
Received: by 10.68.227.38 with SMTP id rx6mr7028874pbc.139.1331479531388; Sun, 11 Mar 2012 08:25:31 -0700 (PDT)
Received: from [192.168.1.103] (q032020.dynamic.ppp.asahi-net.or.jp. [203.181.32.20]) by mx.google.com with ESMTPS id a2sm8360260pbc.16.2012.03.11.08.25.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 08:25:30 -0700 (PDT)
From: nov matake 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Mar 2012 00:25:27 +0900
Message-Id: <62D85564-7961-4AB6-B1FA-B2DD75A4C74B@matake.jp>
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQlmvFsxzmXZHN4dlDfMu2bEgAUJc+aNRkN8+Lr7ezr4I1JbcjoVZHTVhZwK7vDAHXcNvkfR
Subject: [OAUTH-WG] Clarification of "client application consisting of multiple components"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 15:25:32 -0000

Hi,

I just found this sentence in the latest draft.

Does it mean "an application consisting of server-side and client-side =
component (eg. foursquare iPhone app) MUST have separate client_id for =
each component" ?
Or can I image something like Facebook is doing right now? (register =
each component for a single client_id separately)

=3D=3D
A client application consisting of multiple components, each with its
own client type (e.g. a distributed client with both a confidential
server-based component and a public browser-based component), MUST
register each component separately as a different client to ensure
proper handling by the authorization server.  The authorization
server MAY provider tools to manage such complex clients through a
single administration interface.
=3D=3D

--
nov =

From eran@hueniverse.com  Sun Mar 11 08:57:24 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADC521F86E5 for ; Sun, 11 Mar 2012 08:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level: 
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6rsEm-UZ1w0 for ; Sun, 11 Mar 2012 08:57:24 -0700 (PDT)
Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2349521F84E7 for ; Sun, 11 Mar 2012 08:57:24 -0700 (PDT)
Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id kFxP1i00610TkE001FxP5t; Sun, 11 Mar 2012 08:57:23 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Sun, 11 Mar 2012 08:57:23 -0700
From: Eran Hammer 
To: nov matake , "oauth@ietf.org WG" 
Date: Sun, 11 Mar 2012 08:57:22 -0700
Thread-Topic: [OAUTH-WG] Clarification of "client application consisting of multiple components"
Thread-Index: Acz/mzWcUPpRJfNDR66NHAA/GYvcvgABFasw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08605@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <62D85564-7961-4AB6-B1FA-B2DD75A4C74B@matake.jp>
In-Reply-To: <62D85564-7961-4AB6-B1FA-B2DD75A4C74B@matake.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Clarification of "client application consisting of	multiple components"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 15:57:24 -0000

If you have two components each with different security profile, you must a=
ssign each a different client_id. Otherwise, there is no way to enforce the=
 rest of the spec's security requirements.

EH

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of nov matake
> Sent: Sunday, March 11, 2012 8:25 AM
> To: oauth@ietf.org WG
> Subject: [OAUTH-WG] Clarification of "client application consisting of mu=
ltiple
> components"
>=20
> Hi,
>=20
> I just found this sentence in the latest draft.
>=20
> Does it mean "an application consisting of server-side and client-side
> component (eg. foursquare iPhone app) MUST have separate client_id for
> each component" ?
> Or can I image something like Facebook is doing right now? (register each
> component for a single client_id separately)
>=20
> =3D=3D
> A client application consisting of multiple components, each with its own
> client type (e.g. a distributed client with both a confidential server-ba=
sed
> component and a public browser-based component), MUST register each
> component separately as a different client to ensure proper handling by t=
he
> authorization server.  The authorization server MAY provider tools to man=
age
> such complex clients through a single administration interface.
> =3D=3D
>=20
> --
> nov 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From jricher@mitre.org  Sun Mar 11 09:45:53 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854D821F8787 for ; Sun, 11 Mar 2012 09:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.583
X-Spam-Level: 
X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbgKVyiQQsdj for ; Sun, 11 Mar 2012 09:45:50 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9E121F8754 for ; Sun, 11 Mar 2012 09:45:50 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DB60121B17B9; Sun, 11 Mar 2012 12:45:49 -0400 (EDT)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0C14D21B0BD6; Sun, 11 Mar 2012 12:45:46 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Sun, 11 Mar 2012 12:45:46 -0400
From: "Richer, Justin P." 
To: Brian Campbell , John Bradley 
Thread-Topic: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
Thread-Index: AQHM/4gqWIyG2G+J/k6ZdG5qJIljR5ZlX76A///t86k=
Date: Sun, 11 Mar 2012 16:45:43 +0000
Message-ID: 
References: <4E1F6AAD24975D4BA5B168042967394366402261@TK5EX14MBXC284.redmond.corp.microsoft.com> <6C7AC84B-F4F3-4069-9144-65B193D0F882@ve7jtb.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [129.83.31.52]
Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E0E1D8DIMCMBX01MITREORG_"
MIME-Version: 1.0
Cc: oauth 
Subject: Re: [OAUTH-WG] question about the b64token syntax in	draft-ietf-oauth-v2-bearer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 16:45:53 -0000

--_000_B33BFB58CCC8BE4998958016839DE27E0E1D8DIMCMBX01MITREORG_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

+1
________________________________
From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Brian Ca=
mpbell [bcampbell@pingidentity.com]
Sent: Sunday, March 11, 2012 9:50 AM
To: John Bradley
Cc: oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oa=
uth-v2-bearer


+1

On Mar 11, 2012 7:08 AM, "John Bradley" > wrote:
+1

Sent from my iPhone

On 2012-03-10, at 12:49 PM, Mike Jones > wrote:

I plan to make the change to the example access token value to mF_9.B5f-4.1=
JqM before Monday=92s submission deadline, per the requests for b64token sy=
ntax clarification.  I=92m also considering adding an access token response=
 example, pre the requests in this thread.  I would propose adding the foll=
owing new text for this in a new Section 4 (before the current Security Con=
siderations).  This is largely parallel to what is done in Section 5.1 of t=
he MAC spec.

4.  Example Access Token Response

Typically a bearer token is returned to the client as part of an OAuth 2.0 =
[I-D.ietf-oauth-v2] access token response. An example of such as response i=
s:


     HTTP/1.1 200 OK

     Content-Type: application/json;charset=3DUTF-8

     Cache-Control: no-store

     Pragma: no-cache



     {

       "access_token":"mF_9.B5f-4.1JqM",

       "token_type":"Bearer",

       "expires_in":3600,

       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"

     }

Please send either +1s or objections to this text by mid-day Monday.  Unles=
s I receive several +1s, to be conservative at this point, I will not be in=
cluding it in Monday=92s draft.

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Paul Madsen
Sent: Wednesday, March 07, 2012 1:34 PM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oa=
uth-v2-bearer

+1

On 3/7/12 4:08 PM, Brian Campbell wrote:

Yeah, it is case insensitive. I just went with the upper case B

because that's how it was written in =A75.1.1 of

draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually

defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.

Either one would be fine.



I agree that an example response from the token endpoint would be

worthwhile.  Something like the following might help tie together with

the Authorization header example (proposed earlier). It could maybe be

worked in near the top of =A72?



     HTTP/1.1 200 OK

     Content-Type: application/json;charset=3DUTF-8

     Cache-Control: no-store

     Pragma: no-cache



     {

       "access_token":"vF_9.5dCf-t4.qbcmT_k1b",

       "token_type":"example",

       "expires_in":3600,

       "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA",

     }



It'd probably make sense to change the examples in the body =A72.2***

and query =A72.3**** to use the same access token value too.





* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1

** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1

*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2

**** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3





On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer  wrote:

Makes sense to me, except that I think the token_type value is typically

lowercase "bearer", though it's defined to be case insensitive in

Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value o=
f

this field for the Bearer token type ever got defined anywhere. Section 7.1

references the bearer spec as defining the value of the "token_type"

parameter, and passes its example as if by reference. Would be worthwhile

giving an example of a token endpoint response, such as what's found in

OAuth-v2-23 section 5.1.



 -- Justin





On 03/07/2012 12:16 PM, Brian Campbell wrote:



I'd like to propose the following changes and additions, derived

largely from Bill and James suggestions, to

draft-ietf-oauth-v2-bearer-17.  These changes have no normative impact

and only aim to add additional clarity and explanation the workings

and implications of the current spec.  I'm definitely open to changes

or improvements in the wording here (not my strong suit by any means)

but I think it's important that these general ideas be conveyed in the

draft.





=3D=3D>  Insert the following text at the beginning of =A72:



To make a protected resource request, the client must be in possession

of a valid bearer token. Typically a bearer token is returned to the

client as part of an access token response as defined in OAuth 2.0

[I-D.ietf-oauth-v2]. When the "token_type" parameter of the access

token response is "Bearer", the string value of the "access_token"

parameter becomes the bearer access token used to make protected

resource requests.



=3D=3D>  Change the value of the token in the Authorization header example =
to

this:



Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b



=3D=3D>  Insert the following text before the last paragraph of =A72.1:



Note that the name b64token does not imply base64 encoding but rather

is the name for an ABNF syntax definition from HTTP/1.1, Part 7

[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"

string value from an access token response MUST match the b64token

ABNF so it can be used with the Bearer HTTP scheme.





Thanks,

Brian









On Tue, Mar 6, 2012 at 11:45 AM, William Mills

 wrote:



Yeah, something as simple as, "Note that the name 'b64token' does not

imply

base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would

do

it.



-bill



________________________________

From: Brian Campbell

To: Mike Jones

Cc: oauth

Sent: Tuesday, March 6, 2012 8:23 AM



Subject: Re: [OAUTH-WG] question about the b64token syntax in

draft-ietf-oauth-v2-bearer



Thanks Mike, I think changing the example would be helpful.



However I think that including some text along the lines of what James

suggested would also be very valuable. I agree that the connection

between OAuth and Bearer could and should be made more explicit. And

that the implications of the b64token syntax, particularly on what AS

can use to construct ATs, could/should be made more clear.



I can propose some specific text (building on James') if others in the WG

agree?





On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones

wrote:



I'm fine with changing the example to make it clearer that b64token

allows

a wider range of characters than just those legal for base64 and

base64url

encodings of data values.



I'll add it to my to-do list for any additional edits for the Bearer

spec.



                               -- Mike



-----Original Message-----

From: mailto:oauth-bounces@ietf.org] On Behalf

Of

Manger, James H

Sent: Monday, March 05, 2012 3:33 PM

To: Brian Campbell; oauth

Subject: Re: [OAUTH-WG] question about the b64token syntax in

draft-ietf-oauth-v2-bearer



Brian,



On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer

Tokens"* I've encountered several people (including myself) who have

made the assumption that the name b64token implies that some kind of

base64 encoding/decoding on the access token is taking place between

the client and RS.



Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,

however, I see that b64token is just an ABNF syntax definition

allowing for characters typically used in base64, base64url, etc.. So

the b64token doesn't define any encoding or decoding but rather just

defines what characters can be used in the part of the Authorization

header that will contain the access token.



Do I read this correctly?



Yes.



If so, I feel like some additional clarifying text in the Bearer

Tokens draft might help avoid what is (based on my small sample) a

common point of misunderstanding.



Changing the example bearer token should be a simple way to avoid some

confusion by showing that it does not have to be base64 encoding. How

about

changing:

 Authorization: Bearer vF9dft4qmT

to

 Authorization: Bearer vF9.dft4.qmT



The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't

quite manage to be precise about how OAuth and Bearer connect. It could

explicitly state that the string value of the "access_token" member of

an

access token response is the bearer token. The "access_token" string

value

(after unescaping any JSON-escapes) MUST match the b64token ABNF so it

can

be used with the Bearer HTTP scheme. Such text could be put in =A75.1.1

where

the "Bearer" OAuth access token type is defined.





Also, does the use of b64token implicitly limit the allowed characters

that an AS can use to construct a bearer access token?



Yes.





* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1

**

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1



--

James Manger

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

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

--_000_B33BFB58CCC8BE4998958016839DE27E0E1D8DIMCMBX01MITREORG_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable








+1






From: oauth-bounces@ietf.org [oauth-bounc=
es@ietf.org] on behalf of Brian Campbell [bcampbell@pingidentity.com]

Sent: Sunday, March 11, 2012 9:50 AM

To: John Bradley

Cc: oauth

Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-=
ietf-oauth-v2-bearer










+1


On Mar 11, 2012 7:08 AM, "John Bradley"=
; <ve7jtb@ve7jtb.=
com> wrote:






+1



Sent from my iPhone




On 2012-03-10, at 12:49 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:=















I plan to ma=
ke the change to the example access token value to
mF_9.B5f-4.1Jq=
M before Monday=92s submissi=
on deadline, per the requests for b64token syntax clarification.  I=92=
m
 also considering adding an access token response example, pre the requests=
 in this thread.  I would propose adding the following new text for th=
is in a new Section 4 (before the current Security Considerations).  T=
his is largely parallel to what is done in
 Section 5.1 of the MAC spec.


 =
;


4.  Example Access Token Response<=
/span>


 


Typically a bearer token is returned to the client as pa=
rt of an OAuth 2.0 [I-D.ietf-oauth-v2] access token response. An example of=
 such as response is:


 


   =
  HTTP/1.1 200 OK


   =
  Content-Type: application/json;charset=3DUTF-8<=
/p>

   =
  Cache-Control: no-store


   =
  Pragma: no-cache


 


   =
  {


   =
    "access_token":"mF_9.B5f-4.1JqM",=



   =
    "token_type":"Bearer",=



   =
    "expires_in":3600,


   =
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA&q=
uot;


   =
  }


 =
;


Please send =
either +1s or objections to this text by mid-day Monday.  Unless I=
 receive several +1s, to be conservative at this point, I will not
 be including it in Monday=92s draft.


 =
;


  =
            &nb=
sp;            =
            &nb=
sp;            =
        -- Mike


 =
;






From:=

oauth-bounces@i=
etf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Paul Madsen

Sent: Wednesday, March 07, 2012 1:34 PM

To: Brian Campbell

Cc: oauth

Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-=
ietf-oauth-v2-bearer






 


+1



On 3/7/12 4:08 PM, Brian Campbell wrote: 


Yeah, it is case insensitive. I just went with the upper case B=



because that's how it was written in =A75.1.1 of


draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually=



defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.


Either one would be fine.


 


I agree that an example response from the token endpoint would be


worthwhile.  Something like the following might help tie together=
 with


the Authorization header example (proposed earlier). It could maybe be=



worked in near the top of =A72?


 


     HTTP/1.1 200 OK


     Content-Type: application/json;charset=3DUTF-=
8


     Cache-Control: no-store


     Pragma: no-cache


 


     {


       "access_token":"vF=
_9.5dCf-t4.qbcmT_k1b",


       "token_type":"exam=
ple",


       "expires_in":3600,


       "refresh_token":"s=
tGzv3xOdkF0X35Qp2TlKWIA",


     }


 


It'd probably make sense to change the examples in the body =A72.2***<=
u>


and query =A72.3**** to use the same access token value too.=



 


 


* http://tools.ietf.org/html/draft-ietf-oaut=
h-v2-bearer-17#section-5.1.1


** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#=
section-7.1


*** http://tools.ietf.org/html/draft-ietf-oaut=
h-v2-bearer-17#section-2.2


**** http://tools.ietf.org/html/draft-ietf-oau=
th-v2-bearer-17#section-2.3


 


 


On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer <jricher@mitre.org> wrote:=





Makes sense to me, except that I think the token_type value is typical=
ly


lowercase "bearer", though it's defined to be case insensiti=
ve in


Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the va=
lue of


this field for the Bearer token type ever got defined anywhere. Sectio=
n 7.1


references the bearer spec as defining the value of the "token_ty=
pe"


parameter, and passes its example as if by reference. Would be worthwh=
ile


giving an example of a token endpoint response, such as what's found i=
n


OAuth-v2-23 section 5.1.


 


 -- Justin


 


 


On 03/07/2012 12:16 PM, Brian Campbell wrote:




 


I'd like to propose the following changes and additions, derived


largely from Bill and James suggestions, to


draft-ietf-oauth-v2-bearer-17.  These changes have no normative i=
mpact


and only aim to add additional clarity and explanation the workings=



and implications of the current spec.  I'm definitely open to cha=
nges


or improvements in the wording here (not my strong suit by any means)<=
u>


but I think it's important that these general ideas be conveyed in the=



draft.


 


 


=3D=3D>  Insert the following text at the beginning of =A72:


 


To make a protected resource request, the client must be in possession=



of a valid bearer token. Typically a bearer token is returned to the


client as part of an access token response as defined in OAuth 2.0<=
/u>


[I-D.ietf-oauth-v2]. When the "token_type" parameter of the =
access


token response is "Bearer", the string value of the "ac=
cess_token"


parameter becomes the bearer access token used to make protected


resource requests.


 


=3D=3D>  Change the value of the token in the Authorization he=
ader example to


this:


 


Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b


 


=3D=3D>  Insert the following text before the last paragraph o=
f =A72.1:


 


Note that the name b64token does not imply base64 encoding but rather<=
u>


is the name for an ABNF syntax definition from HTTP/1.1, Part 7=



[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token=
"


string value from an access token response MUST match the b64token<=
/u>


ABNF so it can be used with the Bearer HTTP scheme.

 


 


Thanks,


Brian


 


 


 


 


On Tue, Mar 6, 2012 at 11:45 AM, William Mills<wmills@yahoo-inc.com>


 wrote:




 


Yeah, something as simple as, "Note that the name 'b64token' does=
 not


imply


base64 encoding, see the definition in [[INSERT REFERENCE HERE]]."=
; would


do


it.


 


-bill


 


________________________________


From: Brian Campbell<bcampbell@pingidentity.com>


To: Mike Jones<Michael.Jones@microsoft.com>


Cc: oauth<oauth=
@ietf.org>


Sent: Tuesday, March 6, 2012 8:23 AM


 


Subject: Re: [OAUTH-WG] question about the b64token syntax in


draft-ietf-oauth-v2-bearer


 


Thanks Mike, I think changing the example would be helpful.<=
/u>


 


However I think that including some text along the lines of what James=



suggested would also be very valuable. I agree that the connection<=
/u>


between OAuth and Bearer could and should be made more explicit. And


that the implications of the b64token syntax, particularly on what AS<=
u>


can use to construct ATs, could/should be made more clear.


 


I can propose some specific text (building on James') if others in the=
 WG


agree?


 


 


On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones<Michael.Jones@microsoft.com>


wrote:




 


I'm fine with changing the example to make it clearer that b64token=



allows


a wider range of characters than just those legal for base64 and


base64url


encodings of data values.


 


I'll add it to my to-do list for any additional edits for the Bearer


spec.


 


                    =
           -- Mike


 


-----Original Message-----


From: mail=
to:oauth-bounces@ietf.org] On Behalf


Of


Manger, James H


Sent: Monday, March 05, 2012 3:33 PM


To: Brian Campbell; oauth


Subject: Re: [OAUTH-WG] question about the b64token syntax in


draft-ietf-oauth-v2-bearer


 


Brian,


 




On casual reading of "The OAuth 2.0 Authorization Protocol: Beare=
r


Tokens"* I've encountered several people (including myself) who h=
ave


made the assumption that the name b64token implies that some kind of


base64 encoding/decoding on the access token is taking place between


the client and RS.


 


Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"=
;**,


however, I see that b64token is just an ABNF syntax definition<=
u>


allowing for characters typically used in base64, base64url, etc.. So<=
u>


the b64token doesn't define any encoding or decoding but rather just


defines what characters can be used in the part of the Authorization


header that will contain the access token.


 


Do I read this correctly?




 


Yes.


 




If so, I feel like some additional clarifying text in the Bearer


Tokens draft might help avoid what is (based on my small sample) a<=
/u>


common point of misunderstanding.




 


Changing the example bearer token should be a simple way to avoid some=



confusion by showing that it does not have to be base64 encoding. How<=
u>


about


changing:


 Authorization: Bearer vF9dft4qmT


to


 Authorization: Bearer vF9.dft4.qmT


 


The Bearer spec has lots of (unnecessary) text about OAuth, but doesn'=
t


quite manage to be precise about how OAuth and Bearer connect. It coul=
d


explicitly state that the string value of the "access_token"=
 member of


an


access token response is the bearer token. The "access_token"=
; string


value


(after unescaping any JSON-escapes) MUST match the b64token ABNF so it=



can


be used with the Bearer HTTP scheme. Such text could be put in =A75.1.=
1


where


the "Bearer" OAuth access token type is defined.


 


 




Also, does the use of b64token implicitly limit the allowed characters=



that an AS can use to construct a bearer access token?



 


Yes.


 


 




* http://tools.ietf.org/html/draft-ietf-oauth-=
v2-bearer-17#section-2.1


**


http://tools.ietf.org/html/draft-ietf-httpbis-=
p7-auth-18#section-2.1




 


--


James Manger


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth


 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth


 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth




 


 




_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth










_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




















--_000_B33BFB58CCC8BE4998958016839DE27E0E1D8DIMCMBX01MITREORG_--

From nov@matake.jp  Sun Mar 11 10:21:31 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F08421F8619 for ; Sun, 11 Mar 2012 10:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level: 
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJhpJ7OmT6Ti for ; Sun, 11 Mar 2012 10:21:30 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED1F21F8648 for ; Sun, 11 Mar 2012 10:21:25 -0700 (PDT)
Received: by dakl33 with SMTP id l33so4326422dak.31 for ; Sun, 11 Mar 2012 10:21:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=AMNXhbIiPP3CCA1ABqpjqDO4n8p/gOQL1L/j4GG0NkM=; b=QMFJEtU/r+oUCmVHqLqgxMnNV+KXqcbEzb38Q/lcBsgiyZzqKyH2uPZ17Jfnu2dXzy vSJFHcZCO1ar7s93KttddnAWwXqUDfhXlvK/wHIqBuNJDHFPJMjYUXz1Q663Af0Awvo7 QqQFb/nl+nEQKRzIPAjulArRir4jx2Er5ctQEQZcAzPj1xsKWibsqdpnHPUEQDWKfBpZ KBmEhuSjuquXom2Kg3irZrYo8OmSK9BIl7Cv6j0ZYYWGtIag8xxYYzS6xBX/SRL+W8Ca pqA7RQCgS5UzC5K3xK8UsXsULlfMOudk3lXEbgC3KJc/fTb6U9XyU7t1FQ0NshEXavuR 1NlA==
Received: by 10.68.219.41 with SMTP id pl9mr10069406pbc.122.1331486485651; Sun, 11 Mar 2012 10:21:25 -0700 (PDT)
Received: from [192.168.1.106] (q032020.dynamic.ppp.asahi-net.or.jp. [203.181.32.20]) by mx.google.com with ESMTPS id j3sm8517189pbb.29.2012.03.11.10.21.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 10:21:24 -0700 (PDT)
References: <62D85564-7961-4AB6-B1FA-B2DD75A4C74B@matake.jp> <90C41DD21FB7C64BB94121FBBC2E723453AFF08605@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08605@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: 
X-Mailer: iPhone Mail (9B176)
From: nov matake 
Date: Mon, 12 Mar 2012 02:21:18 +0900
To: Eran Hammer 
X-Gm-Message-State: ALoCoQkx6wMdPeZLJvaRTk7zPvk1PitLV7KArpjhCtEqiw8dnPg3ecICi4tUtO4O3ofUpkcEciot
Cc: nov matake , "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Clarification of "client application consisting of multiple components"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 17:21:31 -0000

So what is the usecase of response_type=3Dtoken%20code ?
I thought, in that usecase, token was for the client's client-side component=
, code was for the client's server-side component, and both of them have the=
 same client_id.

--
nov

On Mar 12, 2012, at 12:57 AM, Eran Hammer  wrote:

> If you have two components each with different security profile, you must a=
ssign each a different client_id. Otherwise, there is no way to enforce the r=
est of the spec's security requirements.
>=20
> EH
>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of nov matake
>> Sent: Sunday, March 11, 2012 8:25 AM
>> To: oauth@ietf.org WG
>> Subject: [OAUTH-WG] Clarification of "client application consisting of mu=
ltiple
>> components"
>>=20
>> Hi,
>>=20
>> I just found this sentence in the latest draft.
>>=20
>> Does it mean "an application consisting of server-side and client-side
>> component (eg. foursquare iPhone app) MUST have separate client_id for
>> each component" ?
>> Or can I image something like Facebook is doing right now? (register each=

>> component for a single client_id separately)
>>=20
>> =3D=3D
>> A client application consisting of multiple components, each with its own=

>> client type (e.g. a distributed client with both a confidential server-ba=
sed
>> component and a public browser-based component), MUST register each
>> component separately as a different client to ensure proper handling by t=
he
>> authorization server.  The authorization server MAY provider tools to man=
age
>> such complex clients through a single administration interface.
>> =3D=3D
>>=20
>> --
>> nov 
>> _______________________________________________
>> 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 eran@hueniverse.com  Sun Mar 11 10:30:06 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B919E21F86AF for ; Sun, 11 Mar 2012 10:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.543
X-Spam-Level: 
X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9fQe+D6Sg0K for ; Sun, 11 Mar 2012 10:30:06 -0700 (PDT)
Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0F07B21F8697 for ; Sun, 11 Mar 2012 10:30:05 -0700 (PDT)
Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id kHW51i00310TkE001HW5Hw; Sun, 11 Mar 2012 10:30:05 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Sun, 11 Mar 2012 10:30:05 -0700
From: Eran Hammer 
To: nov matake 
Date: Sun, 11 Mar 2012 10:30:04 -0700
Thread-Topic: [OAUTH-WG] Clarification of "client application consisting of multiple components"
Thread-Index: Acz/q2QcGXncpc47R46PVh2PMBxB3AAAOX6w
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08609@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <62D85564-7961-4AB6-B1FA-B2DD75A4C74B@matake.jp> <90C41DD21FB7C64BB94121FBBC2E723453AFF08605@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Clarification of "client application consisting of multiple components"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 17:30:06 -0000

That use case was removed from the specification. Either way, it is up to t=
he authorization server to decide which registration options to offer the c=
lient if they make such a grant type available in the future, and how it wi=
ll apply the security policies. IOW, those proposing such an extension in t=
he future will have to figure out how this should be handled.

EH

> -----Original Message-----
> From: nov matake [mailto:nov@matake.jp]
> Sent: Sunday, March 11, 2012 10:21 AM
> To: Eran Hammer
> Cc: nov matake; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Clarification of "client application consisting o=
f
> multiple components"
>=20
> So what is the usecase of response_type=3Dtoken%20code ?
> I thought, in that usecase, token was for the client's client-side compon=
ent,
> code was for the client's server-side component, and both of them have th=
e
> same client_id.
>=20
> --
> nov
>=20
> On Mar 12, 2012, at 12:57 AM, Eran Hammer  wrote:
>=20
> > If you have two components each with different security profile, you mu=
st
> assign each a different client_id. Otherwise, there is no way to enforce =
the
> rest of the spec's security requirements.
> >
> > EH
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf Of nov matake
> >> Sent: Sunday, March 11, 2012 8:25 AM
> >> To: oauth@ietf.org WG
> >> Subject: [OAUTH-WG] Clarification of "client application consisting
> >> of multiple components"
> >>
> >> Hi,
> >>
> >> I just found this sentence in the latest draft.
> >>
> >> Does it mean "an application consisting of server-side and
> >> client-side component (eg. foursquare iPhone app) MUST have separate
> >> client_id for each component" ?
> >> Or can I image something like Facebook is doing right now? (register
> >> each component for a single client_id separately)
> >>
> >> =3D=3D
> >> A client application consisting of multiple components, each with its
> >> own client type (e.g. a distributed client with both a confidential
> >> server-based component and a public browser-based component), MUST
> >> register each component separately as a different client to ensure
> >> proper handling by the authorization server.  The authorization
> >> server MAY provider tools to manage such complex clients through a
> single administration interface.
> >> =3D=3D
> >>
> >> --
> >> nov 
> >> _______________________________________________
> >> 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 nov@matake.jp  Sun Mar 11 10:43:35 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD5921F85C2 for ; Sun, 11 Mar 2012 10:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.668
X-Spam-Level: 
X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8amBWym9tIa for ; Sun, 11 Mar 2012 10:43:35 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 986DC21F85C0 for ; Sun, 11 Mar 2012 10:43:32 -0700 (PDT)
Received: by dakl33 with SMTP id l33so4345511dak.31 for ; Sun, 11 Mar 2012 10:43:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=LsGEIN9zjvJ//86rSW+lcltsCytqgZJ6v4fyY7+si/4=; b=QuV39ObMt1iOePAngn5O6M6pqDjRJGZBy/6jOliPBnCzKA33ayFq4BtlQjqu87W8xD N4RCtOyZSagXvoqw13DyKZsN32pN82lE3ik1LUkojtY1NY6hi9sedclNxx9oGzegqJ3g R6ScYUNxu65aZQU/OZ/GAk9FWRdrkbS6iIPylMvOIkPTPC5l0AhmI7DNWiZl2x012ORv tOfDt5o+Se2wsTSwLUKcVcNNu64XTLokn0ekxMiNBOUYlJ+7jOfsrnAR2qnckUR1Lzw2 QuKGyXXa++6yC0cDKTz0vzrpmPiVhMU+Kuc8daOYUgVqyqyKoapBOBevR3zA9s0AsgXe Vzzg==
Received: by 10.68.235.34 with SMTP id uj2mr15314566pbc.74.1331487812178; Sun, 11 Mar 2012 10:43:32 -0700 (PDT)
Received: from [192.168.1.106] (q032020.dynamic.ppp.asahi-net.or.jp. [203.181.32.20]) by mx.google.com with ESMTPS id z10sm8535801pbq.55.2012.03.11.10.43.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 10:43:31 -0700 (PDT)
References: <62D85564-7961-4AB6-B1FA-B2DD75A4C74B@matake.jp> <90C41DD21FB7C64BB94121FBBC2E723453AFF08605@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08609@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08609@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <038CA61F-9DB3-45BC-8DEF-85738F50EA97@matake.jp>
X-Mailer: iPhone Mail (9B176)
From: nov matake 
Date: Mon, 12 Mar 2012 02:43:26 +0900
To: Eran Hammer 
X-Gm-Message-State: ALoCoQk4LTjNXQBAQVUhzZGVb76yWqDO39cKK/24FJmTntdXXpyp7l2oYfHrofVYexInHwez5YVz
Cc: nov matake , "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Clarification of "client application consisting of multiple components"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 17:43:35 -0000

I understood.
Thanks.

--
nov

On Mar 12, 2012, at 2:30 AM, Eran Hammer  wrote:

> That use case was removed from the specification. Either way, it is up to t=
he authorization server to decide which registration options to offer the cl=
ient if they make such a grant type available in the future, and how it will=
 apply the security policies. IOW, those proposing such an extension in the f=
uture will have to figure out how this should be handled.
>=20
> EH
>=20
>> -----Original Message-----
>> From: nov matake [mailto:nov@matake.jp]
>> Sent: Sunday, March 11, 2012 10:21 AM
>> To: Eran Hammer
>> Cc: nov matake; oauth@ietf.org WG
>> Subject: Re: [OAUTH-WG] Clarification of "client application consisting o=
f
>> multiple components"
>>=20
>> So what is the usecase of response_type=3Dtoken%20code ?
>> I thought, in that usecase, token was for the client's client-side compon=
ent,
>> code was for the client's server-side component, and both of them have th=
e
>> same client_id.
>>=20
>> --
>> nov
>>=20
>> On Mar 12, 2012, at 12:57 AM, Eran Hammer  wrote:
>>=20
>>> If you have two components each with different security profile, you mus=
t
>> assign each a different client_id. Otherwise, there is no way to enforce t=
he
>> rest of the spec's security requirements.
>>>=20
>>> EH
>>>=20
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>> Behalf Of nov matake
>>>> Sent: Sunday, March 11, 2012 8:25 AM
>>>> To: oauth@ietf.org WG
>>>> Subject: [OAUTH-WG] Clarification of "client application consisting
>>>> of multiple components"
>>>>=20
>>>> Hi,
>>>>=20
>>>> I just found this sentence in the latest draft.
>>>>=20
>>>> Does it mean "an application consisting of server-side and
>>>> client-side component (eg. foursquare iPhone app) MUST have separate
>>>> client_id for each component" ?
>>>> Or can I image something like Facebook is doing right now? (register
>>>> each component for a single client_id separately)
>>>>=20
>>>> =3D=3D
>>>> A client application consisting of multiple components, each with its
>>>> own client type (e.g. a distributed client with both a confidential
>>>> server-based component and a public browser-based component), MUST
>>>> register each component separately as a different client to ensure
>>>> proper handling by the authorization server.  The authorization
>>>> server MAY provider tools to manage such complex clients through a
>> single administration interface.
>>>> =3D=3D
>>>>=20
>>>> --
>>>> nov 
>>>> _______________________________________________
>>>> 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

From david@davidjfox.com  Sun Mar 11 19:11:02 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BCF21F8610 for ; Sun, 11 Mar 2012 19:11:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVlDzfmhr5ru for ; Sun, 11 Mar 2012 19:11:00 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6C8121F8637 for ; Sun, 11 Mar 2012 19:11:00 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so2376150ggm.31 for ; Sun, 11 Mar 2012 19:10:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=YjUWQa9VlYLnJ4xIXQf2wrL7Z4h6CpjHae3iZ1fMgZg=; b=j5173y0XHe6oF55OIdABiko3YeYkgI+YKTWMRgz2Yb2zGpBX/nQ+1dSNdzOVfzvRFQ qosHdlf2JS/SuyIH3hzExEzVqdCqvMoxQ+YypV2T8a+0xAeCZGXLgUVESnlFgsV9bsO0 /642mB2r4Jv638yikU7IqCDUbZXO/K9q9FPEkisod5l8bmmElOvOAxYAE/SzZ7vSEeXe qCR2DVBIvWpwXMbPj85W7TvxmGDZ7ovAFxkhPOVgSObSfErYEt9VfzOZx4yXlW744LI3 FtweBf0Z9+pE8HpWku6tIt7evH1eEXsiXWIhknQqIExsei33y7kqRWi1tS1UBN2NCRpJ gqUQ==
Received: by 10.60.8.103 with SMTP id q7mr954289oea.61.1331518259618; Sun, 11 Mar 2012 19:10:59 -0700 (PDT)
Received: from [192.168.0.195] (c-24-14-127-202.hsd1.il.comcast.net. [24.14.127.202]) by mx.google.com with ESMTPS id b6sm17967520obe.12.2012.03.11.19.10.58 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 19:10:58 -0700 (PDT)
Message-ID: <4F5D5B32.6090604@davidjfox.com>
Date: Sun, 11 Mar 2012 21:10:58 -0500
From: David Fox 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: 'OAuth WG' 
Content-Type: multipart/alternative; boundary="------------080003060604020606070900"
X-Gm-Message-State: ALoCoQmTyiPDglVeUAreIaraWP5JiWMjHiyosbsXWADsTjb4gyDDp3XvRpPPfBuzlso6WPH8kxY+
Subject: [OAUTH-WG] Issue token for another user
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 02:11:02 -0000

This is a multi-part message in MIME format.
--------------080003060604020606070900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8

In order to achieve the use case above, how would the client (a.k.a the 
resource owner in this case) specify which user to authorize?

Would the correct approach be to make a request to the Authorization 
Server with the grant type set to "client_credentials" and set the scope 
to user=user_id (where user_id would be the identifier for the user Bob)?

-David


--------------080003060604020606070900
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8

    

    In order to achieve the use case above, how would the client (a.k.a
    the resource owner in this case) specify which user to authorize?

    

    Would the correct approach be to make a request to the Authorization
    Server with the grant type set to "client_credentials" and set the
    scope to user=user_id (where user_id would be the identifier for the
    user Bob)?

    

    -David

    
  


--------------080003060604020606070900--

From sweeden@au1.ibm.com  Sun Mar 11 20:46:48 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DE121F851D for ; Sun, 11 Mar 2012 20:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.982
X-Spam-Level: 
X-Spam-Status: No, score=-6.982 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-k18yBrRb9v for ; Sun, 11 Mar 2012 20:46:48 -0700 (PDT)
Received: from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com [202.81.31.142]) by ietfa.amsl.com (Postfix) with ESMTP id B070A21F84F2 for ; Sun, 11 Mar 2012 20:46:45 -0700 (PDT)
Received: from /spool/local by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Mon, 12 Mar 2012 04:36:59 +1000
Received: from d23relay05.au.ibm.com (202.81.31.247) by e23smtp09.au.ibm.com (202.81.31.206) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Mon, 12 Mar 2012 04:36:54 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2C3ecWb2822254; Mon, 12 Mar 2012 14:40:38 +1100
Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2C3kNn9029859; Mon, 12 Mar 2012 14:46:24 +1100
Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2C3kMht029834; Mon, 12 Mar 2012 14:46:22 +1100
In-Reply-To: <4F5D5B32.6090604@davidjfox.com>
References: <4F5D5B32.6090604@davidjfox.com>
X-KeepSent: 6E1E8931:B04C85E3-4A2579BF:0012940C; type=4; name=$KeepSent
To: David Fox 
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: 
From: Shane B Weeden 
Date: Mon, 12 Mar 2012 13:46:18 +1000
X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.2FP1HF437 | June 7, 2011) at 12/03/2012 14:50:30
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
x-cbid: 12031118-3568-0000-0000-00000158E6A0
Cc: 'OAuth WG' , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Issue token for another user
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 03:46:48 -0000

IMO the scenario as documented doesn't make complete sense in the context
of OAuth 2.0 as it says that Bob uses the access token to access Alice's
photos. Clients in OAuth 2.0 are not people, they are programs.




From:	David Fox 
To:	"'OAuth WG'" 
Date:	12/03/2012 12:15 PM
Subject:	[OAUTH-WG] Issue token for another user
Sent by:	oauth-bounces@ietf.org



http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8

In order to achieve the use case above, how would the client (a.k.a the
resource owner in this case) specify which user to authorize?

Would the correct approach be to make a request to the Authorization Server
with the grant type set to "client_credentials" and set the scope to
user=user_id (where user_id would be the identifier for the user Bob)?

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



From wmills@yahoo-inc.com  Sun Mar 11 21:29:01 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAB621F8319 for ; Sun, 11 Mar 2012 21:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.398
X-Spam-Level: 
X-Spam-Status: No, score=-17.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8kYLUGO4xCi for ; Sun, 11 Mar 2012 21:29:00 -0700 (PDT)
Received: from nm11.bullet.mail.sp2.yahoo.com (nm11.bullet.mail.sp2.yahoo.com [98.139.91.81]) by ietfa.amsl.com (Postfix) with SMTP id 4425221F8419 for ; Sun, 11 Mar 2012 21:28:59 -0700 (PDT)
Received: from [98.139.91.65] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 12 Mar 2012 04:28:56 -0000
Received: from [98.139.91.2] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 12 Mar 2012 04:28:56 -0000
Received: from [127.0.0.1] by omp1002.mail.sp2.yahoo.com with NNFMP; 12 Mar 2012 04:28:56 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 68643.12051.bm@omp1002.mail.sp2.yahoo.com
Received: (qmail 56253 invoked by uid 60001); 12 Mar 2012 04:28:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1331526535; bh=Ge/5OioC7emyVe5ns9H8Lv9zNH99jA4gVnyX8n0REu0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=l8kDati3i547/h8/3H12cnHw9caexWv3/hM8f04PtK+Ss9CfW8f9r+BCEPE30V/0XkUi9iYGbL0PiJfU1zwd1lrfhMUiFhXbeHqh/mKK4nFx/Hud8MXv/HMctl/5uqRfWLCwdYet8SD/KX/SlnruuB+uhq88cz0G5WEuM/OjpyA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=AqKe98dAQHXghhAkzXm7rOqY1lLRRxk7JVorpP2IIlcs4XICkYpxGhM0rWGLce0PFur5zwxqQ3xgSYa0Hq9T+7grtODmra0TtH1VGGz8A8z2/P43ijMyQmAWJ29rkzuzIKhtnKpNWwfW0Nl7ud4gw3Ir4vvBrfsCaw6IkKVT33I=;
X-YMail-OSG: 46c9QmMVM1n5lBOoTOygYu7xHHiAsZkN3ZWAE_ZtjTpjP.s uoul3yEpRkhtDQQ8.KsyUN0IvGpKhRoHkcgdIFPBvsMnpNvx9Gdm0Ud57Jp_ suVlsp7Z_sp4XzCKf7joy9H5oUbFxW4c016vWodp5PNIMkFHGSgO3cPZs1NW LCC.e7zDl4AIcBb_mDZJKHRTfxZ2duJmthwlUODeyDnXXHhNr_NmaMI76P1u FMP5NRIvzhSSEbxNYIzSFk5YLNO2RJT6EVZ0ZtsMLZZ_2Rw4dADgSEiNeKBB qSp6AOV5hVkdAW6Dvx17bveZtGoxMHLBpdivRr7kFz3c9dJe3ea.hIU1mIS4 fZ1SmTVVvbgr48r_2wODBX6U.T4TzJVRhLxzUesjaiGqFrnvcCD4QicNcbtJ bJ7OeJIASuza9VtiB6dKMD7zRwvdqJgrIpFL9gIRNWQ2gX22TIISAibO_BUh yaqHRUiS0say5o1qBHkuvK8jNOpS4zdJ_6nlixI4Zx0qGYarefDqAGfiYlWH 51LW1TpJ3i5YJ8gdki82JSFnRhIamfB6HF2qBb3kX5yM-
Received: from [99.31.212.42] by web31806.mail.mud.yahoo.com via HTTP; Sun, 11 Mar 2012 21:28:55 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.117.340979
References: <4F5D5B32.6090604@davidjfox.com>
Message-ID: <1331526535.91064.YahooMailNeo@web31806.mail.mud.yahoo.com>
Date: Sun, 11 Mar 2012 21:28:55 -0700 (PDT)
From: William Mills 
To: David Fox , 'OAuth WG' 
In-Reply-To: <4F5D5B32.6090604@davidjfox.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1055047407-490280357-1331526535=:91064"
Subject: Re: [OAUTH-WG] Issue token for another user
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 04:29:01 -0000

---1055047407-490280357-1331526535=:91064
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Can you specify the user being accesses as the resource in the URL?=0A=0A=
=A0=0A=0A=0AP.S. Please start using the http://twiki.corp.yahoo.com/view/Pa=
ranoidyahoos/SecurityRequest=A0 for new requests like product and feature=
=A0 reviews.=0A=0A=0A=0A>________________________________=0A> From: David F=
ox =0A>To: 'OAuth WG'  =0A>Sent: Sunda=
y, March 11, 2012 7:10 PM=0A>Subject: [OAUTH-WG] Issue token for another us=
er=0A> =0A>=0A>http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#=
section-3.8=0A>=0A>In order to achieve the use case above, how would the cl=
ient (a.k.a=0A    the resource owner in this case) specify which user to au=
thorize?=0A>=0A>Would the correct approach be to make a request to the Auth=
orization=0A    Server with the grant type set to "client_credentials" and =
set the=0A    scope to user=3Duser_id (where user_id would be the identifie=
r for the=0A    user Bob)?=0A>=0A>-David=0A> =0A>__________________________=
_____________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://ww=
w.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A>
---1055047407-490280357-1331526535=:91064
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


Can you specify the user being accesses as the resource in the URL?
 


P.S. Please =
start using the http://twiki.corp.yahoo.com/view/Paranoidyahoos/SecurityReq=
uest  for new requests like product and feature  reviews.

=
 
  
 
 
  
  <=
b>From: David Fox <david@da=
vidjfox.com>
 To: 'O=
Auth WG'
 <oauth@ietf.org> 
 Sent: Sunday, March 11, 2012 7:10 PM
 Subject: [OAUTH-WG] Issue token for another user
  
 
=0A
=0A  =0A=0A    =0A  =0A  
=
=0A    http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-=
3.8
=0A    
=0A    In order to achieve the use case above, how would =
the client (a.k.a=0A    the resource owner in this case) specify which user=
 to authorize?
=0A    
=0A    Would the correct approach be to make a=
 request to the Authorization=0A    Server with the grant type set to "clie=
nt_credentials" and set the=0A    scope to user=3Duser_id (where user_id wo=
uld be the identifier for the=0A    user Bob)?
=0A    
=0A    -David<=
br>=0A    =0A  
=0A=0A=


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

 
 
 
  

---1055047407-490280357-1331526535=:91064--

From david@davidjfox.com  Sun Mar 11 21:47:12 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C4F21F85B1 for ; Sun, 11 Mar 2012 21:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsQ69QvqSW8N for ; Sun, 11 Mar 2012 21:47:11 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCD2C21F85A4 for ; Sun, 11 Mar 2012 21:47:10 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so2437882ghb.31 for ; Sun, 11 Mar 2012 21:47:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=kjqzZV1z0TO3dM2ddutK3CImYaXJVapTPQBCRDA+xNc=; b=E6FKkqHa+lOY4Ye9KusA/3fe69aY+IjHzuaaYPiIjRrjcjHdQkZ10GX3ecQDZPEQow TKXy6cG4jlIIErJN6wEfhGJ2GUOBfcIwcW+TrPvRYTTzcGmG3cqSH9ir525qICCX1YMF hrkJBXxFJVDjbZ57Anqr8fGBwbp0qS+pUXiagjuOdafoJRXIBKgpUpTqujLWzXFbUKR6 j11EFKSy6p50VP8FR4VAvETI28YacdyYfvK78OdPXXC9hUMd9b6iGXWlSyHUNqnRu9Ju J+iiu2ei3OP5L/xsixVXbKMWXX1oJvMFD98xkffSMh/aUUkPOiOqjv1xv+qFEe2A7Is+ Hl6g==
Received: by 10.60.14.36 with SMTP id m4mr6133489oec.37.1331527630267; Sun, 11 Mar 2012 21:47:10 -0700 (PDT)
Received: from [192.168.0.195] (c-24-14-127-202.hsd1.il.comcast.net. [24.14.127.202]) by mx.google.com with ESMTPS id j9sm17536591obl.21.2012.03.11.21.47.09 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 21:47:09 -0700 (PDT)
Message-ID: <4F5D7FCE.5090105@davidjfox.com>
Date: Sun, 11 Mar 2012 23:47:10 -0500
From: David Fox 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: William Mills 
References: <4F5D5B32.6090604@davidjfox.com> <1331526535.91064.YahooMailNeo@web31806.mail.mud.yahoo.com>
In-Reply-To: <1331526535.91064.YahooMailNeo@web31806.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary="------------090201040008000908040805"
X-Gm-Message-State: ALoCoQlDnXjp3bQ1HNWUkUeJ+cCyL4pcuhsGol5TAbmmSfzzwiPlLgBDGyR4dIaZosVyM9g5+/Ts
Cc: 'OAuth WG' 
Subject: Re: [OAUTH-WG] Issue token for another user
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 04:47:12 -0000

This is a multi-part message in MIME format.
--------------090201040008000908040805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

@Shane: Good point, and in my application the user/client would be 
authorizing another registered program. Was just using Bob to keep with 
the example.

@William:
1. I'm just building the API now so anything is possible, but could you 
give me an example of what you mean?
2. Sure will do, though, if that is a website, I'm not able to connect 
to it.

On 3/11/2012 23:28, William Mills wrote:
> Can you specify the user being accesses as the resource in the URL?
>
>
> P.S. Please start using the 
> http://twiki.corp.yahoo.com/view/Paranoidyahoos/SecurityRequest  for 
> new requests like product and feature  reviews.
>
>     ------------------------------------------------------------------------
>     *From:* David Fox 
>     *To:* 'OAuth WG' 
>     *Sent:* Sunday, March 11, 2012 7:10 PM
>     *Subject:* [OAUTH-WG] Issue token for another user
>
>     http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8
>
>     In order to achieve the use case above, how would the client
>     (a.k.a the resource owner in this case) specify which user to
>     authorize?
>
>     Would the correct approach be to make a request to the
>     Authorization Server with the grant type set to
>     "client_credentials" and set the scope to user=user_id (where
>     user_id would be the identifier for the user Bob)?
>
>     -David
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>

--------------090201040008000908040805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    @Shane: Good point, and in my application the user/client would be
    authorizing another registered program. Was just using Bob to keep
    with the example.

    

    @William:

    1. I'm just building the API now so anything is possible, but could
    you give me an example of what you mean?

    2. Sure will do, though, if that is a website, I'm not able to
    connect to it.

    

    On 3/11/2012 23:28, William Mills wrote:
    

      

        
Can you specify the user being accesses as the
            resource in the URL?

          

        
 

        


          

        

        
P.S. Please start using the
          http://twiki.corp.yahoo.com/view/Paranoidyahoos/SecurityRequest 
          for new requests like product and feature  reviews.

          

          

            

              

                
 
                    
 From:
                    David Fox <david@davidjfox.com>

                    To:
                    'OAuth WG' <oauth@ietf.org> 

                    Sent:
                    Sunday, March 11, 2012 7:10 PM

                    Subject:
                    [OAUTH-WG] Issue token for another user

                   

                

                

                  

                    http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8

                    

                    In order to achieve the use case above, how would
                    the client (a.k.a the resource owner in this case)
                    specify which user to authorize?

                    

                    Would the correct approach be to make a request to
                    the Authorization Server with the grant type set to
                    "client_credentials" and set the scope to
                    user=user_id (where user_id would be the identifier
                    for the user Bob)?

                    

                    -David

                  

                

                

                _______________________________________________

                OAuth mailing list

                OAuth@ietf.org

                https://www.ietf.org/mailman/listinfo/oauth

                

                

              

            

          

        

      

    

  


--------------090201040008000908040805--

From wmills@yahoo-inc.com  Sun Mar 11 22:10:15 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4338921F84E1 for ; Sun, 11 Mar 2012 22:10:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.408
X-Spam-Level: 
X-Spam-Status: No, score=-17.408 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCOtvkdn2X9T for ; Sun, 11 Mar 2012 22:10:13 -0700 (PDT)
Received: from nm36-vm7.bullet.mail.ne1.yahoo.com (nm36-vm7.bullet.mail.ne1.yahoo.com [98.138.229.119]) by ietfa.amsl.com (Postfix) with SMTP id E92EE21F84F5 for ; Sun, 11 Mar 2012 22:10:10 -0700 (PDT)
Received: from [98.138.90.54] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 12 Mar 2012 05:10:05 -0000
Received: from [98.138.89.233] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 12 Mar 2012 05:10:05 -0000
Received: from [127.0.0.1] by omp1048.mail.ne1.yahoo.com with NNFMP; 12 Mar 2012 05:10:05 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 108867.39587.bm@omp1048.mail.ne1.yahoo.com
Received: (qmail 25390 invoked by uid 60001); 12 Mar 2012 05:10:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1331529004; bh=oKqAt9ylgXm8XVQBph5VGSgkO2NJirpuXJZM0na9UVI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EYA+yzFkvi+mXv0MhQBpLu0eBd0rLfNZJpNOhKjgK7s4/yYoF0Igje0EtVEbhhk48grSlL9YrPc2ZqZAXEqtHz3uvl8Ai2u6ZvJxbyYpP8ffQ2S3/vVxv9QZC+hVge3JUPg/V3Qm/WLB3JgzM6Pxg29Jl5HhmYFdz7U21dlaMcc=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fVbdeSPu4FiqdK5OjjZTbY5PpfN/ZV+JNjkzJY70GXcGFWPgT2nnL9aoc/OM582vJHpDaiXVuZ2gxn0u1n/q5+vHfS8kJKl0Qh1nWsV2j8I9nG90WyknYUg4Q7T9bAHRB15I1RUaVds/7SsNtEiSe18ZRbhFEa82Epo3isjU914=;
X-YMail-OSG: 9kZXgnIVM1lihow0Dpwdm_Ff9pLznpCMvaJjqU11M4NnYG9 Gz_GKILg81uSgR9N6d4SNzlAgqIiLfnHGmBMyAsxRa875QEq.XOJgpB9tQlJ 1ykNbsKA_oejQ9cguoybAtStEduzrCDWBa0AAZ18khZM08v2Ww1XtQjnnnk2 3M2wgSHne3vTYWjFbNU58kpC2K4BvfvKFhbhl5CPfjFhpKhdgU98Vx5Kq3Wu G8sUZWO_akthmNdRolCvZdAcFW_SH4R0c45GXjkrsBijdDb2eXByiLQQXrYy jonkZuFajjFAnHpthfuDYET_RsIrdm3ndnaQ2XSSXvM8zsRiG_rzDogHf_0Q DoZvzn5MRE9gsLMsrCAsp41mqPRlDaH.IKMAyJ36Q18uiQkcfb1mT49lcp_m bt60nLQzGD3CqbTMDYbBW4NDGekzRXx3U3PGtjQ.mLIticqwzEX7yBseQaeT hqC4aasRKTCOqqHCrr8XAb03GBBunfGZOH6VutQfEvYdehFFWmY3___kANDp eP8YN4kGcaHxPXS961S4xs.JDzzpIuri8DSRC8GnWmbA-
Received: from [99.31.212.42] by web31810.mail.mud.yahoo.com via HTTP; Sun, 11 Mar 2012 22:10:04 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.117.340979
References: <4F5D5B32.6090604@davidjfox.com> <1331526535.91064.YahooMailNeo@web31806.mail.mud.yahoo.com> <4F5D7FCE.5090105@davidjfox.com>
Message-ID: <1331529004.95097.YahooMailNeo@web31810.mail.mud.yahoo.com>
Date: Sun, 11 Mar 2012 22:10:04 -0700 (PDT)
From: William Mills 
To: David Fox 
In-Reply-To: <4F5D7FCE.5090105@davidjfox.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1935884094-1363949482-1331529004=:95097"
Cc: 'OAuth WG' 
Subject: Re: [OAUTH-WG] Issue token for another user
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 05:10:15 -0000

--1935884094-1363949482-1331529004=:95097
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

So Bob has already issued credentials to App-A and now needs to authorize A=
pp-B?=0A=0A=0A=0A=0A=0A>________________________________=0A> From: David Fo=
x =0A>To: William Mills  =0A>Cc:=
 'OAuth WG' ; sweeden@au1.ibm.com =0A>Sent: Sunday, March 1=
1, 2012 9:47 PM=0A>Subject: Re: [OAUTH-WG] Issue token for another user=0A>=
 =0A>=0A>@Shane: Good point, and in my application the user/client would be=
 authorizing another registered program. Was just using Bob to keep with th=
e example.=0A>=0A>@William:=0A>1. I'm just building the API now so anything=
 is possible, but could=0A    you give me an example of what you mean?=0A>2=
. Sure will do, though, if that is a website, I'm not able to=0A    connect=
 to it.=0A>=0A>On 3/11/2012 23:28, William Mills wrote: =0A>Can you specify=
 the user being accesses as the resource in the URL?=0A>>=0A>>=A0=0A>>=0A>>=
=0A>>=0A>>P.S. Please start using the http://twiki.corp.yahoo.com/view/Para=
noidyahoos/SecurityRequest=A0 for new requests like product and feature=A0 =
reviews.=0A>>=0A>>=0A>>=0A>>>________________________________=0A>>> From: D=
avid Fox =0A>>>To: 'OAuth WG'  =0A>>>S=
ent: Sunday, March 11, 2012 7:10 PM=0A>>>Subject: [OAUTH-WG] Issue token fo=
r another user=0A>>> =0A>>>=0A>>>http://tools.ietf.org/html/draft-zeltsan-o=
auth-use-cases-02#section-3.8=0A>>>=0A>>>In order to achieve the use case a=
bove, how would=0A                    the client (a.k.a the resource owner =
in this case)=0A                    specify which user to authorize?=0A>>>=
=0A>>>Would the correct approach be to make a request to=0A                =
    the Authorization Server with the grant type set to=0A                 =
   "client_credentials" and set the scope to=0A                    user=3Du=
ser_id (where user_id would be the identifier=0A                    for the=
 user Bob)?=0A>>>=0A>>>-David=0A>>>=0A>>>__________________________________=
_____________=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https://www.=
ietf.org/mailman/listinfo/oauth=0A>>>=0A>>>=0A>>>=0A>=0A>
--1935884094-1363949482-1331529004=:95097
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


So Bob ha=
s already issued credentials to App-A and now needs to authorize App-B?
=

 

  
 
 
  
  From: David Fox=
 <david@davidjfox.com>
 To:<=
/span> William Mills <wmills@yahoo-inc.com> 
Cc: 'OAuth WG' <oauth@ietf.org>; swee=
den@au1.ibm.com 
 Sent:=
 Sunday, March
 11, 2012 9:47 PM
 Subject:=
 Re: [OAUTH-WG] Issue token for another user
  
 
=0A=

=0A  =0A=0A    =0A  =0A  
=0A    @Shane: Good=
 point, and in my application the user/client would be=0A    authorizing an=
other registered program. Was just using Bob to keep=0A    with the example=
.
=0A    
=0A    @William:
=0A    1. I'm just building the API now=
 so anything is possible, but could=0A    you give me an example of what yo=
u mean?
=0A    2. Sure will do, though, if that is a website, I'm not ab=
le to=0A    connect to it.
=0A    
=0A    On 3/11/2012 23:28, William=
 Mills wrote:=0A    
=0A      
=0A        
Can you specify the =
user being accesses as the=0A            resource in the URL?
=0A       =
   
=0A        
 
=0A        

=0A        =
  
=0A        
=0A        
P.S. Please start using the=0A      =
    http://twiki.corp.yahoo.com/view/Paranoidyahoos/SecurityRequest =
=0A          for new requests like product and feature  reviews.
=
=0A          
=0A          
=0A       =
     
=0A              
=0A                
 =0A                    
 From:=0A           =
         David Fox <david@davidjfox.com>
=0A          =
          To:=0A           =
         'OAuth WG' <oauth@ietf.org> 
=0A                    =
Sent:=0A                    Su=
nday, March 11, 2012 7:10 PM
=0A                    Subject:=0A                    [OAUTH-WG] Issue=
 token for another user
=0A                   
=0A          =
      
=0A                
=0A                 =
 
=0A                    http://tools.ietf.org/html/draft-zeltsan-oauth=
-use-cases-02#section-3.8
=0A                    
=0A                =
    In order to achieve the use case above, how would=0A                   =
 the client (a.k.a the resource owner in this case)=0A                    s=
pecify which user to authorize?
=0A                    
=0A          =
          Would the correct approach be to make a request to=0A            =
        the Authorization Server with the grant type set to=0A             =
       "client_credentials" and set the scope to=0A                    user=
=3Duser_id (where user_id would be the identifier=0A                    for=
 the user Bob)?
=0A                    
=0A                    -David=

=0A                  
=0A                
=0A                =

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


 
 
 
  

--1935884094-1363949482-1331529004=:95097--

From david@davidjfox.com  Sun Mar 11 22:24:12 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69A721F84FC for ; Sun, 11 Mar 2012 22:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ScO3gMjOLLy for ; Sun, 11 Mar 2012 22:24:09 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8DB321F84F7 for ; Sun, 11 Mar 2012 22:23:58 -0700 (PDT)
Received: by yhpp34 with SMTP id p34so2450542yhp.31 for ; Sun, 11 Mar 2012 22:23:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=nEZoIjC1+ugmOXuZv+IBc1y+yTeZFtUQi/2p/ZijNQ0=; b=Crr9NnfzGUjFZcQuqIIILbc6xRwWD4Cd3U3c9pjw1Lv7S8T/LP3vg6B2WzbcaB/76S Tg36jZ6c16WYwpNf97aessg5VoVgjV18NCylshFEGSD3loVKeVcnAd/5XRj/frKz5+yq T8ZQZYFLdSIKD4UDzWTXlc19ypt/EwDcrabd43ClpDAlrZFF+WqtFfLRT9Bi8FcTIfxs hmDTK4SPLcivX0kDHWxBn6p60gtzXigQvo745Fl1Iv/2D/PNFMUwV7kNHFSLfnAf0dEr w4yj7Eo7zFjWTKYLlREBn3kRVI9XwrrRYLo2pjbqpRySL9YbfOd3NqoLoFmgqn+GEKU6 Ja3g==
Received: by 10.60.14.36 with SMTP id m4mr6189828oec.37.1331529838164; Sun, 11 Mar 2012 22:23:58 -0700 (PDT)
Received: from [192.168.0.195] (c-24-14-127-202.hsd1.il.comcast.net. [24.14.127.202]) by mx.google.com with ESMTPS id a6sm9565830oea.13.2012.03.11.22.23.57 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 22:23:57 -0700 (PDT)
Message-ID: <4F5D886D.5080207@davidjfox.com>
Date: Mon, 12 Mar 2012 00:23:57 -0500
From: David Fox 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: William Mills 
References: <4F5D5B32.6090604@davidjfox.com> <1331526535.91064.YahooMailNeo@web31806.mail.mud.yahoo.com> <4F5D7FCE.5090105@davidjfox.com> <1331529004.95097.YahooMailNeo@web31810.mail.mud.yahoo.com>
In-Reply-To: <1331529004.95097.YahooMailNeo@web31810.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary="------------040205020509050706040406"
X-Gm-Message-State: ALoCoQm365LsrGbadIm8IM/SlHFGSxCDMZ9kO8ntdK33tQjJ7/yS+wzVg7LpSiz7T4gbe9Hkjuei
Cc: 'OAuth WG' 
Subject: Re: [OAUTH-WG] Issue token for another user
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 05:24:13 -0000

This is a multi-part message in MIME format.
--------------040205020509050706040406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

More like, Bill (client/resource owner) wants to authorize and generate 
a token for App-B.

On 3/12/2012 00:10, William Mills wrote:
> So Bob has already issued credentials to App-A and now needs to 
> authorize App-B?
>
>
>     ------------------------------------------------------------------------
>     *From:* David Fox 
>     *To:* William Mills 
>     *Cc:* 'OAuth WG' ; sweeden@au1.ibm.com
>     *Sent:* Sunday, March 11, 2012 9:47 PM
>     *Subject:* Re: [OAUTH-WG] Issue token for another user
>
>     @Shane: Good point, and in my application the user/client would be
>     authorizing another registered program. Was just using Bob to keep
>     with the example.
>
>     @William:
>     1. I'm just building the API now so anything is possible, but
>     could you give me an example of what you mean?
>     2. Sure will do, though, if that is a website, I'm not able to
>     connect to it.
>
>     On 3/11/2012 23:28, William Mills wrote:
>>     Can you specify the user being accesses as the resource in the URL?
>>
>>
>>     P.S. Please start using the
>>     http://twiki.corp.yahoo.com/view/Paranoidyahoos/SecurityRequest 
>>     for new requests like product and feature  reviews.
>>
>>         ------------------------------------------------------------------------
>>         *From:* David Fox 
>>         
>>         *To:* 'OAuth WG'  
>>         *Sent:* Sunday, March 11, 2012 7:10 PM
>>         *Subject:* [OAUTH-WG] Issue token for another user
>>
>>         http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8
>>
>>         In order to achieve the use case above, how would the client
>>         (a.k.a the resource owner in this case) specify which user to
>>         authorize?
>>
>>         Would the correct approach be to make a request to the
>>         Authorization Server with the grant type set to
>>         "client_credentials" and set the scope to user=user_id (where
>>         user_id would be the identifier for the user Bob)?
>>
>>         -David
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>

--------------040205020509050706040406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    More like, Bill (client/resource owner) wants to authorize and
    generate a token for App-B.

    

    On 3/12/2012 00:10, William Mills wrote:
    

      
So
        Bob has already issued credentials to App-A and now needs to
        authorize App-B?

        

        


          

            

              

                
 
                    
 From:
                    David Fox <david@davidjfox.com>

                    To:
                    William Mills <wmills@yahoo-inc.com> 

                    Cc:
                    'OAuth WG' <oauth@ietf.org>;
                    sweeden@au1.ibm.com 

                    Sent:
                    Sunday, March 11, 2012 9:47 PM

                    Subject:
                    Re: [OAUTH-WG] Issue token for another user

                   

                

                

                  
 @Shane: Good point, and in my application the
                    user/client would be authorizing another registered
                    program. Was just using Bob to keep with the
                    example.

                    

                    @William:

                    1. I'm just building the API now so anything is
                    possible, but could you give me an example of what
                    you mean?

                    2. Sure will do, though, if that is a website, I'm
                    not able to connect to it.

                    

                    On 3/11/2012 23:28, William Mills wrote:
                    

                      

                        
Can you specify the user being
                            accesses as the resource in the URL?

                          

                        
 

                        


                          

                        

                        
P.S. Please start using the
                          http://twiki.corp.yahoo.com/view/Paranoidyahoos/SecurityRequest 
                          for new requests like product and feature 
                          reviews.

                          

                          

                            

                              

                                
 
                                    
 From:
                                    David Fox <david@davidjfox.com>

                                    To:
                                    'OAuth WG' <oauth@ietf.org>
                                    

                                    Sent:
                                    Sunday, March 11, 2012 7:10 PM

                                    Subject:
                                    [OAUTH-WG] Issue token for another
                                    user

                                   

                                

                                

                                  

                                    http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8

                                    

                                    In order to achieve the use case
                                    above, how would the client (a.k.a
                                    the resource owner in this case)
                                    specify which user to authorize?

                                    

                                    Would the correct approach be to
                                    make a request to the Authorization
                                    Server with the grant type set to
                                    "client_credentials" and set the
                                    scope to user=user_id (where user_id
                                    would be the identifier for the user
                                    Bob)?

                                    

                                    -David

                                  

                                

                                

_______________________________________________

                                OAuth mailing list

                                OAuth@ietf.org

                                https://www.ietf.org/mailman/listinfo/oauth

                                

                                

                              

                            

                          

                        

                      

                    

                  

                

                

                

              

            

          

        

      

    

  


--------------040205020509050706040406--

From eve@xmlgrrl.com  Sun Mar 11 22:43:08 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE56121F8562 for ; Sun, 11 Mar 2012 22:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.293
X-Spam-Level: 
X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaQD6RzvQRTn for ; Sun, 11 Mar 2012 22:43:04 -0700 (PDT)
Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07821F850C for ; Sun, 11 Mar 2012 22:43:04 -0700 (PDT)
Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q2C5h1q3007870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Mar 2012 22:43:02 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5A79A381-768C-493D-B556-D8B7C7865630"
From: Eve Maler 
In-Reply-To: <4F5D5B32.6090604@davidjfox.com>
Date: Sun, 11 Mar 2012 22:43:01 -0700
Message-Id: 
References: <4F5D5B32.6090604@davidjfox.com>
To: David Fox 
X-Mailer: Apple Mail (2.1257)
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Issue token for another user
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 05:43:11 -0000

--Apple-Mail=_5A79A381-768C-493D-B556-D8B7C7865630
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

As written in the I-D, the use case does call for person-to-person =
sharing, which OAuth in its current state doesn't really cover. If you =
do want to achieve that outcome, User-Managed Access, built on top of =
OAuth, specializes in it. You can find out more at =
http://kantarainitiative.org/confluence/display/uma/Home . (We're =
holding a Twitter #umachat this Wednesday 9-10am PT if you want to =
deep-dive on UMA one tweet at a time.)

	Eve

On 11 Mar 2012, at 7:10 PM, David Fox wrote:

> =
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8
>=20
> In order to achieve the use case above, how would the client (a.k.a =
the resource owner in this case) specify which user to authorize?
>=20
> Would the correct approach be to make a request to the Authorization =
Server with the grant type set to "client_credentials" and set the scope =
to user=3Duser_id (where user_id would be the identifier for the user =
Bob)?
>=20
> -David
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


--Apple-Mail=_5A79A381-768C-493D-B556-D8B7C7865630
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

http://k=
antarainitiative.org/confluence/display/uma/Home . (We're holding a =
Twitter #umachat this Wednesday 9-10am PT if you want to deep-dive on =
UMA one tweet at a time.)

	=
Eve

On 11 Mar 2012, at 7:10 PM, David Fox =
wrote:


 =20

   =20
 =20
  

    http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section=
-3.8

    

    In order to achieve the use case above, how would the client (a.k.a
    the resource owner in this case) specify which user to =
authorize?

    

    Would the correct approach be to make a request to the Authorization
    Server with the grant type set to "client_credentials" and set the
    scope to user=3Duser_id (where user_id would be the identifier for =
the
    user Bob)?

    

    -David

    
  


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




Eve Maler       =
                    =
       http://www.xmlgrrl.com/blog
=

+1 425 345 6756               =
          http://www.twitter.com/xmlgrrl=





=

--Apple-Mail=_5A79A381-768C-493D-B556-D8B7C7865630--

From david@davidjfox.com  Mon Mar 12 00:04:46 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E217221F854A for ; Mon, 12 Mar 2012 00:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.195
X-Spam-Level: 
X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfOYz5riV4qs for ; Mon, 12 Mar 2012 00:04:44 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4244D21F8531 for ; Mon, 12 Mar 2012 00:04:41 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so2511277ghb.31 for ; Mon, 12 Mar 2012 00:04:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=dWjIqHxwEe3qNt8bEVhqLzyzQz/YunAYCy97RcJvs0A=; b=CogVr5GMuoO+Sz/zPWp0DiKTFQ1us2XicDQPnn5zAwPu+OT3yavFtKHHPp9/Bk0XOB mULeQ4ssN4YGgXRpQQi4kNus2dIRmgxUsbMP6DapFcvOx6I1ISF2oTVtYidqnol/06AA gGmgNabh4pcFbIhxfb8bEKp1pJn6z5soKTX+Wpn6/IlxMVR2XbklGjGweE98qqbCq7Eu 7XNK2SudDxHUPC5iCI1owotcSqsoO7yqGYGglLTMYw+xC5Cr1o0AOH516VErJEW1YzUw guU/TOWB/o/8oHbUIxPYpVv5wUDY4b3j1N0qsb4lMRLfopLVno3+yr6+mT984p22sB28 Ve9w==
Received: by 10.182.38.7 with SMTP id c7mr6338310obk.44.1331535881086; Mon, 12 Mar 2012 00:04:41 -0700 (PDT)
Received: from [192.168.0.195] (c-24-14-127-202.hsd1.il.comcast.net. [24.14.127.202]) by mx.google.com with ESMTPS id gl4sm19165699obb.23.2012.03.12.00.04.39 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 00:04:40 -0700 (PDT)
Message-ID: <4F5DA008.60809@davidjfox.com>
Date: Mon, 12 Mar 2012 02:04:40 -0500
From: David Fox 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Eve Maler 
References: <4F5D5B32.6090604@davidjfox.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080305090101010500080302"
X-Gm-Message-State: ALoCoQnfC638Z9qlgp4/Xq1OjwNdkC/lV4bzzocxcwLkkXX1KOpEuVcmOfZwtE0Ce38cpNYFDbQx
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Issue token for another user
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 07:04:46 -0000

This is a multi-part message in MIME format.
--------------080305090101010500080302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This looks identical to what I want to do, i'll definitely hop on the 
tweet chat.

Also, do you know of any good resources touching on how to implement this?

Thanks :)

On 3/12/2012 00:43, Eve Maler wrote:
> As written in the I-D, the use case does call for person-to-person 
> sharing, which OAuth in its current state doesn't really cover. If you 
> do want to achieve that outcome, User-Managed Access, built on top of 
> OAuth, specializes in it. You can find out more at 
> http://kantarainitiative.org/confluence/display/uma/Home . (We're 
> holding a Twitter #umachat this Wednesday 9-10am PT if you want to 
> deep-dive on UMA one tweet at a time.)
>
> Eve
>
> On 11 Mar 2012, at 7:10 PM, David Fox wrote:
>
>> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8
>>
>> In order to achieve the use case above, how would the client (a.k.a 
>> the resource owner in this case) specify which user to authorize?
>>
>> Would the correct approach be to make a request to the Authorization 
>> Server with the grant type set to "client_credentials" and set the 
>> scope to user=user_id (where user_id would be the identifier for the 
>> user Bob)?
>>
>> -David
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> Eve Maler http://www.xmlgrrl.com/blog
> +1 425 345 6756 http://www.twitter.com/xmlgrrl
>

--------------080305090101010500080302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    This looks identical to what I want to do, i'll definitely hop on
    the tweet chat.

    

    Also, do you know of any good resources touching on how to implement
    this?

    

    Thanks :)

    

    On 3/12/2012 00:43, Eve Maler wrote:
    

      
As written in the I-D, the use case does call for
        person-to-person sharing, which OAuth in its current state
        doesn't really cover. If you do want to achieve that outcome,
        User-Managed Access, built on top of OAuth, specializes in it.
        You can find out more at http://kantarainitiative.org/confluence/display/uma/Home
        . (We're holding a Twitter #umachat this Wednesday 9-10am PT if
        you want to deep-dive on UMA one tweet at a time.)

      


      

      
 Eve

      

      

        
On 11 Mar 2012, at 7:10 PM, David Fox wrote:

        

        

          
 http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8

            

            In order to achieve the use case above, how would the client
            (a.k.a the resource owner in this case) specify which user
            to authorize?

            

            Would the correct approach be to make a request to the
            Authorization Server with the grant type set to
            "client_credentials" and set the scope to user=user_id
            (where user_id would be the identifier for the user Bob)?

            

            -David

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

          https://www.ietf.org/mailman/listinfo/oauth

        

      

      

      

        
            

                

                    

                        

                            


                              Eve Maler                                
                               http://www.xmlgrrl.com/blog

                            
+1 425 345 6756                        
                              http://www.twitter.com/xmlgrrl

                          

                      

                  

              

          
      

      

    

  


--------------080305090101010500080302--

From gffletch@aol.com  Mon Mar 12 07:08:48 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC12C21F85AF for ; Mon, 12 Mar 2012 07:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.87
X-Spam-Level: 
X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.728,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CheiOcIaST0F for ; Mon, 12 Mar 2012 07:08:45 -0700 (PDT)
Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by ietfa.amsl.com (Postfix) with ESMTP id ADF0921F8567 for ; Mon, 12 Mar 2012 07:08:43 -0700 (PDT)
Received: from mtaout-ma05.r1000.mx.aol.com (mtaout-ma05.r1000.mx.aol.com [172.29.41.5]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id q2CE8WLI032247; Mon, 12 Mar 2012 10:08:32 -0400
Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 679B1E000141; Mon, 12 Mar 2012 10:08:32 -0400 (EDT)
Message-ID: <4F5E0360.8060700@aol.com>
Date: Mon, 12 Mar 2012 10:08:32 -0400
From: George Fletcher 
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Richer, Justin P." 
References: <4E1F6AAD24975D4BA5B168042967394366402261@TK5EX14MBXC284.redmond.corp.microsoft.com> <6C7AC84B-F4F3-4069-9144-65B193D0F882@ve7jtb.com>,  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090900070108010405010804"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1331561312; bh=gqkI6B4kHf+M1wxFdWaU3GIPBYHaVfZfY/eOFVURmYE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=YQjLiUSet73aV2chK9NJL1KcwTnDqN0xfqKnnhFIRrWXuA1ZopgDCchZdDv5nM9KP Jo/5JS4Y7r2TVAiXI0QF/TUdm7/F57kVE5aWhTXN0kS0AyxcoPs8W9LXjaWcnrlEZX sf+hrwb95g6h0zBVypOjbRVpR02/HP9R4AIVyu6A=
X-AOL-SCOLL-SCORE: 0:2:509327136:93952408  
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d29054f5e03602060
X-AOL-IP: 10.181.186.254
Cc: oauth 
Subject: Re: [OAUTH-WG] question about the b64token syntax in	draft-ietf-oauth-v2-bearer
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 14:08:48 -0000

This is a multi-part message in MIME format.
--------------090900070108010405010804
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

+1

On 3/11/12 12:45 PM, Richer, Justin P. wrote:
> +1
> ------------------------------------------------------------------------
> *From:* oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of 
> Brian Campbell [bcampbell@pingidentity.com]
> *Sent:* Sunday, March 11, 2012 9:50 AM
> *To:* John Bradley
> *Cc:* oauth
> *Subject:* Re: [OAUTH-WG] question about the b64token syntax in 
> draft-ietf-oauth-v2-bearer
>
> +1
>
> On Mar 11, 2012 7:08 AM, "John Bradley"  > wrote:
>
>     +1
>
>     Sent from my iPhone
>
>     On 2012-03-10, at 12:49 PM, Mike Jones
>     >
>     wrote:
>
>>     I plan to make the change to the example access token value to
>>     mF_9.B5f-4.1JqMbefore Monday’s submission deadline, per the
>>     requests for b64token syntax clarification.  I’m also considering
>>     adding an access token response example, pre the requests in this
>>     thread.  I would propose adding the following new text for this
>>     in a new Section 4 (before the current Security Considerations). 
>>     This is largely parallel to what is done in Section 5.1 of the
>>     MAC spec.
>>
>>     *4.  Example Access Token Response*
>>
>>     Typically a bearer token is returned to the client as part of an
>>     OAuth 2.0 [I-D.ietf-oauth-v2] access token response. An example
>>     of such as response is:
>>
>>          HTTP/1.1 200 OK
>>
>>          Content-Type: application/json;charset=UTF-8
>>
>>          Cache-Control: no-store
>>
>>          Pragma: no-cache
>>
>>          {
>>
>>            "access_token":"mF_9.B5f-4.1JqM",
>>
>>            "token_type":"Bearer",
>>
>>            "expires_in":3600,
>>
>>            "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
>>
>>          }
>>
>>     Please send either +1s or objections to this text by mid-day
>>     Monday.  Unless I receive several +1s, to be conservative at this
>>     point, I will not be including it in Monday’s draft.
>>
>>                                                                 -- Mike
>>
>>     *From:*oauth-bounces@ietf.org 
>>     [mailto:oauth-bounces@ietf.org ]
>>     *On Behalf Of *Paul Madsen
>>     *Sent:* Wednesday, March 07, 2012 1:34 PM
>>     *To:* Brian Campbell
>>     *Cc:* oauth
>>     *Subject:* Re: [OAUTH-WG] question about the b64token syntax in
>>     draft-ietf-oauth-v2-bearer
>>
>>     +1
>>
>>     On 3/7/12 4:08 PM, Brian Campbell wrote:
>>
>>     Yeah, it is case insensitive. I just went with the upper case B
>>     because that's how it was written in §5.1.1 of
>>     draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually
>>     defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.
>>     Either one would be fine.
>>       
>>     I agree that an example response from the token endpoint would be
>>     worthwhile.  Something like the following might help tie together with
>>     the Authorization header example (proposed earlier). It could maybe be
>>     worked in near the top of §2?
>>       
>>           HTTP/1.1 200 OK
>>           Content-Type: application/json;charset=UTF-8
>>           Cache-Control: no-store
>>           Pragma: no-cache
>>       
>>           {
>>             "access_token":"vF_9.5dCf-t4.qbcmT_k1b",
>>             "token_type":"example",
>>             "expires_in":3600,
>>             "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA",
>>           }
>>       
>>     It'd probably make sense to change the examples in the body §2.2***
>>     and query §2.3**** to use the same access token value too.
>>       
>>       
>>     *http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1
>>     **http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1
>>     ***http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2
>>     ****http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3
>>       
>>       
>>     On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer    wrote:
>>
>>         Makes sense to me, except that I think the token_type value is typically
>>
>>         lowercase "bearer", though it's defined to be case insensitive in
>>
>>         Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value of
>>
>>         this field for the Bearer token type ever got defined anywhere. Section 7.1
>>
>>         references the bearer spec as defining the value of the "token_type"
>>
>>         parameter, and passes its example as if by reference. Would be worthwhile
>>
>>         giving an example of a token endpoint response, such as what's found in
>>
>>         OAuth-v2-23 section 5.1.
>>
>>           
>>
>>           -- Justin
>>
>>           
>>
>>           
>>
>>         On 03/07/2012 12:16 PM, Brian Campbell wrote:
>>
>>               
>>
>>             I'd like to propose the following changes and additions, derived
>>
>>             largely from Bill and James suggestions, to
>>
>>             draft-ietf-oauth-v2-bearer-17.  These changes have no normative impact
>>
>>             and only aim to add additional clarity and explanation the workings
>>
>>             and implications of the current spec.  I'm definitely open to changes
>>
>>             or improvements in the wording here (not my strong suit by any means)
>>
>>             but I think it's important that these general ideas be conveyed in the
>>
>>             draft.
>>
>>               
>>
>>               
>>
>>             ==>    Insert the following text at the beginning of §2:
>>
>>               
>>
>>             To make a protected resource request, the client must be in possession
>>
>>             of a valid bearer token. Typically a bearer token is returned to the
>>
>>             client as part of an access token response as defined in OAuth 2.0
>>
>>             [I-D.ietf-oauth-v2]. When the "token_type" parameter of the access
>>
>>             token response is "Bearer", the string value of the "access_token"
>>
>>             parameter becomes the bearer access token used to make protected
>>
>>             resource requests.
>>
>>               
>>
>>             ==>    Change the value of the token in the Authorization header example to
>>
>>             this:
>>
>>               
>>
>>             Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b
>>
>>               
>>
>>             ==>    Insert the following text before the last paragraph of §2.1:
>>
>>               
>>
>>             Note that the name b64token does not imply base64 encoding but rather
>>
>>             is the name for an ABNF syntax definition from HTTP/1.1, Part 7
>>
>>             [I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"
>>
>>             string value from an access token response MUST match the b64token
>>
>>             ABNF so it can be used with the Bearer HTTP scheme.
>>
>>               
>>
>>               
>>
>>             Thanks,
>>
>>             Brian
>>
>>               
>>
>>               
>>
>>               
>>
>>               
>>
>>             On Tue, Mar 6, 2012 at 11:45 AM, William Mills  
>>
>>               wrote:
>>
>>                   
>>
>>                 Yeah, something as simple as, "Note that the name 'b64token' does not
>>
>>                 imply
>>
>>                 base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would
>>
>>                 do
>>
>>                 it.
>>
>>                   
>>
>>                 -bill
>>
>>                   
>>
>>                 ________________________________
>>
>>                 From: Brian Campbell  
>>
>>                 To: Mike Jones  
>>
>>                 Cc: oauth  
>>
>>                 Sent: Tuesday, March 6, 2012 8:23 AM
>>
>>                   
>>
>>                 Subject: Re: [OAUTH-WG] question about the b64token syntax in
>>
>>                 draft-ietf-oauth-v2-bearer
>>
>>                   
>>
>>                 Thanks Mike, I think changing the example would be helpful.
>>
>>                   
>>
>>                 However I think that including some text along the lines of what James
>>
>>                 suggested would also be very valuable. I agree that the connection
>>
>>                 between OAuth and Bearer could and should be made more explicit. And
>>
>>                 that the implications of the b64token syntax, particularly on what AS
>>
>>                 can use to construct ATs, could/should be made more clear.
>>
>>                   
>>
>>                 I can propose some specific text (building on James') if others in the WG
>>
>>                 agree?
>>
>>                   
>>
>>                   
>>
>>                 On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones  
>>
>>                 wrote:
>>
>>                       
>>
>>                     I'm fine with changing the example to make it clearer that b64token
>>
>>                     allows
>>
>>                     a wider range of characters than just those legal for base64 and
>>
>>                     base64url
>>
>>                     encodings of data values.
>>
>>                       
>>
>>                     I'll add it to my to-do list for any additional edits for the Bearer
>>
>>                     spec.
>>
>>                       
>>
>>                                                     -- Mike
>>
>>                       
>>
>>                     -----Original Message-----
>>
>>                     From:mailto:oauth-bounces@ietf.org] On Behalf
>>
>>                     Of
>>
>>                     Manger, James H
>>
>>                     Sent: Monday, March 05, 2012 3:33 PM
>>
>>                     To: Brian Campbell; oauth
>>
>>                     Subject: Re: [OAUTH-WG] question about the b64token syntax in
>>
>>                     draft-ietf-oauth-v2-bearer
>>
>>                       
>>
>>                     Brian,
>>
>>                       
>>
>>                         On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
>>
>>                         Tokens"* I've encountered several people (including myself) who have
>>
>>                         made the assumption that the name b64token implies that some kind of
>>
>>                         base64 encoding/decoding on the access token is taking place between
>>
>>                         the client and RS.
>>
>>                           
>>
>>                         Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,
>>
>>                         however, I see that b64token is just an ABNF syntax definition
>>
>>                         allowing for characters typically used in base64, base64url, etc.. So
>>
>>                         the b64token doesn't define any encoding or decoding but rather just
>>
>>                         defines what characters can be used in the part of the Authorization
>>
>>                         header that will contain the access token.
>>
>>                           
>>
>>                         Do I read this correctly?
>>
>>                       
>>
>>                     Yes.
>>
>>                       
>>
>>                         If so, I feel like some additional clarifying text in the Bearer
>>
>>                         Tokens draft might help avoid what is (based on my small sample) a
>>
>>                         common point of misunderstanding.
>>
>>                       
>>
>>                     Changing the example bearer token should be a simple way to avoid some
>>
>>                     confusion by showing that it does not have to be base64 encoding. How
>>
>>                     about
>>
>>                     changing:
>>
>>                       Authorization: Bearer vF9dft4qmT
>>
>>                     to
>>
>>                       Authorization: Bearer vF9.dft4.qmT
>>
>>                       
>>
>>                     The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't
>>
>>                     quite manage to be precise about how OAuth and Bearer connect. It could
>>
>>                     explicitly state that the string value of the "access_token" member of
>>
>>                     an
>>
>>                     access token response is the bearer token. The "access_token" string
>>
>>                     value
>>
>>                     (after unescaping any JSON-escapes) MUST match the b64token ABNF so it
>>
>>                     can
>>
>>                     be used with the Bearer HTTP scheme. Such text could be put in §5.1.1
>>
>>                     where
>>
>>                     the "Bearer" OAuth access token type is defined.
>>
>>                       
>>
>>                       
>>
>>                         Also, does the use of b64token implicitly limit the allowed characters
>>
>>                         that an AS can use to construct a bearer access token?
>>
>>                       
>>
>>                     Yes.
>>
>>                       
>>
>>                       
>>
>>                         *http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1
>>
>>                         **
>>
>>                         http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1
>>
>>                       
>>
>>                     --
>>
>>                     James Manger
>>
>>                     _______________________________________________
>>
>>                     OAuth mailing list
>>
>>                     OAuth@ietf.org  
>>
>>                     https://www.ietf.org/mailman/listinfo/oauth
>>
>>                       
>>
>>                       
>>
>>                 _______________________________________________
>>
>>                 OAuth mailing list
>>
>>                 OAuth@ietf.org  
>>
>>                 https://www.ietf.org/mailman/listinfo/oauth
>>
>>                   
>>
>>                   
>>
>>             _______________________________________________
>>
>>             OAuth mailing list
>>
>>             OAuth@ietf.org  
>>
>>             https://www.ietf.org/mailman/listinfo/oauth
>>
>>           
>>
>>           
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org  
>>     https://www.ietf.org/mailman/listinfo/oauth
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          Home: gffletch@aol.com
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch


--------------090900070108010405010804
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    +1

    

    On 3/11/12 12:45 PM, Richer, Justin P. wrote:
    

      
      
      
+1

        

          

          
From:
              oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf
              of Brian Campbell [bcampbell@pingidentity.com]

              Sent: Sunday, March 11, 2012 9:50 AM

              To: John Bradley

              Cc: oauth

              Subject: Re: [OAUTH-WG] question about the b64token
              syntax in draft-ietf-oauth-v2-bearer

            

          

          

            
+1

            
On Mar 11, 2012 7:08 AM, "John
              Bradley" <ve7jtb@ve7jtb.com>
              wrote:

              

                

                  
+1

                    

                    Sent from my iPhone

                  


                    On 2012-03-10, at 12:49 PM, Mike Jones <Michael.Jones@microsoft.com>
                    wrote:

                    

                  

                  

                    

                      

                        
I plan to make the
                            change to the example access token value to
                          mF_9.B5f-4.1JqM before Monday’s
                            submission deadline, per the requests for
                            b64token syntax clarification.  I’m also
                            considering adding an access token response
                            example, pre the requests in this thread.  I
                            would propose adding the following new text
                            for this in a new Section 4 (before the
                            current Security Considerations).  This is
                            largely parallel to what is done in Section
                            5.1 of the MAC spec.

                        
 

                        
4.  Example Access Token
                              Response

                        
 

                        
Typically
                            a bearer token is returned to the client as
                            part of an OAuth 2.0 [I-D.ietf-oauth-v2]
                            access token response. An example of such as
                            response is:

                        
 

                        
     HTTP/1.1 200 OK

                        
     Content-Type:
                            application/json;charset=UTF-8

                        
     Cache-Control: no-store

                        
     Pragma: no-cache

                        
 

                        
     {

                        
      
                            "access_token":"mF_9.B5f-4.1JqM",

                        
       "token_type":"Bearer",

                        
       "expires_in":3600,

                        
      
                            "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"

                        
     }

                        
 

                        
Please send either
                            +1s or objections to this text by mid-day
                            Monday.  Unless I receive several +1s, to be
                            conservative at this point, I will not be
                            including it in Monday’s draft.

                        
 

                        
                                                           
                            -- Mike

                        
 

                        

                          

                            
From:
                                oauth-bounces@ietf.org
                                [mailto:oauth-bounces@ietf.org]
                                On Behalf Of Paul Madsen

                                Sent: Wednesday, March 07, 2012
                                1:34 PM

                                To: Brian Campbell

                                Cc: oauth

                                Subject: Re: [OAUTH-WG] question
                                about the b64token syntax in
                                draft-ietf-oauth-v2-bearer

                          

                        

                        
 

                        
+1

                          

                          On 3/7/12 4:08 PM, Brian Campbell wrote: 

                        
Yeah, it is case insensitive. I just went with the upper case B

                        
because that's how it was written in §5.1.1 of

                        
draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually

                        
defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.

                        
Either one would be fine.

                        
 

                        
I agree that an example response from the token endpoint would be

                        
worthwhile.  Something like the following might help tie together with

                        
the Authorization header example (proposed earlier). It could maybe be

                        
worked in near the top of §2?

                        
 

                        
     HTTP/1.1 200 OK

                        
     Content-Type: application/json;charset=UTF-8

                        
     Cache-Control: no-store

                        
     Pragma: no-cache

                        
 

                        
     {

                        
       "access_token":"vF_9.5dCf-t4.qbcmT_k1b",

                        
       "token_type":"example",

                        
       "expires_in":3600,

                        
       "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA",

                        
     }

                        
 

                        
It'd probably make sense to change the examples in the body §2.2***

                        
and query §2.3**** to use the same access token value too.

                        
 

                        
 

                        
* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1

                        
** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1

                        
*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2

                        
**** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3

                        
 

                        
 

                        
On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer <jricher@mitre.org> wrote:

                        

                          
Makes sense to me, except that I think the token_type value is typically

                          
lowercase "bearer", though it's defined to be case insensitive in

                          
Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value of

                          
this field for the Bearer token type ever got defined anywhere. Section 7.1

                          
references the bearer spec as defining the value of the "token_type"

                          
parameter, and passes its example as if by reference. Would be worthwhile

                          
giving an example of a token endpoint response, such as what's found in

                          
OAuth-v2-23 section 5.1.

                          
 

                          
 -- Justin

                          
 

                          
 

                          
On 03/07/2012 12:16 PM, Brian Campbell wrote:

                          

                            
 

                            
I'd like to propose the following changes and additions, derived

                            
largely from Bill and James suggestions, to

                            
draft-ietf-oauth-v2-bearer-17.  These changes have no normative impact

                            
and only aim to add additional clarity and explanation the workings

                            
and implications of the current spec.  I'm definitely open to changes

                            
or improvements in the wording here (not my strong suit by any means)

                            
but I think it's important that these general ideas be conveyed in the

                            
draft.

                            
 

                            
 

                            
==>  Insert the following text at the beginning of §2:

                            
 

                            
To make a protected resource request, the client must be in possession

                            
of a valid bearer token. Typically a bearer token is returned to the

                            
client as part of an access token response as defined in OAuth 2.0

                            
[I-D.ietf-oauth-v2]. When the "token_type" parameter of the access

                            
token response is "Bearer", the string value of the "access_token"

                            
parameter becomes the bearer access token used to make protected

                            
resource requests.

                            
 

                            
==>  Change the value of the token in the Authorization header example to

                            
this:

                            
 

                            
Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b

                            
 

                            
==>  Insert the following text before the last paragraph of §2.1:

                            
 

                            
Note that the name b64token does not imply base64 encoding but rather

                            
is the name for an ABNF syntax definition from HTTP/1.1, Part 7

                            
[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"

                            
string value from an access token response MUST match the b64token

                            
ABNF so it can be used with the Bearer HTTP scheme.

                            
 

                            
 

                            
Thanks,

                            
Brian

                            
 

                            
 

                            
 

                            
 

                            
On Tue, Mar 6, 2012 at 11:45 AM, William Mills<wmills@yahoo-inc.com>

                            
 wrote:

                            

                              
 

                              
Yeah, something as simple as, "Note that the name 'b64token' does not

                              
imply

                              
base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would

                              
do

                              
it.

                              
 

                              
-bill

                              
 

                              
________________________________

                              
From: Brian Campbell<bcampbell@pingidentity.com>

                              
To: Mike Jones<Michael.Jones@microsoft.com>

                              
Cc: oauth<oauth@ietf.org>

                              
Sent: Tuesday, March 6, 2012 8:23 AM

                              
 

                              
Subject: Re: [OAUTH-WG] question about the b64token syntax in

                              
draft-ietf-oauth-v2-bearer

                              
 

                              
Thanks Mike, I think changing the example would be helpful.

                              
 

                              
However I think that including some text along the lines of what James

                              
suggested would also be very valuable. I agree that the connection

                              
between OAuth and Bearer could and should be made more explicit. And

                              
that the implications of the b64token syntax, particularly on what AS

                              
can use to construct ATs, could/should be made more clear.

                              
 

                              
I can propose some specific text (building on James') if others in the WG

                              
agree?

                              
 

                              
 

                              
On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones<Michael.Jones@microsoft.com>

                              
wrote:

                              

                                
 

                                
I'm fine with changing the example to make it clearer that b64token

                                
allows

                                
a wider range of characters than just those legal for base64 and

                                
base64url

                                
encodings of data values.

                                
 

                                
I'll add it to my to-do list for any additional edits for the Bearer

                                
spec.

                                
 

                                
                               -- Mike

                                
 

                                
-----Original Message-----

                                
From: mailto:oauth-bounces@ietf.org] On Behalf

                                
Of

                                
Manger, James H

                                
Sent: Monday, March 05, 2012 3:33 PM

                                
To: Brian Campbell; oauth

                                
Subject: Re: [OAUTH-WG] question about the b64token syntax in

                                
draft-ietf-oauth-v2-bearer

                                
 

                                
Brian,

                                
 

                                

                                  
On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer

                                  
Tokens"* I've encountered several people (including myself) who have

                                  
made the assumption that the name b64token implies that some kind of

                                  
base64 encoding/decoding on the access token is taking place between

                                  
the client and RS.

                                  
 

                                  
Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,

                                  
however, I see that b64token is just an ABNF syntax definition

                                  
allowing for characters typically used in base64, base64url, etc.. So

                                  
the b64token doesn't define any encoding or decoding but rather just

                                  
defines what characters can be used in the part of the Authorization

                                  
header that will contain the access token.

                                  
 

                                  
Do I read this correctly?

                                

                                
 

                                
Yes.

                                
 

                                

                                  
If so, I feel like some additional clarifying text in the Bearer

                                  
Tokens draft might help avoid what is (based on my small sample) a

                                  
common point of misunderstanding.

                                

                                
 

                                
Changing the example bearer token should be a simple way to avoid some

                                
confusion by showing that it does not have to be base64 encoding. How

                                
about

                                
changing:

                                
 Authorization: Bearer vF9dft4qmT

                                
to

                                
 Authorization: Bearer vF9.dft4.qmT

                                
 

                                
The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't

                                
quite manage to be precise about how OAuth and Bearer connect. It could

                                
explicitly state that the string value of the "access_token" member of

                                
an

                                
access token response is the bearer token. The "access_token" string

                                
value

                                
(after unescaping any JSON-escapes) MUST match the b64token ABNF so it

                                
can

                                
be used with the Bearer HTTP scheme. Such text could be put in §5.1.1

                                
where

                                
the "Bearer" OAuth access token type is defined.

                                
 

                                
 

                                

                                  
Also, does the use of b64token implicitly limit the allowed characters

                                  
that an AS can use to construct a bearer access token?

                                

                                
 

                                
Yes.

                                
 

                                
 

                                

                                  
* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1

                                  
**

                                  
http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1

                                

                                
 

                                
--

                                
James Manger

                                
_______________________________________________

                                
OAuth mailing list

                                
OAuth@ietf.org

                                
https://www.ietf.org/mailman/listinfo/oauth

                                
 

                                
 

                              

                              
_______________________________________________

                              
OAuth mailing list

                              
OAuth@ietf.org

                              
https://www.ietf.org/mailman/listinfo/oauth

                              
 

                              
 

                            

                            
_______________________________________________

                            
OAuth mailing list

                            
OAuth@ietf.org

                            
https://www.ietf.org/mailman/listinfo/oauth

                          

                          
 

                          
 

                        

                        
_______________________________________________

                        
OAuth mailing list

                        
OAuth@ietf.org

                        
https://www.ietf.org/mailman/listinfo/oauth

                      

                    

                  

                  

                    
_______________________________________________

                      OAuth mailing list

                      OAuth@ietf.org

                      https://www.ietf.org/mailman/listinfo/oauth

                    

                  

                

              

            

          

        

      

      

      

      

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


    

    

    
-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          Home: gffletch@aol.com
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch


  


--------------090900070108010405010804--

From stein.desmet@lin-k.net  Mon Mar 12 08:16:20 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F9F21F87E5 for ; Mon, 12 Mar 2012 08:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.764
X-Spam-Level: 
X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=0.835,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fO7HwzlJDMrM for ; Mon, 12 Mar 2012 08:16:19 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBE321F873C for ; Mon, 12 Mar 2012 08:16:19 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so3089264wib.13 for ; Mon, 12 Mar 2012 08:16:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:date:subject:to:from:organization:message-id :user-agent:resent-to:mime-version:content-transfer-encoding :resent-from:resent-date:resent-message-id:x-gm-message-state; bh=Ubh0tXszMREDD89DQbgcmwfFEbNT2pIuh71w5vy4Hyk=; b=LDnlSDdXkIe2XGKtAluw9sjiukTFrkLhudBqnQ+txYLzz8YbWOlXG3osPxcjRBNQ4w nvaC6wXjD7itZvxXk/fPMn2GdEbuyx6FijgoZ/NxQiiYlEuZer7Ucr3ijiPMHDNzrpLA x0irFAF0MSS6v/pta1boSGwih5NpRJL+s6kb091gg0xUv1k8hHeO5izyu8k1BfXVulUH EkSo2yoC2pAHLxTaspngiszKh0l2XJkycxrZSbrm4J2w1afwB/8oPPn9SrHYsdUrKYGD 4bJW4eMQqf32kx4U4W8yTmw2kJL1kzhvMa0N/1TvkrkU1L/EEt9GPpW6cYqWaw45EPud t39w==
Received: by 10.180.97.41 with SMTP id dx9mr28146205wib.9.1331565378668; Mon, 12 Mar 2012 08:16:18 -0700 (PDT)
Received: from sgdesmet.lin-k.net ([80.169.61.18]) by mx.google.com with ESMTPS id k6sm11064911wie.9.2012.03.12.08.16.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Mar 2012 08:16:18 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Date: Fri, 09 Mar 2012 11:19:16 +0100
To: oauth@ietf.org
From: "Stein Desmet" 
Organization: Lin.K
Message-ID: 
User-Agent: Opera Mail/11.61 (MacIntel)
Resent-To: "oauth@ietf.org" 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Resent-From: "Stein Desmet" 
Resent-Date: Mon, 12 Mar 2012 16:16:16 +0100
Resent-Message-ID: 
X-Gm-Message-State: ALoCoQnYmLM6VeJojFj2sT3HmuI2rwHxctNmUi1LmnnK2Bcz1xMaezsgooi1nll60KSpfeHdxKPv
Subject: [OAUTH-WG] Client credentials flow vs. authorization grant flow for native clients
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 15:16:20 -0000

I have mistakingly asked this question on the google group on google's
Oauth2 implementation, so here it is at the correct place (I hope).

We have an authentication server/identity provider, and a number of
external web applications (ie resource servers) that make use of it.
We would like to build native applications (iOS/Android) that make use of
the resources on these web applications, so adding Oauht2 to
both our authentication server and our web applications to provide
authorization seems ideal.

However, there is one issue: it is possible for end-users to authenticate
themselves using smartcards or electronic ids (these users do not have
a login/password at all). Therefore, we can't use embedded user-agents, or
external user agents located on the mobile platform itself, so users
would need to use a browser on another computer. However, I'm not entirely
sure which flow is best applicable in such a case, and offers the best
security?

- The client credentials flow seems like a fit. Users would need to
register their mobile device on the authentication server first, meaning
they
     are issued a client id and secret, unique to each client instance.  
These
credentials could be transferred in a number of ways, using QR codes,
     or have the user manually input them.
- The authorization grant flow can also be used. The flow would be started
on a separate browser using a helper web client app, and at the end
     of the flow, the authorization code is transferred to the native client
by for example push notifications, QR codes or having the user manually
     input it. Client credentials in this case would be universal for the
native application.
     This seems a bit harder to implement (and care must betaken to avoid
exploitation of the web client app), but the refresh tokens could be used
     as OTP (i.e. issuing a new refresh token each time a user asks for a  
new
access token, and invalidating the previous one), allowing some detection
     of misuse.

The device flow seems applicable as well, but is no longer present in
recent Oauht2 drafts (though there is still
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00).

Best regards,
Stein Desmet

From jricher@mitre.org  Mon Mar 12 08:39:13 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2A521F8674 for ; Mon, 12 Mar 2012 08:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.584
X-Spam-Level: 
X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHlmNKnZbcfA for ; Mon, 12 Mar 2012 08:39:12 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A995C21F8469 for ; Mon, 12 Mar 2012 08:39:12 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8CB7721B0772; Mon, 12 Mar 2012 11:39:11 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7E70A21B0315; Mon, 12 Mar 2012 11:39:11 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Mon, 12 Mar 2012 11:39:11 -0400
From: "Richer, Justin P." 
To: Stein Desmet 
Thread-Topic: [OAUTH-WG] Client credentials flow vs. authorization grant flow for native clients
Thread-Index: AQHNAGMhtha/OSA9oEm2MOLRSdoPlZZnDtAA
Date: Mon, 12 Mar 2012 15:39:10 +0000
Message-ID: <9A009C12-25F1-4FB6-BE7B-F0CDAD1E7A6A@mitre.org>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.32.192]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [OAUTH-WG] Client credentials flow vs. authorization grant flow for native clients
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 15:39:13 -0000

Client credentials is not the right flow for this approach since there's a =
user present at the client and they can close the loop for you. The Device =
Flow, if it were to get picked up and fleshed out a bit, is a better fit fo=
r what you're after and is made for just such a disconnected world where yo=
u can't rely on the user logging in through a browser that's easily accessi=
ble from the client app.

Another, arguably better, approach would be to use the vanilla Authz Code f=
low, taking advantage of the fact that the code is itself a OTP. First, hav=
e the ClientID embedded in the mobile app, like normal. Since it's a config=
uration time piece of information that gets copied to every instance, you w=
ouldn't use a client secret here. (It doesn't buy you anything.) Next, dire=
ct your users to log into a server-side "help app", which is basically just=
 the Authz Server's authorization endpoint that's been seeded with the clie=
nt ID, scope, and other relevant parameters. This is easy enough to do by g=
iving your users a short URL  to go go that starts off this process automat=
ically. Next, the user goes through all the normal OAuth stuff and gets red=
irected to a pre-registered callback URL. This callback URL is hosted by yo=
ur service, not by the device itself. The page would then display the code =
so that the user could type it in, present a QRCode to scan in, do some kin=
d of backchannel trusted pass, or a few other tricks to get the code from t=
he hosted site over to the device itself. Then the device uses the code, wh=
ich you remember is a OTP that's hopefully time limited, along with its cli=
ent ID to go and grab the access tokens that it needs.

 -- Justin


On Mar 9, 2012, at 5:19 AM, Stein Desmet wrote:

> I have mistakingly asked this question on the google group on google's
> Oauth2 implementation, so here it is at the correct place (I hope).
>=20
> We have an authentication server/identity provider, and a number of
> external web applications (ie resource servers) that make use of it.
> We would like to build native applications (iOS/Android) that make use of
> the resources on these web applications, so adding Oauht2 to
> both our authentication server and our web applications to provide
> authorization seems ideal.
>=20
> However, there is one issue: it is possible for end-users to authenticate
> themselves using smartcards or electronic ids (these users do not have
> a login/password at all). Therefore, we can't use embedded user-agents, o=
r
> external user agents located on the mobile platform itself, so users
> would need to use a browser on another computer. However, I'm not entirel=
y
> sure which flow is best applicable in such a case, and offers the best
> security?
>=20
> - The client credentials flow seems like a fit. Users would need to
> register their mobile device on the authentication server first, meaning
> they
>    are issued a client id and secret, unique to each client instance. The=
se
> credentials could be transferred in a number of ways, using QR codes,
>    or have the user manually input them.
> - The authorization grant flow can also be used. The flow would be starte=
d
> on a separate browser using a helper web client app, and at the end
>    of the flow, the authorization code is transferred to the native clien=
t
> by for example push notifications, QR codes or having the user manually
>    input it. Client credentials in this case would be universal for the
> native application.
>    This seems a bit harder to implement (and care must betaken to avoid
> exploitation of the web client app), but the refresh tokens could be used
>    as OTP (i.e. issuing a new refresh token each time a user asks for a n=
ew
> access token, and invalidating the previous one), allowing some detection
>    of misuse.
>=20
> The device flow seems applicable as well, but is no longer present in
> recent Oauht2 drafts (though there is still
> http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00).
>=20
> Best regards,
> Stein Desmet
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From abilbie@lincoln.ac.uk  Mon Mar 12 08:55:33 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1AE21E804D for ; Mon, 12 Mar 2012 08:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcTDKA1J8CSU for ; Mon, 12 Mar 2012 08:55:32 -0700 (PDT)
Received: from harkonnen.lincoln.ac.uk (harkonnen.lincoln.ac.uk [195.195.10.62]) by ietfa.amsl.com (Postfix) with ESMTP id C3BF421E8040 for ; Mon, 12 Mar 2012 08:55:29 -0700 (PDT)
Received: from [194.80.56.81] (helo=email.lincoln.ac.uk) by harkonnen.lincoln.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1S77an-0000tF-Sv for oauth@ietf.org; Mon, 12 Mar 2012 15:55:27 +0000
Received: from alexs-imac.network.uni ([10.1.8.5]) by email.lincoln.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Mar 2012 15:55:25 +0000
From: Alex Bilbie 
Content-Type: multipart/alternative; boundary="Apple-Mail=_0007A8EA-A422-4EA6-892F-1D57EB46E664"
Date: Mon, 12 Mar 2012 15:55:25 +0000
Message-Id: <819174B8-CD1E-4676-960A-60FA67F4ABF9@lincoln.ac.uk>
To: oauth 
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
X-OriginalArrivalTime: 12 Mar 2012 15:55:25.0372 (UTC) FILETIME=[89E557C0:01CD0068]
X-harkonnen-AV-clam: Checked using ClamAV
X-harkonnen-AV-sophos: Checked using SophosAV
X-SA-Exim-Connect-IP: 194.80.56.81
X-SA-Exim-Mail-From: abilbie@lincoln.ac.uk
X-SA-Exim-Version: 4.2.1 (built Wed, 15 Dec 2010 16:28:39 +0000)
X-SA-Exim-Scanned: Yes (on harkonnen.lincoln.ac.uk)
Subject: [OAUTH-WG] Are there any implementations of the SAML bearer token specificiation?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 15:55:33 -0000

--Apple-Mail=_0007A8EA-A422-4EA6-892F-1D57EB46E664
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello,

Can anyone please tell me if there are any implementations of the OAuth =
2 SAML bearer tokens draft specification?

It is our intention to expand on the existing work (see =
http://lncn.eu/jsx5) we have done at the University of Lincoln and =
develop an implementation of the above specification.

If anyone is already doing some work in this area we'd love to have a =
chat with you.

Kind regards,

Alex Bilbie

Online Services Team
ICT Services
University of Lincoln

e: abilbie@lincoln.ac.uk=

--Apple-Mail=_0007A8EA-A422-4EA6-892F-1D57EB46E664
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

http://lncn.eu/jsx5) we have done at =
the University of Lincoln and develop an implementation of the above =
specification.

If anyone is already doing some =
work in this area we'd love to have a chat with =
you.

Kind =
regards,

Alex Bilbie

Online Services Team
University of Lincoln

=

--Apple-Mail=_0007A8EA-A422-4EA6-892F-1D57EB46E664--

From cmortimore@salesforce.com  Mon Mar 12 09:01:59 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8414021E8068 for ; Mon, 12 Mar 2012 09:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39ZuypBgekZU for ; Mon, 12 Mar 2012 09:01:58 -0700 (PDT)
Received: from exprod8og115.obsmtp.com (exprod8og115.obsmtp.com [64.18.3.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E221E8066 for ; Mon, 12 Mar 2012 09:01:58 -0700 (PDT)
Received: from mail-fa0-f43.google.com ([209.85.161.43]) (using TLSv1) by exprod8ob115.postini.com ([64.18.7.12]) with SMTP ID DSNKT14d9dMzYrklHFIgUXOQnKz4TpTxe1wR@postini.com; Mon, 12 Mar 2012 09:01:58 PDT
Received: by fanq24 with SMTP id q24so158156fan.2 for ; Mon, 12 Mar 2012 09:01:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=j8Ib5qcJoOnJ2zoxTRe8RZNPgRiKBNDMi+XZb+tGm7M=; b=EzRx7cT9dZHbyXWmrEeRxH5bNvFGZ3d5qWe8g1bNFtOZIHg3oIIp7Vo0aZk2v4uHJN 4MURez74TERVh2LGChFccioSZuN1GOrZxxQxV8rUMaYuI2BxOYnwcN+RI/GkIMBXfJ4P BmcZ+kFO0NPAgSab0QJA6iS3dwhOHi2oiUfEplt5BjfWNh9gN4lBWTKuH4C9cPvB4/lz RcvgB8TvOEFn8/m6ccdkNpMljOu5hWTM2vGn19oRgK4Kc/QGTUkyQmJqNT3nWVRw6kgf YwUblS2WEO+P62eOEAcIP/mQDbzzmrv8/fMBpL/f0/gKrcpVj9w3HsykKl8MMHcJGiz0 jlKQ==
MIME-Version: 1.0
Received: by 10.224.210.129 with SMTP id gk1mr8670794qab.85.1331568115761; Mon, 12 Mar 2012 09:01:55 -0700 (PDT)
Received: by 10.229.77.77 with HTTP; Mon, 12 Mar 2012 09:01:55 -0700 (PDT)
In-Reply-To: <819174B8-CD1E-4676-960A-60FA67F4ABF9@lincoln.ac.uk>
References: <819174B8-CD1E-4676-960A-60FA67F4ABF9@lincoln.ac.uk>
Date: Mon, 12 Mar 2012 09:01:55 -0700
Message-ID: 
From: Chuck Mortimore 
To: Alex Bilbie 
Content-Type: multipart/alternative; boundary=20cf300faca188c31a04bb0ddc09
X-Gm-Message-State: ALoCoQlRZcogzQ1WJzhaRuoX/vDNQXQUN/T5RksXrStTYJQpbSUs6+l9vhNoQDo/tqxLBMf0996v
Cc: oauth 
Subject: Re: [OAUTH-WG] Are there any implementations of the SAML bearer token specificiation?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 16:01:59 -0000

--20cf300faca188c31a04bb0ddc09
Content-Type: text/plain; charset=ISO-8859-1

Salesforce has an implementation of both the SAML and JWT Bearer tokens.
Happy to chat.

-cmort

On Mon, Mar 12, 2012 at 8:55 AM, Alex Bilbie  wrote:

> Hello,
>
> Can anyone please tell me if there are any implementations of the OAuth 2
> SAML bearer tokens draft specification?
>
> It is our intention to expand on the existing work (see
> http://lncn.eu/jsx5) we have done at the University of Lincoln and
> develop an implementation of the above specification.
>
> If anyone is already doing some work in this area we'd love to have a chat
> with you.
>
> Kind regards,
>
> Alex Bilbie
>
> Online Services Team
> ICT Services
> University of Lincoln
>
> e: abilbie@lincoln.ac.uk
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--20cf300faca188c31a04bb0ddc09
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Salesforce has an implementation of both the SAML and JWT Bearer tokens. =
=A0 Happy to chat.

-cmort

On Mon, Mar 12, 2012 at 8:55 AM, Alex Bilbie <abilbie@lincoln.ac.uk> w=
rote:


Hello,
Can anyone please tell me if there are any implementation=
s of the OAuth 2 SAML bearer tokens draft specification?



It is our intention to expand on the existing work (see=
 http://lncn.eu/jsx5)=
 we have done at the University of Lincoln and develop an implementation of=
 the above specification.



If anyone is already doing some work in this area we=
9;d love to have a chat with you.

Kind regards,

<=
span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;fon=
t-style:normal;font-weight:normal;line-height:normal;border-collapse:separa=
te;text-transform:none;font-size:medium;white-space:normal;font-family:Helv=
etica;word-spacing:0px">


Alex Bilbie


Online Serv=
ices Team

ICT Services
Uni=
versity of Lincoln





_____________________=
__________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--20cf300faca188c31a04bb0ddc09--

From paul.madsen@gmail.com  Mon Mar 12 09:20:27 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360E621F8735 for ; Mon, 12 Mar 2012 09:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAcgI1AKfl9K for ; Mon, 12 Mar 2012 09:20:26 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5B021F8720 for ; Mon, 12 Mar 2012 09:20:25 -0700 (PDT)
Received: by eaaq11 with SMTP id q11so1260819eaa.31 for ; Mon, 12 Mar 2012 09:20:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=D2X1c4ePeck+1WTiCUCvC1uikFZUK1GvHhUYJziuygk=; b=ET8vOkMm3gv/hJ8uWI2CBHkdm52rQ5O/lwc3DMevazVTwjnd1fSnVlXE1FiOnGk3vh TBDJTTy5z/iaLrNwI3wUH6xGnK+1XVEMbuzHEHagpwuljTXt9yokuSQzSC16ey+o40ZF eO6Uj9rHGvbxVcupgAJe3BoclswU+Xe+JWhG5a2cIt3sRo9DeKLwE14dd2hs5v2v8SAo tFIw4rMaBYVJEWPyJraJBOhB7lYpdgY/0csP7ZngaQIt+2U55hH4xJv4UhCCQX+6GlYz 9FUFn+P4eUKSDVA6R4wy60EqhAoeG6K9FpfUqQ/sY95wVsBuboyZimb8gQVXY+gIPvK6 KDxw==
Received: by 10.52.21.51 with SMTP id s19mr15141906vde.35.1331569224752; Mon, 12 Mar 2012 09:20:24 -0700 (PDT)
Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.162.33]) by mx.google.com with ESMTPS id hf9sm27138309vdb.7.2012.03.12.09.20.22 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 09:20:23 -0700 (PDT)
Message-ID: <4F5E2245.4080000@gmail.com>
Date: Mon, 12 Mar 2012 12:20:21 -0400
From: Paul Madsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Alex Bilbie 
References: <819174B8-CD1E-4676-960A-60FA67F4ABF9@lincoln.ac.uk>
In-Reply-To: <819174B8-CD1E-4676-960A-60FA67F4ABF9@lincoln.ac.uk>
Content-Type: multipart/alternative; boundary="------------020907050409040204000403"
Cc: oauth 
Subject: Re: [OAUTH-WG] Are there any implementations of the SAML bearer token specificiation?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 16:20:27 -0000

This is a multi-part message in MIME format.
--------------020907050409040204000403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ping Identity has implemented


On 3/12/12 11:55 AM, Alex Bilbie wrote:
> Hello,
>
> Can anyone please tell me if there are any implementations of the 
> OAuth 2 SAML bearer tokens draft specification?
>
> It is our intention to expand on the existing work (see 
> http://lncn.eu/jsx5) we have done at the University of Lincoln and 
> develop an implementation of the above specification.
>
> If anyone is already doing some work in this area we'd love to have a 
> chat with you.
>
> Kind regards,
>
> Alex Bilbie
>
> Online Services Team
> ICT Services
> University of Lincoln
>
> e: abilbie@lincoln.ac.uk 
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------020907050409040204000403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ping Identity has implemented

    

    

    On 3/12/12 11:55 AM, Alex Bilbie wrote:
    
Hello,
      


      

      
Can anyone please tell me if there are any implementations of
        the OAuth 2 SAML bearer tokens draft specification?

      


      

      
It is our intention to expand on the existing work (see http://lncn.eu/jsx5)
        we have done at the University of Lincoln and develop an
        implementation of the above specification.

      


      

      
If anyone is already doing some work in this area we'd love
        to have a chat with you.

      


      

      
Kind regards,

      


      

      

        

          

                

                  

                    
Alex Bilbie

                    


                    

                    
Online
                      Services Team

                    
ICT
                      Services

                    
University
                      of Lincoln

                    


                    

                    
                  

                

              

        

      

      

      

      

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


    

  


--------------020907050409040204000403--

From igor.faynberg@alcatel-lucent.com  Mon Mar 12 10:18:05 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBE021F8899 for ; Mon, 12 Mar 2012 10:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PreMJkv06LAM for ; Mon, 12 Mar 2012 10:18:04 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 669D221F888E for ; Mon, 12 Mar 2012 10:18:04 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2CHI3H2019454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Mar 2012 12:18:03 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CHI35Y014742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Mar 2012 12:18:03 -0500
Received: from [135.222.134.168] (USMUYN0L055118.mh.lucent.com [135.222.134.168]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2CHI3jv012964; Mon, 12 Mar 2012 12:18:03 -0500 (CDT)
Message-ID: <4F5E2FCA.2030300@alcatel-lucent.com>
Date: Mon, 12 Mar 2012 13:18:02 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: oauth@ietf.org
References: <819174B8-CD1E-4676-960A-60FA67F4ABF9@lincoln.ac.uk> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060603000707040901030003"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Subject: Re: [OAUTH-WG] Are there any implementations of the SAML bearer	token specificiation?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 17:18:05 -0000

This is a multi-part message in MIME format.
--------------060603000707040901030003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Please include me in the chat!

This is, in fact, something that could make a very interesting agenda 
item at a meeting.

Igor

On 3/12/2012 12:01 PM, Chuck Mortimore wrote:
> Salesforce has an implementation of both the SAML and JWT Bearer 
> tokens.   Happy to chat.
>
> -cmort
>
> On Mon, Mar 12, 2012 at 8:55 AM, Alex Bilbie  > wrote:
>
>     Hello,
>
>     Can anyone please tell me if there are any implementations of the
>     OAuth 2 SAML bearer tokens draft specification?
>
>     It is our intention to expand on the existing work (see
>     http://lncn.eu/jsx5) we have done at the University of Lincoln and
>     develop an implementation of the above specification.
>
>     If anyone is already doing some work in this area we'd love to
>     have a chat with you.
>
>     Kind regards,
>
>     Alex Bilbie
>
>     Online Services Team
>     ICT Services
>     University of Lincoln
>
>     e: abilbie@lincoln.ac.uk 
>
>     _______________________________________________
>     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

--------------060603000707040901030003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Please include me in the chat!   

    

    This is, in fact, something that could make a very interesting
    agenda item at a meeting.

    

    Igor

    

    On 3/12/2012 12:01 PM, Chuck Mortimore wrote:
    
Salesforce has an implementation of both the SAML and
      JWT Bearer tokens.   Happy to chat.
      


      

      
-cmort

        

        
On Mon, Mar 12, 2012 at 8:55 AM, Alex
          Bilbie <abilbie@lincoln.ac.uk>
          wrote:

          

            
Hello,
              


              

              
Can anyone please tell me if there are any
                implementations of the OAuth 2 SAML bearer tokens draft
                specification?

              


              

              
It is our intention to expand on the existing work
                (see http://lncn.eu/jsx5)
                we have done at the University of Lincoln and develop an
                implementation of the above specification.

              


              

              
If anyone is already doing some work in this area
                we'd love to have a chat with you.

              


              

              
Kind regards,

              


              

              

                

                  

                        

                          

                            
Alex Bilbie

                            

                              

                            

                            
Online Services Team

                            

                              ICT Services

                            
University of Lincoln

                            

                              

                            

                            
                          

                        

                      

                

              

            

            

            _______________________________________________

            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


    

  


--------------060603000707040901030003--

From internet-drafts@ietf.org  Mon Mar 12 10:43:50 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4CB21F893A; Mon, 12 Mar 2012 10:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlyhmagw1GmX; Mon, 12 Mar 2012 10:43:50 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6F921F8910; Mon, 12 Mar 2012 10:43:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120312174344.19406.49330.idtracker@ietfa.amsl.com>
Date: Mon, 12 Mar 2012 10:43:44 -0700
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-18.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 17:43:51 -0000

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

	Title           : The OAuth 2.0 Authorization Protocol: Bearer Tokens
	Author(s)       : Michael B. Jones
                          Dick Hardt
                          David Recordon
	Filename        : draft-ietf-oauth-v2-bearer-18.txt
	Pages           : 23
	Date            : 2012-03-12

   This specification describes how to use bearer tokens in HTTP
   requests to access OAuth 2.0 protected resources.  Any party in
   possession of a bearer token (a "bearer") can use it to get access to
   the associated resources (without demonstrating possession of a
   cryptographic key).  To prevent misuse, bearer tokens need to be
   protected from disclosure in storage and in transport.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-18.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-18.txt


From Michael.Jones@microsoft.com  Mon Mar 12 10:50:21 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A52521F89CC for ; Mon, 12 Mar 2012 10:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.782
X-Spam-Level: 
X-Spam-Status: No, score=-3.782 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afPFPg3zYs87 for ; Mon, 12 Mar 2012 10:50:20 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5FD21F8967 for ; Mon, 12 Mar 2012 10:50:20 -0700 (PDT)
Received: from mail60-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Mon, 12 Mar 2012 17:50:19 +0000
Received: from mail60-va3 (localhost [127.0.0.1])	by mail60-va3-R.bigfish.com (Postfix) with ESMTP id 297F460320	for ; Mon, 12 Mar 2012 17:50:19 +0000 (UTC)
X-SpamScore: -19
X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail60-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail60-va3 (localhost.localdomain [127.0.0.1]) by mail60-va3 (MessageSwitch) id 1331574615883786_8652; Mon, 12 Mar 2012 17:50:15 +0000 (UTC)
Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.253])	by mail60-va3.bigfish.com (Postfix) with ESMTP id D22D83A0047	for ; Mon, 12 Mar 2012 17:50:15 +0000 (UTC)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 12 Mar 2012 17:50:14 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0283.004; Mon, 12 Mar 2012 17:50:00 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: OAuth 2.0 Bearer Token Specification Draft -18
Thread-Index: Ac0AeIt64uboncVYT3CqRsd3gSwfpw==
Date: Mon, 12 Mar 2012 17:50:00 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943664143F9@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.78]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943664143F9TK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -18
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 17:50:21 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943664143F9TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Draft 18 of the OAuth 2.0 Bearer Token Specification has been published.  It contains the follo=
wing changes:

  *   Changed example bearer token value from vF9dft4qmT to mF_9.B5f-4.1JqM=
.
  *   Added example access token response returning a Bearer token.

The draft is available at:

*         http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-18
A HTML-formatted version is available at:

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-18.html

                                                                -- Mike


--_000_4E1F6AAD24975D4BA5B1680429673943664143F9TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Draft 18 of the 
OAuth 2.0 Bearer Token Specification has been published.  It conta=
ins the following changes:


    

  • 
Changed example bearer token value from vF9dft4qmT=
 to mF_9.B5f-4.1JqM.

  • 
Added example access token response returning a Be=
arer token.



 


The draft is available at:


·        
http://tools.ietf.org/html/draft-ietf-oauth-v2-bea=
rer-18


A HTML-formatted version is available at:=



·        
http://self-issued.info/docs/draft-ietf-oau=
th-v2-bearer-18.html


 


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


 






--_000_4E1F6AAD24975D4BA5B1680429673943664143F9TK5EX14MBXC284r_--

From sweeden@au1.ibm.com  Mon Mar 12 15:37:00 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2832121E815E for ; Mon, 12 Mar 2012 15:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.768
X-Spam-Level: 
X-Spam-Status: No, score=-5.768 tagged_above=-999 required=5 tests=[AWL=-1.469, BAYES_00=-2.599, MANGLED_LINKS=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id io1+d5wY3nBY for ; Mon, 12 Mar 2012 15:36:59 -0700 (PDT)
Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by ietfa.amsl.com (Postfix) with ESMTP id C36B721E815D for ; Mon, 12 Mar 2012 15:36:58 -0700 (PDT)
Received: from /spool/local by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Mon, 12 Mar 2012 22:28:43 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245) by e23smtp03.au.ibm.com (202.81.31.209) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Mon, 12 Mar 2012 22:28:39 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2CMakIq1396934; Tue, 13 Mar 2012 09:36:46 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2CMakDu023916; Tue, 13 Mar 2012 09:36:46 +1100
Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2CMaklJ023913; Tue, 13 Mar 2012 09:36:46 +1100
In-Reply-To: 
References: 
X-KeepSent: 113F0337:C49C785D-4A2579BF:007B00A1; type=4; name=$KeepSent
To: "Stein Desmet" 
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: 
From: Shane B Weeden 
Date: Tue, 13 Mar 2012 08:28:09 +1000
X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.2FP1HF437 | June 7, 2011) at 13/03/2012 09:40:54
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
x-cbid: 12031212-6102-0000-0000-00000106ACA0
Cc: oauth@ietf.org, oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Client credentials flow vs. authorization grant flow for native clients
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 22:37:00 -0000

You're on the right track.
If you're interested, I have a demo of exactly what you are talking about
using the authorization code flow (and in this case manual entry of the
short-lived azn code). It uses refresh tokens precisely just as you
suggest:

https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_oauth_application_demonstration
https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_demonstration_under_the_hood

You'll see that a client secret is not required at all as native mobile
clients are really public.

My server is currently offline, but I'll be bringing it back up again in
the next couple of days then you can try it our directly.



From:	"Stein Desmet" 
To:	oauth@ietf.org
Date:	13/03/2012 01:20 AM
Subject:	[OAUTH-WG] Client credentials flow vs. authorization grant flow
            for native clients
Sent by:	oauth-bounces@ietf.org



I have mistakingly asked this question on the google group on google's
Oauth2 implementation, so here it is at the correct place (I hope).

We have an authentication server/identity provider, and a number of
external web applications (ie resource servers) that make use of it.
We would like to build native applications (iOS/Android) that make use of
the resources on these web applications, so adding Oauht2 to
both our authentication server and our web applications to provide
authorization seems ideal.

However, there is one issue: it is possible for end-users to authenticate
themselves using smartcards or electronic ids (these users do not have
a login/password at all). Therefore, we can't use embedded user-agents, or
external user agents located on the mobile platform itself, so users
would need to use a browser on another computer. However, I'm not entirely
sure which flow is best applicable in such a case, and offers the best
security?

- The client credentials flow seems like a fit. Users would need to
register their mobile device on the authentication server first, meaning
they
     are issued a client id and secret, unique to each client instance.
These
credentials could be transferred in a number of ways, using QR codes,
     or have the user manually input them.
- The authorization grant flow can also be used. The flow would be started
on a separate browser using a helper web client app, and at the end
     of the flow, the authorization code is transferred to the native
client
by for example push notifications, QR codes or having the user manually
     input it. Client credentials in this case would be universal for the
native application.
     This seems a bit harder to implement (and care must betaken to avoid
exploitation of the web client app), but the refresh tokens could be used
     as OTP (i.e. issuing a new refresh token each time a user asks for a
new
access token, and invalidating the previous one), allowing some detection
     of misuse.

The device flow seems applicable as well, but is no longer present in
recent Oauht2 drafts (though there is still
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00).

Best regards,
Stein Desmet
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




From Michael.Jones@microsoft.com  Mon Mar 12 17:39:02 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954C221E8073 for ; Mon, 12 Mar 2012 17:39:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.304
X-Spam-Level: 
X-Spam-Status: No, score=-5.304 tagged_above=-999 required=5 tests=[AWL=1.294,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+tual6QppDP for ; Mon, 12 Mar 2012 17:39:00 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9B38721E8011 for ; Mon, 12 Mar 2012 17:39:00 -0700 (PDT)
Received: from mail134-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 13 Mar 2012 00:39:00 +0000
Received: from mail134-tx2 (localhost [127.0.0.1])	by mail134-tx2-R.bigfish.com (Postfix) with ESMTP id 432D0200442	for ; Tue, 13 Mar 2012 00:39:00 +0000 (UTC)
X-SpamScore: -20
X-BigFish: VS-20(zz9371Ic85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail134-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail134-tx2 (localhost.localdomain [127.0.0.1]) by mail134-tx2 (MessageSwitch) id 133159913891660_5803; Tue, 13 Mar 2012 00:38:58 +0000 (UTC)
Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.241])	by mail134-tx2.bigfish.com (Postfix) with ESMTP id 0743B3400AC	for ; Tue, 13 Mar 2012 00:38:58 +0000 (UTC)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 13 Mar 2012 00:38:57 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0283.004; Tue, 13 Mar 2012 00:38:56 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: Draft -01 of JSON Crypto Specs: JWS, JWE, JWK, JWA, JWS-JS, JWE-JS
Thread-Index: Ac0AsXe8nVQEXhi3RWWAlZ3h4dYRKAAABurg
Date: Tue, 13 Mar 2012 00:38:55 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366416F5A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.79]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366416F5ATK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: [OAUTH-WG] FW: Draft -01 of JSON Crypto Specs: JWS, JWE, JWK, JWA, JWS-JS, JWE-JS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Mar 2012 00:39:02 -0000

--_000_4E1F6AAD24975D4BA5B168042967394366416F5ATK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



From: Mike Jones
Sent: Monday, March 12, 2012 5:37 PM
To: jose@ietf.org
Subject: Draft -01 of JSON Crypto Specs: JWS, JWE, JWK, JWA, JWS-JS, JWE-JS

New versions of the JSON Object Signing and Encryption (JOSE) specifications are now available that incorporate =
working group feedback since publication of the initial versions.  They are=
:

*         JSON Web Signature (JWS) - Digital signature/HMAC specification

*         JSON Web Encryption (JWE) - Encryption specification

*         JSON Web Key (JWK) - Public key specification

*         JSON Web Algorithms (JWA) - Algorithms and identifiers specificat=
ion

The most important changes are:

*         Added a separate integrity check for encryption algorithms withou=
t an integral integrity check.

*         Defined header parameters for including JWK public keys and X.509=
 certificate chains directly in the header.
See the Document History section in each specification for a more detailed =
list of changes.

Corresponding versions of the JSON Serialization specs, which use these JOS=
E drafts, are also available.  Besides using JSON Serializations of the cry=
ptographic results (rather than Compact Serializations using a series of ba=
se64url encoded values), these specifications also enable multiple digital =
signatures and/or HMACs to applied to the same message and enable the same =
plaintext to be encrypted to multiple recipients.  They are:

*         JSON Web Signature JSON Serialization (JWS-JS)

*         JSON Web Encryption JSON Serialization (JWE-JS)

These specifications are available at:

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-01

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-key-01

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01

*         http://tools.ietf.org/html/draft-jones-json-web-signature-json-se=
rialization-01

*         http://tools.ietf.org/html/draft-jones-json-web-encryption-json-s=
erialization-01

HTML formatted versions are available at:

*         http://self-issued.info/docs/draft-ietf-jose-json-web-signature-0=
1.html

*         http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-=
01.html

*         http://self-issued.info/docs/draft-ietf-jose-json-web-key-01.html

*         http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-=
01.html

*         http://self-issued.info/docs/draft-jones-json-web-signature-json-=
serialization-01.html

*         http://self-issued.info/docs/draft-jones-json-web-encryption-json=
-serialization-01.html

                                                                -- Mike


--_000_4E1F6AAD24975D4BA5B168042967394366416F5ATK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 


 






From: Mike Jon=
es


Sent: Monday, March 12, 2012 5:37 PM

To: jose@ietf.org

Subject: Draft -01 of JSON Crypto Specs: JWS, JWE, JWK, JWA, JWS-JS,=
 JWE-JS






 


New versions of the 
JSON Object Signing and Encryption (JOSE) specifications are now availa=
ble that incorporate working group feedback since publication of the initia=
l versions.  They are:


·        
JSON Web Signature (JWS) – Digital sig=
nature/HMAC specification


·        
JSON Web Encryption (JWE) – Encryption=
 specification


·        
JSON Web Key (JWK) – Public key specif=
ication


·        
JSON Web Algorithms (JWA) – Algorithms=
 and identifiers specification


 


The most important changes are:


·        
Added a separate integrity check for encrypt=
ion algorithms without an integral integrity check.


·        
Defined header parameters for including JWK =
public keys and X.509 certificate chains directly in the header.=



See the Document History section in each specificati=
on for a more detailed list of changes.


 


Corresponding versions of the JSON Serialization spe=
cs, which use these JOSE drafts, are also available.  Besides using JS=
ON Serializations of the cryptographic results (rather than Compact Seriali=
zations using a series of base64url encoded
 values), these specifications also enable multiple digital signatures and/=
or HMACs to applied to the same message and enable the same plaintext to be=
 encrypted to multiple recipients.  They are:


·        
JSON Web Signature JSON Serialization (JWS-J=
S)


·        
JSON Web Encryption JSON Serialization (JWE-=
JS)


 


These specifications are available at:

·        
http://tools.ietf.org/html/draft-ietf-jose=
-json-web-signature-01


·        
http://tools.ietf.org/html/draft-ietf-jos=
e-json-web-encryption-01


·        
http://tools.ietf.org/html/draft-ietf-jose-json-=
web-key-01


·        
http://tools.ietf.org/html/draft-ietf-jos=
e-json-web-algorithms-01


·        
http://tools.ietf.org/html/=
draft-jones-json-web-signature-json-serialization-01


·        
http://tools.ietf.org/html=
/draft-jones-json-web-encryption-json-serialization-01


 


HTML formatted versions are available at:=



·        
http://self-issued.info/docs/draft-=
ietf-jose-json-web-signature-01.html


·        
http://self-issued.info/docs/draft=
-ietf-jose-json-web-encryption-01.html


·        
http://self-issued.info/docs/draft-ietf-j=
ose-json-web-key-01.html


·        
http://self-issued.info/docs/draft=
-ietf-jose-json-web-algorithms-01.html


·        
http://self-issued.i=
nfo/docs/draft-jones-json-web-signature-json-serialization-01.html=



·        
http://self-issued.=
info/docs/draft-jones-json-web-encryption-json-serialization-01.html


 


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


 






--_000_4E1F6AAD24975D4BA5B168042967394366416F5ATK5EX14MBXC284r_--

From Michael.Jones@microsoft.com  Mon Mar 12 18:07:29 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689A011E8083 for ; Mon, 12 Mar 2012 18:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.829
X-Spam-Level: 
X-Spam-Status: No, score=-3.829 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntTMgTIb6-pK for ; Mon, 12 Mar 2012 18:07:28 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 50D0D11E8079 for ; Mon, 12 Mar 2012 18:07:27 -0700 (PDT)
Received: from mail43-db3-R.bigfish.com (10.3.81.240) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 13 Mar 2012 01:07:26 +0000
Received: from mail43-db3 (localhost [127.0.0.1])	by mail43-db3-R.bigfish.com (Postfix) with ESMTP id 4DDB8E0574	for ; Tue, 13 Mar 2012 01:07:26 +0000 (UTC)
X-SpamScore: -19
X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail43-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail43-db3 (localhost.localdomain [127.0.0.1]) by mail43-db3 (MessageSwitch) id 1331600843664885_14575; Tue, 13 Mar 2012 01:07:23 +0000 (UTC)
Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.227])	by mail43-db3.bigfish.com (Postfix) with ESMTP id 9D8E9C0049	for ; Tue, 13 Mar 2012 01:07:23 +0000 (UTC)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 13 Mar 2012 01:07:23 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0283.004; Tue, 13 Mar 2012 01:07:21 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: JSON Web Token (JWT) Specification Draft -08
Thread-Index: Ac0AtZ2VWOQ/geNTRauMlubauujftQ==
Date: Tue, 13 Mar 2012 01:07:20 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366418016@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.79]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366418016TK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: [OAUTH-WG] JSON Web Token (JWT) Specification Draft -08
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Mar 2012 01:07:29 -0000

--_000_4E1F6AAD24975D4BA5B168042967394366418016TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Draft 08 of the JSON Web Token (JWT) specification has been published.  It uses the -01 vers=
ions of the JOSE specifications and also =
contains these changes:

*         Removed language that required that a JWT must have three parts. =
 Now the number of parts is explicitly dependent upon the representation of=
 the underlying JWS or JWE.

*         Moved the "alg":"none" definition to the JWS spec.

*         Registered the application/jwt MIME Media Type.

*         Clarified that the order of the creation and validation steps is =
not significant in cases where there are no dependencies between the inputs=
 and outputs of the steps.

*         Corrected the Magic Signatures and Simple Web Token (SWT) referen=
ces.
This specification is available at:

*         http://tools.ietf.org/html/draft-jones-json-web-token-08
An HTML formatted version is available at:

*         http://self-issued.info/docs/draft-jones-json-web-token-08.html

                                                                -- Mike


--_000_4E1F6AAD24975D4BA5B168042967394366418016TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Draft 08 of the 
JSON Web Token (JWT) specification has been published.  It uses th=
e 
-01 versions of the JOSE specifications and also contains these changes=
:


·        
Removed language that required that a JWT mu=
st have three parts.  Now the number of parts is explicitly dependent =
upon the representation of the underlying JWS or JWE.


·        
Moved the “alg”:“none̶=
1; definition to the JWS spec.


·        
Registered the 
application/jwt MIME Media Type.


·        
Clarified that the order of the creation and=
 validation steps is not significant in cases where there are no dependenci=
es between the inputs and outputs of the steps.


·        
Corrected the Magic Signatures and Simple We=
b Token (SWT) references.




This specification is available at:


·        
http://tools.ietf.org/html/draft-jones-json-web-to=
ken-08




An HTML formatted version is available at:


·        
http://self-issued.info/docs/draft-jones-js=
on-web-token-08.html


 


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


 






--_000_4E1F6AAD24975D4BA5B168042967394366418016TK5EX14MBXC284r_--

From stein.desmet@lin-k.net  Wed Mar 14 08:51:49 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AA421F8798 for ; Wed, 14 Mar 2012 08:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.043
X-Spam-Level: 
X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=0.556,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPfcJ7MIRl3c for ; Wed, 14 Mar 2012 08:51:45 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C92421F8587 for ; Wed, 14 Mar 2012 08:51:44 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so6002051wib.13 for ; Wed, 14 Mar 2012 08:51:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:organization:message-id:in-reply-to :user-agent:x-gm-message-state; bh=pI78SpOgYNl1KNAVpRluLdxeMDt+xqFP2YfLWUoBM3M=; b=S9F8cbxG9YoKaXbosNuB6kNPq4raB27vS2tBHeWXw/4OyDasmfbluEoipgYNHLyjdu RGvJZ+q6pO7dOq3F0KmILu5dWfBWaS1J8ySdEwFyEKLeBKSVIIdJORbGNtGvQtYW3Z/z m4I5rgbkLjhj2++l0jQjVB+vlboNnbvvGFiy8mHyrfruXuZmpQUMh7Qc7FbXQRMkrzgr SUc8Pk+98oGwxBRalfJ4ZUgY7edzlt/J8md/V4y1MUiYSKrtMVfgEQ483J7USuGcZlBL UeeEfOrqleirMtNVHIq5bfA5Vh+3Nb1i8+hnSyHps3L9GAr8JhRHFBtNuN2nSsysM7Hw CY/A==
Received: by 10.180.102.231 with SMTP id fr7mr7527400wib.10.1331740304166; Wed, 14 Mar 2012 08:51:44 -0700 (PDT)
Received: from sgdesmet.lin-k.net ([80.169.61.18]) by mx.google.com with ESMTPS id fz9sm18214132wib.3.2012.03.14.08.51.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Mar 2012 08:51:43 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Richer, Justin P." 
References:  <9A009C12-25F1-4FB6-BE7B-F0CDAD1E7A6A@mitre.org>
Date: Wed, 14 Mar 2012 16:51:41 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Stein Desmet" 
Organization: Lin.K
Message-ID: 
In-Reply-To: <9A009C12-25F1-4FB6-BE7B-F0CDAD1E7A6A@mitre.org>
User-Agent: Opera Mail/11.61 (MacIntel)
X-Gm-Message-State: ALoCoQlvg7f/3Wr/nZjExj9QgNncQNVNpRE/832hw4Os10+lIjcaE63nrYv6vP26Mj3AEEEFSPYZ
Cc: "" 
Subject: Re: [OAUTH-WG] Client credentials flow vs. authorization grant flow for native clients
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 15:51:49 -0000

Thank you for your reply. We've indeed decided to go with the  
authorization flow like you suggested, because:
- the client credentials flow would require a timeout for user  
registration (to handle idle users)
   However, it seems that you might as well use the authorization flow in  
that case, as it works
   like an OTP of sorts (as you pointed out). The authorization flow also  
has the state field,
   which solves other possible security issues with user/client  
registration in the client credentials
   flow.
- Support for the authorization flow is wider than for the others  
(including device flow)
- Implementing the authorization flow has the added benefit that we can  
immediately
   use Oauth as an alternative to our openid and saml authentication  
options.

Best regards,
Stein Desmet


On Mon, 12 Mar 2012 16:39:10 +0100, Richer, Justin P.   
wrote:

> Client credentials is not the right flow for this approach since there's  
> a user present at the client and they can close the loop for you. The  
> Device Flow, if it were to get picked up and fleshed out a bit, is a  
> better fit for what you're after and is made for just such a  
> disconnected world where you can't rely on the user logging in through a  
> browser that's easily accessible from the client app.
>
> Another, arguably better, approach would be to use the vanilla Authz  
> Code flow, taking advantage of the fact that the code is itself a OTP.  
> First, have the ClientID embedded in the mobile app, like normal. Since  
> it's a configuration time piece of information that gets copied to every  
> instance, you wouldn't use a client secret here. (It doesn't buy you  
> anything.) Next, direct your users to log into a server-side "help app",  
> which is basically just the Authz Server's authorization endpoint that's  
> been seeded with the client ID, scope, and other relevant parameters.  
> This is easy enough to do by giving your users a short URL  to go go  
> that starts off this process automatically. Next, the user goes through  
> all the normal OAuth stuff and gets redirected to a pre-registered  
> callback URL. This callback URL is hosted by your service, not by the  
> device itself. The page would then display the code so that the user  
> could type it in, present a QRCode to scan in, do some kind of  
> backchannel trusted pass, or a few other tricks to get the code from the  
> hosted site over to the device itself. Then the device uses the code,  
> which you remember is a OTP that's hopefully time limited, along with  
> its client ID to go and grab the access tokens that it needs.
>
>  -- Justin
>
>
> On Mar 9, 2012, at 5:19 AM, Stein Desmet wrote:
>
>> I have mistakingly asked this question on the google group on google's
>> Oauth2 implementation, so here it is at the correct place (I hope).
>>
>> We have an authentication server/identity provider, and a number of
>> external web applications (ie resource servers) that make use of it.
>> We would like to build native applications (iOS/Android) that make use  
>> of
>> the resources on these web applications, so adding Oauht2 to
>> both our authentication server and our web applications to provide
>> authorization seems ideal.
>>
>> However, there is one issue: it is possible for end-users to  
>> authenticate
>> themselves using smartcards or electronic ids (these users do not have
>> a login/password at all). Therefore, we can't use embedded user-agents,  
>> or
>> external user agents located on the mobile platform itself, so users
>> would need to use a browser on another computer. However, I'm not  
>> entirely
>> sure which flow is best applicable in such a case, and offers the best
>> security?
>>
>> - The client credentials flow seems like a fit. Users would need to
>> register their mobile device on the authentication server first, meaning
>> they
>>    are issued a client id and secret, unique to each client instance.  
>> These
>> credentials could be transferred in a number of ways, using QR codes,
>>    or have the user manually input them.
>> - The authorization grant flow can also be used. The flow would be  
>> started
>> on a separate browser using a helper web client app, and at the end
>>    of the flow, the authorization code is transferred to the native  
>> client
>> by for example push notifications, QR codes or having the user manually
>>    input it. Client credentials in this case would be universal for the
>> native application.
>>    This seems a bit harder to implement (and care must betaken to avoid
>> exploitation of the web client app), but the refresh tokens could be  
>> used
>>    as OTP (i.e. issuing a new refresh token each time a user asks for a  
>> new
>> access token, and invalidating the previous one), allowing some  
>> detection
>>    of misuse.
>>
>> The device flow seems applicable as well, but is no longer present in
>> recent Oauht2 drafts (though there is still
>> http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00).
>>
>> Best regards,
>> Stein Desmet
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

From mscurtescu@google.com  Wed Mar 14 09:53:45 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A2221F85B6 for ; Wed, 14 Mar 2012 09:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmfrquWwi0PQ for ; Wed, 14 Mar 2012 09:53:44 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF6FD21F852C for ; Wed, 14 Mar 2012 09:53:43 -0700 (PDT)
Received: by yhpp34 with SMTP id p34so2323484yhp.31 for ; Wed, 14 Mar 2012 09:53:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record; bh=Tx/wnuWBEcWnlHJXPolRtZulnLekQjer2ahzvdXKXXw=; b=ZB3fdgYIAzuGV2fjGjjl93cUOAAS5vDMXHM7V29lkAJPS3PtmbVD1nhJjFMtjeuC0/ RHi2hABKEHmVzvuz4chCd9JyBWIcVwbYpiioeC08T0nCMIo8Fr3sD7jtRHkvKd1Mrk5C Q7tORo7apF+OMC8gN4+oKr8zFZNnQUZCgR8TYHFw24m/Lorf/th9pRS3c3aJ4W8KbJnm Tl+1mhX53gDEdOHiSLZXT6vKAlR1fI86CEIaEl7h/TJiPvFailNsf0BX8pZ+0SNBSAYe 7OAScU1LieZZD1Jh7DDkqiM6EJL7akND6s72y/ShGOOtyLWL5ibhiVrSz5IN4QxK/xTl GvWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=Tx/wnuWBEcWnlHJXPolRtZulnLekQjer2ahzvdXKXXw=; b=OA9JkFRn3XwlYqhAafHBUMWNxwrgXIZfqw4eO2PyVq0zXXbeBoKxngo1m6JvQkSFm5 RpG6D45qSgAe2m+VLMrLjAgvT60bqGqFg3bVfiP/NlH5XafSqlrcDXxUPgaeKVQQG5NS XeAASoQo0r0t3BIqEWjS8Gk7bEsX7360jcbClnV5IyLOzzjKA5hBHziEEZ7tlFS9/ZZr L3gR+HaefrwURlOrbQ2Q9cS/5I9gf/4nypGZHMeIST3hFedGQsbfs8UTcn9sf5r6dE3h EZ/PzzhNxrrLugzC7PqTpCcIsQbXWlheAa42Gd2bqIqoUGIjwnguR34aek0EgqcfbyUV nK/A==
Received: by 10.236.153.70 with SMTP id e46mr3840091yhk.29.1331744023438; Wed, 14 Mar 2012 09:53:43 -0700 (PDT)
Received: by 10.236.153.70 with SMTP id e46mr3840082yhk.29.1331744023358; Wed, 14 Mar 2012 09:53:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.164.1 with HTTP; Wed, 14 Mar 2012 09:53:23 -0700 (PDT)
From: Marius Scurtescu 
Date: Wed, 14 Mar 2012 09:53:23 -0700
Message-ID: 
To: OAuth WG 
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmjZx64BHrrEPJEz/tnVgpOqMyYbPcvX1SexjXAfatN67Vgq04z2JK0+VIpByfh0KBTW4RiFGOIKThfDgxFhIff3YGAGyYssoMTGh2nb26FQFaOMK2gAkqSm6fceGW3gxJ3WAx8
Cc: Breno de Medeiros 
Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 16:53:45 -0000

Hi,

Nat Sakimura started a thread on the OpenID Connect list about a
breaking change introduced by rev 2.3

The paragraph in question is in section 2.1:

"A client application consisting of multiple components, each with its
own client type (e.g. a distributed client with both a confidential
server-based component and a public browser-based component), MUST
register each component separately as a different client to ensure
proper handling by the authorization server.  The authorization
server MAY provider tools to manage such complex clients through a
single administration interface."

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-oauth-v2-23.txt

You can see the thread here:
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001672.html

This paragraph basically prevents response_type=code+token which is
already implemented by many providers and also relied on by OpenID
Connect.

The intent, I think, was to prevent clients from embedding the client
secret meant for a confidential client into a public client.
JavaScript based clients using the token flow do not need the client
secret, so this concern does not apply.

Thoughts?

Thanks,
Marius

From eran@hueniverse.com  Wed Mar 14 10:08:41 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E840D21E8010 for ; Wed, 14 Mar 2012 10:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.243
X-Spam-Level: 
X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4mdLzjfscWY for ; Wed, 14 Mar 2012 10:08:41 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 3C32921F87B0 for ; Wed, 14 Mar 2012 10:08:41 -0700 (PDT)
Received: (qmail 23898 invoked from network); 14 Mar 2012 17:08:40 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Mar 2012 17:08:40 -0000
Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id lV8g1i00410TkE001V8gE3; Wed, 14 Mar 2012 10:08:40 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 14 Mar 2012 10:08:40 -0700
From: Eran Hammer 
To: Marius Scurtescu , OAuth WG 
Date: Wed, 14 Mar 2012 10:08:32 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0CAwqOQWdEeLV9SIu6J20RRRxhhAAATcQw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Breno de Medeiros 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 17:08:42 -0000

This was already raised and addressed on this list last week.

When someone defines and registers code+token, that specification must defi=
ne how such a client is registered in light of the text below. This might m=
ean defining a new client type, choosing the confidential client type with =
other normative text limiting the use of the secret in the public component=
, etc.

IOW, this section doesn't break anything because there is nothing else defi=
ned to break. There is no way to avoid explicitly defining these requiremen=
ts for a code+token response type, or any other new response type for that =
matter. The text below is required to ensure that the authorization server =
can properly enforce the rest of the normative security language in the spe=
cification.

EH


> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Marius Scurtescu
> Sent: Wednesday, March 14, 2012 9:53 AM
> To: OAuth WG
> Cc: Breno de Medeiros
> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>=20
> Hi,
>=20
> Nat Sakimura started a thread on the OpenID Connect list about a breaking
> change introduced by rev 2.3
>=20
> The paragraph in question is in section 2.1:
>=20
> "A client application consisting of multiple components, each with its ow=
n
> client type (e.g. a distributed client with both a confidential server-ba=
sed
> component and a public browser-based component), MUST register each
> component separately as a different client to ensure proper handling by t=
he
> authorization server.  The authorization server MAY provider tools to man=
age
> such complex clients through a single administration interface."
>=20
> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-oauth=
-v2-
> 23.txt
>=20
> You can see the thread here:
> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-
> 20120312/001672.html
>=20
> This paragraph basically prevents response_type=3Dcode+token which is
> already implemented by many providers and also relied on by OpenID
> Connect.
>=20
> The intent, I think, was to prevent clients from embedding the client sec=
ret
> meant for a confidential client into a public client.
> JavaScript based clients using the token flow do not need the client secr=
et, so
> this concern does not apply.
>=20
> Thoughts?
>=20
> Thanks,
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From breno@google.com  Wed Mar 14 10:16:32 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB7721F86AD for ; Wed, 14 Mar 2012 10:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.377
X-Spam-Level: 
X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTHnam27OWVj for ; Wed, 14 Mar 2012 10:16:31 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1349C21F8617 for ; Wed, 14 Mar 2012 10:16:30 -0700 (PDT)
Received: by eeke51 with SMTP id e51so1222813eek.31 for ; Wed, 14 Mar 2012 10:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=2Tm8D7/Oi/YP2QD9VklZRfaW1p1ZjXizwwnkO66Xb6w=; b=feqGl1BSRBxMDeQ0hEWt1r517z5UNx9nsrXjfl3wLGIPzqu0LTJnKLHkTePU1U8zAX 3CFAw6+5GAw9eNy5S6S0uAwULXHd0RKcBWe4oN06fp6VeMG2h+XMYYVd0/f9eY9fL18J VmwVGC0ztgC7Y2+/I2NuhhCkG9wYidgjY9cfCWE4mZkB1g/w1BpEbruqCJi0EbzKsZha cV/zDyc/BjtZHZHFQfVTbJDYjvFKRT/0mzurWWEaQCjU2oPVzNdtd5yuNTVQO8Ytw6Ft 2x2BIy8ywvuySdpU+8uJC0wU6ZjiRuSZFgmgRwty2kITx/8zfHHnAyv2RkKpkjo/PlJz RbhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=2Tm8D7/Oi/YP2QD9VklZRfaW1p1ZjXizwwnkO66Xb6w=; b=gH8Umc8tnuZiXjYh6w8lScGZfXCAgdJ/NBou/r5S19HTj+p+yH8P62qGon8heqUpj0 n4xHPNIeXsjQ+ZDZIg6iHqwRS7FxmmJCINF3glSC/fdG6WIycx4wtrRCg1+7pctGjMKy sBSG4d/4TY5IhQxtN2gcMIeJh1KO+z9LUsfxE3oQuzibUD3mRvcXo9kRFj9fhcvxVyya GxgV1Ch7VyW7JjfhEEH5d+Mvwqg4TqzYykLJhME4gR2C5nuV8Ay/91HDcWKbJ8lH5vve CRxmv25t4JvAqbz9J1ZUXusOAlGaWn9sHo1HNd8dBVyS/24MEy7jeDcs9dx9YFatfSa1 KaBw==
Received: by 10.50.6.138 with SMTP id b10mr5891699iga.21.1331745389230; Wed, 14 Mar 2012 10:16:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.6.138 with SMTP id b10mr5891360iga.21.1331745385372; Wed, 14 Mar 2012 10:16:25 -0700 (PDT)
Received: by 10.231.41.137 with HTTP; Wed, 14 Mar 2012 10:16:25 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 14 Mar 2012 10:16:25 -0700
Message-ID: 
From: Breno de Medeiros 
To: Eran Hammer 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlPqGd3pMFYlgmkBS5WQBghjcKcNynEpcR+gKZCIUFTzutyrxJSRsbWWisRfljYx3OD4V/2YqmYER4EzkRUzC2CLTb8FbsLZI/Q3Uwh7gykxUfPCPXvhB67FXbaafrYf/QkoUvH
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 17:16:32 -0000

Can you explain to me why response_type is necessary at all after this chan=
ge.

If a javascript client (candidate for token usage) and the web server
component (candidate for code usage) cannot share registration (since
they are different components with different security contexts of the
same application) then there is no need to specify response_type. The
server can infer the response type from the client and its security
context.

My objection has nothing to do with code+token flow. I think the
change makes response_types irrelevant and is essentially a new
protocol.

As far as I understand it, the introduction of different code and
token flows was precisely to allow different security-context
components of the same client to securely operate under the same
registration. I think if we change this we need to specify a lot more
behavior, such as how a client can request authorization on behalf of
several components simultaneously.

On Wed, Mar 14, 2012 at 10:08, Eran Hammer  wrote:
> This was already raised and addressed on this list last week.
>
> When someone defines and registers code+token, that specification must de=
fine how such a client is registered in light of the text below. This might=
 mean defining a new client type, choosing the confidential client type wit=
h other normative text limiting the use of the secret in the public compone=
nt, etc.
>
> IOW, this section doesn't break anything because there is nothing else de=
fined to break. There is no way to avoid explicitly defining these requirem=
ents for a code+token response type, or any other new response type for tha=
t matter. The text below is required to ensure that the authorization serve=
r can properly enforce the rest of the normative security language in the s=
pecification.
>
> EH
>
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Marius Scurtescu
>> Sent: Wednesday, March 14, 2012 9:53 AM
>> To: OAuth WG
>> Cc: Breno de Medeiros
>> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>
>> Hi,
>>
>> Nat Sakimura started a thread on the OpenID Connect list about a breakin=
g
>> change introduced by rev 2.3
>>
>> The paragraph in question is in section 2.1:
>>
>> "A client application consisting of multiple components, each with its o=
wn
>> client type (e.g. a distributed client with both a confidential server-b=
ased
>> component and a public browser-based component), MUST register each
>> component separately as a different client to ensure proper handling by =
the
>> authorization server. =A0The authorization server MAY provider tools to =
manage
>> such complex clients through a single administration interface."
>>
>> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-oaut=
h-v2-
>> 23.txt
>>
>> You can see the thread here:
>> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-
>> 20120312/001672.html
>>
>> This paragraph basically prevents response_type=3Dcode+token which is
>> already implemented by many providers and also relied on by OpenID
>> Connect.
>>
>> The intent, I think, was to prevent clients from embedding the client se=
cret
>> meant for a confidential client into a public client.
>> JavaScript based clients using the token flow do not need the client sec=
ret, so
>> this concern does not apply.
>>
>> Thoughts?
>>
>> Thanks,
>> Marius
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth



--=20
--Breno

From eran@hueniverse.com  Wed Mar 14 11:12:58 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E66421E8044 for ; Wed, 14 Mar 2012 11:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.24
X-Spam-Level: 
X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=-0.241,  BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxu9RdLtl7Ni for ; Wed, 14 Mar 2012 11:12:57 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id CB3FD21E8034 for ; Wed, 14 Mar 2012 11:12:56 -0700 (PDT)
Received: (qmail 11870 invoked from network); 14 Mar 2012 18:12:51 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Mar 2012 18:12:51 -0000
Received: from P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id lWAM1i0030SoFT401WAMbE; Wed, 14 Mar 2012 11:10:21 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 14 Mar 2012 11:09:28 -0700
From: Eran Hammer 
To: Breno de Medeiros 
Date: Wed, 14 Mar 2012 11:09:20 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0CBjRPCl/R9yvgT6mOCblWtcxwXQAB15mw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 18:12:58 -0000

If the server locks a client type to a particular grant type (or response t=
ype) then this is true, you don't need to specify the response type in the =
request. But this is based on a very limited set of potential response type=
s. I can envision a code response type with different response syntax but s=
ame security properties, and same goes for token.

In the past, a cookie response type was proposed to use the cookie headers =
in the server response instead of returning a token. The security propertie=
s of such a flow are very similar to those of token (from OAuth's perspecti=
ve). This means a public client would be able to request either token or co=
okie response type.

Also as noted, servers are allowed to provide different registration option=
s to clients, as long as the client identifies each discrete component. The=
re is no requirement or even suggestion that the server issues different cl=
ient identifiers to such complex clients. I think this is another point mis=
sed in your reading of the text.

Hope this clarifies it.

EH

> -----Original Message-----
> From: Breno de Medeiros [mailto:breno@google.com]
> Sent: Wednesday, March 14, 2012 10:16 AM
> To: Eran Hammer
> Cc: Marius Scurtescu; OAuth WG
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>=20
> Can you explain to me why response_type is necessary at all after this
> change.
>=20
> If a javascript client (candidate for token usage) and the web server
> component (candidate for code usage) cannot share registration (since the=
y
> are different components with different security contexts of the same
> application) then there is no need to specify response_type. The server c=
an
> infer the response type from the client and its security context.
>=20
> My objection has nothing to do with code+token flow. I think the change
> makes response_types irrelevant and is essentially a new protocol.
>=20
> As far as I understand it, the introduction of different code and token f=
lows
> was precisely to allow different security-context components of the same
> client to securely operate under the same registration. I think if we cha=
nge
> this we need to specify a lot more behavior, such as how a client can req=
uest
> authorization on behalf of several components simultaneously.
>=20
> On Wed, Mar 14, 2012 at 10:08, Eran Hammer 
> wrote:
> > This was already raised and addressed on this list last week.
> >
> > When someone defines and registers code+token, that specification must
> define how such a client is registered in light of the text below. This m=
ight
> mean defining a new client type, choosing the confidential client type wi=
th
> other normative text limiting the use of the secret in the public compone=
nt,
> etc.
> >
> > IOW, this section doesn't break anything because there is nothing else
> defined to break. There is no way to avoid explicitly defining these
> requirements for a code+token response type, or any other new response
> type for that matter. The text below is required to ensure that the
> authorization server can properly enforce the rest of the normative secur=
ity
> language in the specification.
> >
> > EH
> >
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf Of Marius Scurtescu
> >> Sent: Wednesday, March 14, 2012 9:53 AM
> >> To: OAuth WG
> >> Cc: Breno de Medeiros
> >> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >>
> >> Hi,
> >>
> >> Nat Sakimura started a thread on the OpenID Connect list about a
> >> breaking change introduced by rev 2.3
> >>
> >> The paragraph in question is in section 2.1:
> >>
> >> "A client application consisting of multiple components, each with
> >> its own client type (e.g. a distributed client with both a
> >> confidential server-based component and a public browser-based
> >> component), MUST register each component separately as a different
> >> client to ensure proper handling by the authorization server. =A0The
> >> authorization server MAY provider tools to manage such complex clients
> through a single administration interface."
> >>
> >> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-oa=
uth
> >> -v2-
> >> 23.txt
> >>
> >> You can see the thread here:
> >> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-
> >> 20120312/001672.html
> >>
> >> This paragraph basically prevents response_type=3Dcode+token which is
> >> already implemented by many providers and also relied on by OpenID
> >> Connect.
> >>
> >> The intent, I think, was to prevent clients from embedding the client
> >> secret meant for a confidential client into a public client.
> >> JavaScript based clients using the token flow do not need the client
> >> secret, so this concern does not apply.
> >>
> >> Thoughts?
> >>
> >> Thanks,
> >> Marius
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
> --
> --Breno

From mscurtescu@google.com  Wed Mar 14 11:24:12 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D8221F84FD for ; Wed, 14 Mar 2012 11:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.677
X-Spam-Level: 
X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKKfMYWfQynx for ; Wed, 14 Mar 2012 11:24:11 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1362121F84FE for ; Wed, 14 Mar 2012 11:24:10 -0700 (PDT)
Received: by yhpp34 with SMTP id p34so2430951yhp.31 for ; Wed, 14 Mar 2012 11:24:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=RGwuuES2UtC2a1BHQkdLxaIZJnNORwUAIoxDsE/nubQ=; b=CxeOqaFrDVLZE+o9Nq81PKbaAR1cuZmemTcMfmgy//5tOnkVO+UbwmOdapo0iBna6S YPHRlVQ9TK/34M3h69iPBJ2bIRP8BsSg1XV1JVjOhIOjs7t7xiw0b3Kw7ssUoZk86AQm eAELQrFTD6H5nyPXlXyum5MZFF4MqOR1AdRLoTnbNstRJqHqNNgWrRpEwzJ98yvyApS3 ZMRqRm2GXdSCeoT87sZGJBTZgACL7QLIdc/rjQHSMbBsrTmGX+bFMzDkeo3S/cbQ0k4E 6x5wa0NpOiykJq/dEezQX1O43EpGzSBH8oHxGBXRlUrS0iXBNwJVTnPKdKTaRRid91AI GA2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=RGwuuES2UtC2a1BHQkdLxaIZJnNORwUAIoxDsE/nubQ=; b=J0x6PHAtS98pfSVgwFNgUbw+GoxNc0i0rN2p/IQqtkyr65fR3+l5EmfcWfrXIm4Zp5 NYeA1c3zE/uD4EBPeGG3Xv1WH9nS7MsGhvypyW+1TXWwCWjNLUaFd7qbG4Sr+im3Ibgl //Z7oCWHcpmGmM+kz3XA0mxD8VdeI+MEvIU508nwCg4+2PuCXXWBoPx+tOjipR/BNfiT b7boUPEcKY3M9p/VXgjsK04Hf8CRq0vI09KxXzk1Agrk+ygGOULaLQ68nv8qst4WeS8M vNejn0sAzpZ9kyoIGJPeU5H7HUM5dMJJk/t0CS3BhsVvbEH26DphO8soGkOQz4Btjkl8 0t+Q==
Received: by 10.236.46.232 with SMTP id r68mr4232447yhb.80.1331749450441; Wed, 14 Mar 2012 11:24:10 -0700 (PDT)
Received: by 10.236.46.232 with SMTP id r68mr4232434yhb.80.1331749450335; Wed, 14 Mar 2012 11:24:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.164.1 with HTTP; Wed, 14 Mar 2012 11:23:50 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Marius Scurtescu 
Date: Wed, 14 Mar 2012 11:23:50 -0700
Message-ID: 
To: Eran Hammer 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkYfSZR/nlBPl6vGc6lVUsVxIgqt6Lin6hqON7GnuQK8mO641tfySJg0PJHQ9KhmNb71IEgQZz0sA15ehtFFf9+PA245efTVAsYnw3YZ6d8k9dffSMXdp5Rxi505Zq2bQunu4ze
Cc: Breno de Medeiros , OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 18:24:12 -0000

Before v23 a web server client could use either response_type=3Dcode or
response_type=3Dtoken, with the same client id. No security issues and
this was supported for quite a while.

With this latest change, if I am reading it correctly, this is not
possible anymore. The client has to use two different client ids. It
is very late in the game to introduce changes like this, unless there
is an extremely good reason.

Marius



On Wed, Mar 14, 2012 at 11:09 AM, Eran Hammer  wrote:
> If the server locks a client type to a particular grant type (or response=
 type) then this is true, you don't need to specify the response type in th=
e request. But this is based on a very limited set of potential response ty=
pes. I can envision a code response type with different response syntax but=
 same security properties, and same goes for token.
>
> In the past, a cookie response type was proposed to use the cookie header=
s in the server response instead of returning a token. The security propert=
ies of such a flow are very similar to those of token (from OAuth's perspec=
tive). This means a public client would be able to request either token or =
cookie response type.
>
> Also as noted, servers are allowed to provide different registration opti=
ons to clients, as long as the client identifies each discrete component. T=
here is no requirement or even suggestion that the server issues different =
client identifiers to such complex clients. I think this is another point m=
issed in your reading of the text.
>
> Hope this clarifies it.
>
> EH
>
>> -----Original Message-----
>> From: Breno de Medeiros [mailto:breno@google.com]
>> Sent: Wednesday, March 14, 2012 10:16 AM
>> To: Eran Hammer
>> Cc: Marius Scurtescu; OAuth WG
>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>
>> Can you explain to me why response_type is necessary at all after this
>> change.
>>
>> If a javascript client (candidate for token usage) and the web server
>> component (candidate for code usage) cannot share registration (since th=
ey
>> are different components with different security contexts of the same
>> application) then there is no need to specify response_type. The server =
can
>> infer the response type from the client and its security context.
>>
>> My objection has nothing to do with code+token flow. I think the change
>> makes response_types irrelevant and is essentially a new protocol.
>>
>> As far as I understand it, the introduction of different code and token =
flows
>> was precisely to allow different security-context components of the same
>> client to securely operate under the same registration. I think if we ch=
ange
>> this we need to specify a lot more behavior, such as how a client can re=
quest
>> authorization on behalf of several components simultaneously.
>>
>> On Wed, Mar 14, 2012 at 10:08, Eran Hammer 
>> wrote:
>> > This was already raised and addressed on this list last week.
>> >
>> > When someone defines and registers code+token, that specification must
>> define how such a client is registered in light of the text below. This =
might
>> mean defining a new client type, choosing the confidential client type w=
ith
>> other normative text limiting the use of the secret in the public compon=
ent,
>> etc.
>> >
>> > IOW, this section doesn't break anything because there is nothing else
>> defined to break. There is no way to avoid explicitly defining these
>> requirements for a code+token response type, or any other new response
>> type for that matter. The text below is required to ensure that the
>> authorization server can properly enforce the rest of the normative secu=
rity
>> language in the specification.
>> >
>> > EH
>> >
>> >
>> >> -----Original Message-----
>> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>> >> Behalf Of Marius Scurtescu
>> >> Sent: Wednesday, March 14, 2012 9:53 AM
>> >> To: OAuth WG
>> >> Cc: Breno de Medeiros
>> >> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>> >>
>> >> Hi,
>> >>
>> >> Nat Sakimura started a thread on the OpenID Connect list about a
>> >> breaking change introduced by rev 2.3
>> >>
>> >> The paragraph in question is in section 2.1:
>> >>
>> >> "A client application consisting of multiple components, each with
>> >> its own client type (e.g. a distributed client with both a
>> >> confidential server-based component and a public browser-based
>> >> component), MUST register each component separately as a different
>> >> client to ensure proper handling by the authorization server. =A0The
>> >> authorization server MAY provider tools to manage such complex client=
s
>> through a single administration interface."
>> >>
>> >> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-o=
auth
>> >> -v2-
>> >> 23.txt
>> >>
>> >> You can see the thread here:
>> >> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-
>> >> 20120312/001672.html
>> >>
>> >> This paragraph basically prevents response_type=3Dcode+token which is
>> >> already implemented by many providers and also relied on by OpenID
>> >> Connect.
>> >>
>> >> The intent, I think, was to prevent clients from embedding the client
>> >> secret meant for a confidential client into a public client.
>> >> JavaScript based clients using the token flow do not need the client
>> >> secret, so this concern does not apply.
>> >>
>> >> Thoughts?
>> >>
>> >> Thanks,
>> >> Marius
>> >> _______________________________________________
>> >> OAuth mailing list
>> >> OAuth@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> --
>> --Breno

From eran@hueniverse.com  Wed Mar 14 11:37:02 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54AB21F8657 for ; Wed, 14 Mar 2012 11:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.237
X-Spam-Level: 
X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOOx2nzgKHDQ for ; Wed, 14 Mar 2012 11:37:02 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 1B6D521F8647 for ; Wed, 14 Mar 2012 11:37:01 -0700 (PDT)
Received: (qmail 17932 invoked from network); 14 Mar 2012 18:37:00 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Mar 2012 18:37:00 -0000
Received: from P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id lWcz1i0060SoFT401Wd0v7; Wed, 14 Mar 2012 11:37:00 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 14 Mar 2012 11:35:24 -0700
From: Eran Hammer 
To: Marius Scurtescu 
Date: Wed, 14 Mar 2012 11:35:15 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0CD6iKbWwcDxp5QUC/EBDwlLeirgAAOfAg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Breno de Medeiros , OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 18:37:03 -0000

You are not reading it correctly.

This is a *registration* requirement, meaning, the client has to inform the=
 server of the different components. If the server doesn't care, it can iss=
ue one client identifier capable of both.

This protocol assume the authorization server asked the client for its type=
 and based on that made decisions about the credentials issued and the secu=
rity properties of the client. It is also triggers a whole list of normativ=
e language handling the different client types throughout the specification=
.

EH

> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurtescu@google.com]
> Sent: Wednesday, March 14, 2012 11:24 AM
> To: Eran Hammer
> Cc: Breno de Medeiros; OAuth WG
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>=20
> Before v23 a web server client could use either response_type=3Dcode or
> response_type=3Dtoken, with the same client id. No security issues and th=
is
> was supported for quite a while.
>=20
> With this latest change, if I am reading it correctly, this is not possib=
le
> anymore. The client has to use two different client ids. It is very late =
in the
> game to introduce changes like this, unless there is an extremely good
> reason.
>=20
> Marius
>=20
>=20
>=20
> On Wed, Mar 14, 2012 at 11:09 AM, Eran Hammer 
> wrote:
> > If the server locks a client type to a particular grant type (or respon=
se type)
> then this is true, you don't need to specify the response type in the req=
uest.
> But this is based on a very limited set of potential response types. I ca=
n
> envision a code response type with different response syntax but same
> security properties, and same goes for token.
> >
> > In the past, a cookie response type was proposed to use the cookie
> headers in the server response instead of returning a token. The security
> properties of such a flow are very similar to those of token (from OAuth'=
s
> perspective). This means a public client would be able to request either
> token or cookie response type.
> >
> > Also as noted, servers are allowed to provide different registration op=
tions
> to clients, as long as the client identifies each discrete component. The=
re is
> no requirement or even suggestion that the server issues different client
> identifiers to such complex clients. I think this is another point missed=
 in your
> reading of the text.
> >
> > Hope this clarifies it.
> >
> > EH
> >
> >> -----Original Message-----
> >> From: Breno de Medeiros [mailto:breno@google.com]
> >> Sent: Wednesday, March 14, 2012 10:16 AM
> >> To: Eran Hammer
> >> Cc: Marius Scurtescu; OAuth WG
> >> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >>
> >> Can you explain to me why response_type is necessary at all after
> >> this change.
> >>
> >> If a javascript client (candidate for token usage) and the web server
> >> component (candidate for code usage) cannot share registration (since
> >> they are different components with different security contexts of the
> >> same
> >> application) then there is no need to specify response_type. The
> >> server can infer the response type from the client and its security co=
ntext.
> >>
> >> My objection has nothing to do with code+token flow. I think the
> >> change makes response_types irrelevant and is essentially a new
> protocol.
> >>
> >> As far as I understand it, the introduction of different code and
> >> token flows was precisely to allow different security-context
> >> components of the same client to securely operate under the same
> >> registration. I think if we change this we need to specify a lot more
> >> behavior, such as how a client can request authorization on behalf of
> several components simultaneously.
> >>
> >> On Wed, Mar 14, 2012 at 10:08, Eran Hammer 
> >> wrote:
> >> > This was already raised and addressed on this list last week.
> >> >
> >> > When someone defines and registers code+token, that specification
> >> > must
> >> define how such a client is registered in light of the text below.
> >> This might mean defining a new client type, choosing the confidential
> >> client type with other normative text limiting the use of the secret
> >> in the public component, etc.
> >> >
> >> > IOW, this section doesn't break anything because there is nothing
> >> > else
> >> defined to break. There is no way to avoid explicitly defining these
> >> requirements for a code+token response type, or any other new
> >> response type for that matter. The text below is required to ensure
> >> that the authorization server can properly enforce the rest of the
> >> normative security language in the specification.
> >> >
> >> > EH
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> >> Behalf Of Marius Scurtescu
> >> >> Sent: Wednesday, March 14, 2012 9:53 AM
> >> >> To: OAuth WG
> >> >> Cc: Breno de Medeiros
> >> >> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >> >>
> >> >> Hi,
> >> >>
> >> >> Nat Sakimura started a thread on the OpenID Connect list about a
> >> >> breaking change introduced by rev 2.3
> >> >>
> >> >> The paragraph in question is in section 2.1:
> >> >>
> >> >> "A client application consisting of multiple components, each with
> >> >> its own client type (e.g. a distributed client with both a
> >> >> confidential server-based component and a public browser-based
> >> >> component), MUST register each component separately as a different
> >> >> client to ensure proper handling by the authorization server. =A0Th=
e
> >> >> authorization server MAY provider tools to manage such complex
> >> >> clients
> >> through a single administration interface."
> >> >>
> >> >> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf=
-oa
> >> >> uth
> >> >> -v2-
> >> >> 23.txt
> >> >>
> >> >> You can see the thread here:
> >> >> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-
> >> >> 20120312/001672.html
> >> >>
> >> >> This paragraph basically prevents response_type=3Dcode+token which
> >> >> is already implemented by many providers and also relied on by
> >> >> OpenID Connect.
> >> >>
> >> >> The intent, I think, was to prevent clients from embedding the
> >> >> client secret meant for a confidential client into a public client.
> >> >> JavaScript based clients using the token flow do not need the
> >> >> client secret, so this concern does not apply.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> Thanks,
> >> >> Marius
> >> >> _______________________________________________
> >> >> OAuth mailing list
> >> >> OAuth@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >>
> >> --
> >> --Breno

From Michael.Jones@microsoft.com  Wed Mar 14 11:42:21 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC5F21F8647 for ; Wed, 14 Mar 2012 11:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.562
X-Spam-Level: 
X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0-QaP-hsQcg for ; Wed, 14 Mar 2012 11:42:20 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id F123C21F8540 for ; Wed, 14 Mar 2012 11:42:19 -0700 (PDT)
Received: from mail164-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Mar 2012 18:42:20 +0000
Received: from mail164-ch1 (localhost [127.0.0.1])	by mail164-ch1-R.bigfish.com (Postfix) with ESMTP id C162130061A; Wed, 14 Mar 2012 18:42:20 +0000 (UTC)
X-SpamScore: -41
X-BigFish: VS-41(zz9371I1803M542M1432N98dK4015Izz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail164-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail164-ch1 (localhost.localdomain [127.0.0.1]) by mail164-ch1 (MessageSwitch) id 1331750538765481_4981; Wed, 14 Mar 2012 18:42:18 +0000 (UTC)
Received: from CH1EHSMHS023.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228])	by mail164-ch1.bigfish.com (Postfix) with ESMTP id B4B5A2C0294;	Wed, 14 Mar 2012 18:42:18 +0000 (UTC)
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Mar 2012 18:42:17 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0283.004; Wed, 14 Mar 2012 18:42:03 +0000
From: Mike Jones 
To: Eran Hammer , Marius Scurtescu 
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: AQHNAgMKtRI52qb7tE6+kmeeW24qnZZqBiQAgAACNICAAA7JAIAABA0AgAADMYCAAACtcA==
Date: Wed, 14 Mar 2012 18:42:03 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.37]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: Breno de Medeiros , OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 18:42:21 -0000

All of Marius, Breno, Nat, myself, and several others on the OpenID AB list=
 have read it this way.  I believe that either this change needs to be remo=
ved (my preference!) or a sentence needs to be explicitly added that states=
 that "The same client_id MAY be used with both the code and token response=
 types"  to explicitly rule out this apparently common misinterpretation of=
 the new text.

Otherwise, I agree that it will continue to be perceived by most people as =
a breaking change.

				-- Mike

P.S.  When you make this change, you should also correct the typo in this s=
entence: "The authorization server MAY provider tools to manage such comple=
x clients through a single administration interface" by changing "provider"=
 to "provide".

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E=
ran Hammer
Sent: Wednesday, March 14, 2012 11:35 AM
To: Marius Scurtescu
Cc: Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

You are not reading it correctly.

This is a *registration* requirement, meaning, the client has to inform the=
 server of the different components. If the server doesn't care, it can iss=
ue one client identifier capable of both.

This protocol assume the authorization server asked the client for its type=
 and based on that made decisions about the credentials issued and the secu=
rity properties of the client. It is also triggers a whole list of normativ=
e language handling the different client types throughout the specification=
.

EH

> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurtescu@google.com]
> Sent: Wednesday, March 14, 2012 11:24 AM
> To: Eran Hammer
> Cc: Breno de Medeiros; OAuth WG
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>=20
> Before v23 a web server client could use either response_type=3Dcode or=20
> response_type=3Dtoken, with the same client id. No security issues and=20
> this was supported for quite a while.
>=20
> With this latest change, if I am reading it correctly, this is not=20
> possible anymore. The client has to use two different client ids. It=20
> is very late in the game to introduce changes like this, unless there=20
> is an extremely good reason.
>=20
> Marius
>=20
>=20
>=20
> On Wed, Mar 14, 2012 at 11:09 AM, Eran Hammer 
> wrote:
> > If the server locks a client type to a particular grant type (or=20
> > response type)
> then this is true, you don't need to specify the response type in the req=
uest.
> But this is based on a very limited set of potential response types. I=20
> can envision a code response type with different response syntax but=20
> same security properties, and same goes for token.
> >
> > In the past, a cookie response type was proposed to use the cookie
> headers in the server response instead of returning a token. The=20
> security properties of such a flow are very similar to those of token=20
> (from OAuth's perspective). This means a public client would be able=20
> to request either token or cookie response type.
> >
> > Also as noted, servers are allowed to provide different registration=20
> > options
> to clients, as long as the client identifies each discrete component.=20
> There is no requirement or even suggestion that the server issues=20
> different client identifiers to such complex clients. I think this is=20
> another point missed in your reading of the text.
> >
> > Hope this clarifies it.
> >
> > EH
> >
> >> -----Original Message-----
> >> From: Breno de Medeiros [mailto:breno@google.com]
> >> Sent: Wednesday, March 14, 2012 10:16 AM
> >> To: Eran Hammer
> >> Cc: Marius Scurtescu; OAuth WG
> >> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >>
> >> Can you explain to me why response_type is necessary at all after=20
> >> this change.
> >>
> >> If a javascript client (candidate for token usage) and the web=20
> >> server component (candidate for code usage) cannot share=20
> >> registration (since they are different components with different=20
> >> security contexts of the same
> >> application) then there is no need to specify response_type. The=20
> >> server can infer the response type from the client and its security co=
ntext.
> >>
> >> My objection has nothing to do with code+token flow. I think the=20
> >> change makes response_types irrelevant and is essentially a new
> protocol.
> >>
> >> As far as I understand it, the introduction of different code and=20
> >> token flows was precisely to allow different security-context=20
> >> components of the same client to securely operate under the same=20
> >> registration. I think if we change this we need to specify a lot=20
> >> more behavior, such as how a client can request authorization on=20
> >> behalf of
> several components simultaneously.
> >>
> >> On Wed, Mar 14, 2012 at 10:08, Eran Hammer 
> >> wrote:
> >> > This was already raised and addressed on this list last week.
> >> >
> >> > When someone defines and registers code+token, that specification=20
> >> > must
> >> define how such a client is registered in light of the text below.
> >> This might mean defining a new client type, choosing the=20
> >> confidential client type with other normative text limiting the use=20
> >> of the secret in the public component, etc.
> >> >
> >> > IOW, this section doesn't break anything because there is nothing=20
> >> > else
> >> defined to break. There is no way to avoid explicitly defining=20
> >> these requirements for a code+token response type, or any other new=20
> >> response type for that matter. The text below is required to ensure=20
> >> that the authorization server can properly enforce the rest of the=20
> >> normative security language in the specification.
> >> >
> >> > EH
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20
> >> >> Behalf Of Marius Scurtescu
> >> >> Sent: Wednesday, March 14, 2012 9:53 AM
> >> >> To: OAuth WG
> >> >> Cc: Breno de Medeiros
> >> >> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >> >>
> >> >> Hi,
> >> >>
> >> >> Nat Sakimura started a thread on the OpenID Connect list about a=20
> >> >> breaking change introduced by rev 2.3
> >> >>
> >> >> The paragraph in question is in section 2.1:
> >> >>
> >> >> "A client application consisting of multiple components, each=20
> >> >> with its own client type (e.g. a distributed client with both a=20
> >> >> confidential server-based component and a public browser-based=20
> >> >> component), MUST register each component separately as a=20
> >> >> different client to ensure proper handling by the authorization=20
> >> >> server. =A0The authorization server MAY provider tools to manage=20
> >> >> such complex clients
> >> through a single administration interface."
> >> >>
> >> >> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf=
-
> >> >> oa
> >> >> uth
> >> >> -v2-
> >> >> 23.txt
> >> >>
> >> >> You can see the thread here:
> >> >> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-
> >> >> 20120312/001672.html
> >> >>
> >> >> This paragraph basically prevents response_type=3Dcode+token which=
=20
> >> >> is already implemented by many providers and also relied on by=20
> >> >> OpenID Connect.
> >> >>
> >> >> The intent, I think, was to prevent clients from embedding the=20
> >> >> client secret meant for a confidential client into a public client.
> >> >> JavaScript based clients using the token flow do not need the=20
> >> >> client secret, so this concern does not apply.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> Thanks,
> >> >> Marius
> >> >> _______________________________________________
> >> >> OAuth mailing list
> >> >> OAuth@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >>
> >> --
> >> --Breno
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



From eran@hueniverse.com  Wed Mar 14 12:24:18 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2C721F87FD for ; Wed, 14 Mar 2012 12:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level: 
X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbMSCwOmzhkn for ; Wed, 14 Mar 2012 12:24:17 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 600F721F87FC for ; Wed, 14 Mar 2012 12:24:17 -0700 (PDT)
Received: (qmail 25197 invoked from network); 14 Mar 2012 19:24:07 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Mar 2012 19:24:07 -0000
Received: from P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id lXQ41i0030SoFT401XQ6ph; Wed, 14 Mar 2012 12:24:06 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 14 Mar 2012 12:23:24 -0700
From: Eran Hammer 
To: Mike Jones , Marius Scurtescu 
Date: Wed, 14 Mar 2012 12:23:16 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: AQHNAgMKtRI52qb7tE6+kmeeW24qnZZqBiQAgAACNICAAA7JAIAABA0AgAADMYCAAACtcIAABZMA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Breno de Medeiros , OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 19:24:18 -0000

Let's take a step back for a second.

Previous versions of this document stated that during the registration proc=
ess the client developer specifies the client type as described in 2.1. Thi=
s has been specified under "registration requirements" since -17 published =
July 8th 2011. The only two types provided were (and still are) public and =
confidential.

While there was no MUST or SHALL directive, the text was pretty clear about=
 the need for each client registration to be tied to a single client type.

-23 was an attempt to clarify this, by making it explicit that hybrid clien=
ts are not addressed by the specification, and have to be dealt with as two=
 separate clients.

The specification breaks if a client has more than one type. The authorizat=
ion server cannot enforce some of the security requirements if the client t=
ype is unknown. This is all based on how the specification is written and h=
ow the security consideration section is structured.

The real issue raised here is how to handle hybrid clients which are beyond=
 the scope of this specification.

Here is an alternative text:

   A client application consisting of multiple components, each with its
   own client type (e.g. a distributed client with both a confidential
   server-based component and a public browser-based component), MUST
   register each component separately as a different client to ensure
   proper handling by the authorization server, unless the authorization
   server provides other registration options to specify such complex clien=
ts.

It's basically saying that unless the authorization server provides a speci=
al option other than 'public' and 'confidential', clients MUST register suc=
h applications separately for each component. It leaves the decision of how=
 to deal with such clients completely up to the authorization server during=
 the registration process.

I think we should also add a SHALL in section 2: "When registering a client=
, the client developer SHALL:", which is implicit already.

Another, less desirable alternative is to remove this section and add:

   The authorization server MAY provide the client with other client types
   options during the registration process. Such client types are beyond th=
e
   scope of this specification. Such additional client types will require a
   different set of security considerations not provided by this specificat=
ion.

My intention was never to introduce a (breaking) change here, just to clari=
fy what was already the prescribed process. I'm open to other suggestions a=
s long as they account for the deep dependency this protocol has on client =
type identification.

EH



> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Wednesday, March 14, 2012 11:42 AM
> To: Eran Hammer; Marius Scurtescu
> Cc: Breno de Medeiros; OAuth WG
> Subject: RE: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>=20
> All of Marius, Breno, Nat, myself, and several others on the OpenID AB li=
st
> have read it this way.  I believe that either this change needs to be rem=
oved
> (my preference!) or a sentence needs to be explicitly added that states t=
hat
> "The same client_id MAY be used with both the code and token response
> types"  to explicitly rule out this apparently common misinterpretation o=
f the
> new text.
>=20
> Otherwise, I agree that it will continue to be perceived by most people a=
s a
> breaking change.
>=20
> 				-- Mike
>=20
> P.S.  When you make this change, you should also correct the typo in this
> sentence: "The authorization server MAY provider tools to manage such
> complex clients through a single administration interface" by changing
> "provider" to "provide".
>=20
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer
> Sent: Wednesday, March 14, 2012 11:35 AM
> To: Marius Scurtescu
> Cc: Breno de Medeiros; OAuth WG
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>=20
> You are not reading it correctly.
>=20
> This is a *registration* requirement, meaning, the client has to inform t=
he
> server of the different components. If the server doesn't care, it can is=
sue
> one client identifier capable of both.
>=20
> This protocol assume the authorization server asked the client for its ty=
pe
> and based on that made decisions about the credentials issued and the
> security properties of the client. It is also triggers a whole list of no=
rmative
> language handling the different client types throughout the specification=
.
>=20
> EH
>=20
> > -----Original Message-----
> > From: Marius Scurtescu [mailto:mscurtescu@google.com]
> > Sent: Wednesday, March 14, 2012 11:24 AM
> > To: Eran Hammer
> > Cc: Breno de Medeiros; OAuth WG
> > Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >
> > Before v23 a web server client could use either response_type=3Dcode or
> > response_type=3Dtoken, with the same client id. No security issues and
> > this was supported for quite a while.
> >
> > With this latest change, if I am reading it correctly, this is not
> > possible anymore. The client has to use two different client ids. It
> > is very late in the game to introduce changes like this, unless there
> > is an extremely good reason.
> >
> > Marius
> >
> >
> >
> > On Wed, Mar 14, 2012 at 11:09 AM, Eran Hammer 
> > wrote:
> > > If the server locks a client type to a particular grant type (or
> > > response type)
> > then this is true, you don't need to specify the response type in the
> request.
> > But this is based on a very limited set of potential response types. I
> > can envision a code response type with different response syntax but
> > same security properties, and same goes for token.
> > >
> > > In the past, a cookie response type was proposed to use the cookie
> > headers in the server response instead of returning a token. The
> > security properties of such a flow are very similar to those of token
> > (from OAuth's perspective). This means a public client would be able
> > to request either token or cookie response type.
> > >
> > > Also as noted, servers are allowed to provide different registration
> > > options
> > to clients, as long as the client identifies each discrete component.
> > There is no requirement or even suggestion that the server issues
> > different client identifiers to such complex clients. I think this is
> > another point missed in your reading of the text.
> > >
> > > Hope this clarifies it.
> > >
> > > EH
> > >
> > >> -----Original Message-----
> > >> From: Breno de Medeiros [mailto:breno@google.com]
> > >> Sent: Wednesday, March 14, 2012 10:16 AM
> > >> To: Eran Hammer
> > >> Cc: Marius Scurtescu; OAuth WG
> > >> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> > >>
> > >> Can you explain to me why response_type is necessary at all after
> > >> this change.
> > >>
> > >> If a javascript client (candidate for token usage) and the web
> > >> server component (candidate for code usage) cannot share
> > >> registration (since they are different components with different
> > >> security contexts of the same
> > >> application) then there is no need to specify response_type. The
> > >> server can infer the response type from the client and its security
> context.
> > >>
> > >> My objection has nothing to do with code+token flow. I think the
> > >> change makes response_types irrelevant and is essentially a new
> > protocol.
> > >>
> > >> As far as I understand it, the introduction of different code and
> > >> token flows was precisely to allow different security-context
> > >> components of the same client to securely operate under the same
> > >> registration. I think if we change this we need to specify a lot
> > >> more behavior, such as how a client can request authorization on
> > >> behalf of
> > several components simultaneously.
> > >>
> > >> On Wed, Mar 14, 2012 at 10:08, Eran Hammer 
> > >> wrote:
> > >> > This was already raised and addressed on this list last week.
> > >> >
> > >> > When someone defines and registers code+token, that specification
> > >> > must
> > >> define how such a client is registered in light of the text below.
> > >> This might mean defining a new client type, choosing the
> > >> confidential client type with other normative text limiting the use
> > >> of the secret in the public component, etc.
> > >> >
> > >> > IOW, this section doesn't break anything because there is nothing
> > >> > else
> > >> defined to break. There is no way to avoid explicitly defining
> > >> these requirements for a code+token response type, or any other new
> > >> response type for that matter. The text below is required to ensure
> > >> that the authorization server can properly enforce the rest of the
> > >> normative security language in the specification.
> > >> >
> > >> > EH
> > >> >
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> > >> >> Behalf Of Marius Scurtescu
> > >> >> Sent: Wednesday, March 14, 2012 9:53 AM
> > >> >> To: OAuth WG
> > >> >> Cc: Breno de Medeiros
> > >> >> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> > >> >>
> > >> >> Hi,
> > >> >>
> > >> >> Nat Sakimura started a thread on the OpenID Connect list about a
> > >> >> breaking change introduced by rev 2.3
> > >> >>
> > >> >> The paragraph in question is in section 2.1:
> > >> >>
> > >> >> "A client application consisting of multiple components, each
> > >> >> with its own client type (e.g. a distributed client with both a
> > >> >> confidential server-based component and a public browser-based
> > >> >> component), MUST register each component separately as a
> > >> >> different client to ensure proper handling by the authorization
> > >> >> server. =A0The authorization server MAY provider tools to manage
> > >> >> such complex clients
> > >> through a single administration interface."
> > >> >>
> > >> >> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ie=
tf-
> > >> >> oa
> > >> >> uth
> > >> >> -v2-
> > >> >> 23.txt
> > >> >>
> > >> >> You can see the thread here:
> > >> >> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-
> > >> >> 20120312/001672.html
> > >> >>
> > >> >> This paragraph basically prevents response_type=3Dcode+token whic=
h
> > >> >> is already implemented by many providers and also relied on by
> > >> >> OpenID Connect.
> > >> >>
> > >> >> The intent, I think, was to prevent clients from embedding the
> > >> >> client secret meant for a confidential client into a public clien=
t.
> > >> >> JavaScript based clients using the token flow do not need the
> > >> >> client secret, so this concern does not apply.
> > >> >>
> > >> >> Thoughts?
> > >> >>
> > >> >> Thanks,
> > >> >> Marius
> > >> >> _______________________________________________
> > >> >> OAuth mailing list
> > >> >> OAuth@ietf.org
> > >> >> https://www.ietf.org/mailman/listinfo/oauth
> > >>
> > >>
> > >>
> > >> --
> > >> --Breno
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


From jricher@mitre.org  Wed Mar 14 12:47:42 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46D821F875B for ; Wed, 14 Mar 2012 12:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.284
X-Spam-Level: 
X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4lOURKZSvjo for ; Wed, 14 Mar 2012 12:47:41 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFD021F880F for ; Wed, 14 Mar 2012 12:47:41 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1D7DD21B0367; Wed, 14 Mar 2012 15:47:40 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id F019521B1235; Wed, 14 Mar 2012 15:47:39 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.126]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Wed, 14 Mar 2012 15:47:39 -0400
From: "Richer, Justin P." 
To: Eran Hammer 
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: AQHNAgMWxQQUri5nmEOAit8MpDUHmZZqSTIAgAACNICAAA7JAIAABA0AgAADMYCAAAHmgIAAC4QAgAAGzwA=
Date: Wed, 14 Mar 2012 19:47:38 +0000
Message-ID: 
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.8.106]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Breno de Medeiros , OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 19:47:42 -0000

Even though I also don't like the addition of normative text in such a late=
 revision, I'm with Eran in that I don't think this actually introduces a b=
reaking change, nor did I read it as such when it went through. It's talkin=
g about public vs. confidential clients and keeping them separate, and it's=
 really got nothing to do with the response type. After all, you can have a=
 public client use the code flow (like a native app) just fine. But though =
if it's clear to me, it's definitely to the spec's benefit to make sure tha=
t the language is clear, and as Mike points out if a decent subset of famil=
iar developers misread it the same way, then we should fix that.

I think that perhaps the use of normative language here was the major confu=
sing point -- it made something explicitly normative that was implicitly re=
commended before. If that's the case, would removal of the normative MUST (=
change to "must" or "really should") in the client type text help the situa=
tion?

Barring the relaxation of normative language here, Eran's first text below =
clarifies that this is in response to the public/confidential client type a=
nd *NOT* the response_type, and does so better than Mike's suggested text w=
hich I believe continues to conflate the two.=20

 -- Justin

On Mar 14, 2012, at 3:23 PM, Eran Hammer wrote:

> Let's take a step back for a second.
>=20
> Previous versions of this document stated that during the registration pr=
ocess the client developer specifies the client type as described in 2.1. T=
his has been specified under "registration requirements" since -17 publishe=
d July 8th 2011. The only two types provided were (and still are) public an=
d confidential.
>=20
> While there was no MUST or SHALL directive, the text was pretty clear abo=
ut the need for each client registration to be tied to a single client type=
.
>=20
> -23 was an attempt to clarify this, by making it explicit that hybrid cli=
ents are not addressed by the specification, and have to be dealt with as t=
wo separate clients.
>=20
> The specification breaks if a client has more than one type. The authoriz=
ation server cannot enforce some of the security requirements if the client=
 type is unknown. This is all based on how the specification is written and=
 how the security consideration section is structured.
>=20
> The real issue raised here is how to handle hybrid clients which are beyo=
nd the scope of this specification.
>=20
> Here is an alternative text:
>=20
>   A client application consisting of multiple components, each with its
>   own client type (e.g. a distributed client with both a confidential
>   server-based component and a public browser-based component), MUST
>   register each component separately as a different client to ensure
>   proper handling by the authorization server, unless the authorization
>   server provides other registration options to specify such complex clie=
nts.
>=20
> It's basically saying that unless the authorization server provides a spe=
cial option other than 'public' and 'confidential', clients MUST register s=
uch applications separately for each component. It leaves the decision of h=
ow to deal with such clients completely up to the authorization server duri=
ng the registration process.
>=20
> I think we should also add a SHALL in section 2: "When registering a clie=
nt, the client developer SHALL:", which is implicit already.
>=20
> Another, less desirable alternative is to remove this section and add:
>=20
>   The authorization server MAY provide the client with other client types
>   options during the registration process. Such client types are beyond t=
he
>   scope of this specification. Such additional client types will require =
a
>   different set of security considerations not provided by this specifica=
tion.
>=20
> My intention was never to introduce a (breaking) change here, just to cla=
rify what was already the prescribed process. I'm open to other suggestions=
 as long as they account for the deep dependency this protocol has on clien=
t type identification.
>=20
> EH
>=20
>=20
>=20
>> -----Original Message-----
>> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
>> Sent: Wednesday, March 14, 2012 11:42 AM
>> To: Eran Hammer; Marius Scurtescu
>> Cc: Breno de Medeiros; OAuth WG
>> Subject: RE: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>=20
>> All of Marius, Breno, Nat, myself, and several others on the OpenID AB l=
ist
>> have read it this way.  I believe that either this change needs to be re=
moved
>> (my preference!) or a sentence needs to be explicitly added that states =
that
>> "The same client_id MAY be used with both the code and token response
>> types"  to explicitly rule out this apparently common misinterpretation =
of the
>> new text.
>>=20
>> Otherwise, I agree that it will continue to be perceived by most people =
as a
>> breaking change.
>>=20
>> 				-- Mike
>>=20
>> P.S.  When you make this change, you should also correct the typo in thi=
s
>> sentence: "The authorization server MAY provider tools to manage such
>> complex clients through a single administration interface" by changing
>> "provider" to "provide".
>>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Eran Hammer
>> Sent: Wednesday, March 14, 2012 11:35 AM
>> To: Marius Scurtescu
>> Cc: Breno de Medeiros; OAuth WG
>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>=20
>> You are not reading it correctly.
>>=20
>> This is a *registration* requirement, meaning, the client has to inform =
the
>> server of the different components. If the server doesn't care, it can i=
ssue
>> one client identifier capable of both.
>>=20
>> This protocol assume the authorization server asked the client for its t=
ype
>> and based on that made decisions about the credentials issued and the
>> security properties of the client. It is also triggers a whole list of n=
ormative
>> language handling the different client types throughout the specificatio=
n.
>>=20
>> EH
>>=20
>>> -----Original Message-----
>>> From: Marius Scurtescu [mailto:mscurtescu@google.com]
>>> Sent: Wednesday, March 14, 2012 11:24 AM
>>> To: Eran Hammer
>>> Cc: Breno de Medeiros; OAuth WG
>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>>=20
>>> Before v23 a web server client could use either response_type=3Dcode or
>>> response_type=3Dtoken, with the same client id. No security issues and
>>> this was supported for quite a while.
>>>=20
>>> With this latest change, if I am reading it correctly, this is not
>>> possible anymore. The client has to use two different client ids. It
>>> is very late in the game to introduce changes like this, unless there
>>> is an extremely good reason.
>>>=20
>>> Marius
>>>=20
>>>=20
>>>=20
>>> On Wed, Mar 14, 2012 at 11:09 AM, Eran Hammer 
>>> wrote:
>>>> If the server locks a client type to a particular grant type (or
>>>> response type)
>>> then this is true, you don't need to specify the response type in the
>> request.
>>> But this is based on a very limited set of potential response types. I
>>> can envision a code response type with different response syntax but
>>> same security properties, and same goes for token.
>>>>=20
>>>> In the past, a cookie response type was proposed to use the cookie
>>> headers in the server response instead of returning a token. The
>>> security properties of such a flow are very similar to those of token
>>> (from OAuth's perspective). This means a public client would be able
>>> to request either token or cookie response type.
>>>>=20
>>>> Also as noted, servers are allowed to provide different registration
>>>> options
>>> to clients, as long as the client identifies each discrete component.
>>> There is no requirement or even suggestion that the server issues
>>> different client identifiers to such complex clients. I think this is
>>> another point missed in your reading of the text.
>>>>=20
>>>> Hope this clarifies it.
>>>>=20
>>>> EH
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Breno de Medeiros [mailto:breno@google.com]
>>>>> Sent: Wednesday, March 14, 2012 10:16 AM
>>>>> To: Eran Hammer
>>>>> Cc: Marius Scurtescu; OAuth WG
>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>>>>=20
>>>>> Can you explain to me why response_type is necessary at all after
>>>>> this change.
>>>>>=20
>>>>> If a javascript client (candidate for token usage) and the web
>>>>> server component (candidate for code usage) cannot share
>>>>> registration (since they are different components with different
>>>>> security contexts of the same
>>>>> application) then there is no need to specify response_type. The
>>>>> server can infer the response type from the client and its security
>> context.
>>>>>=20
>>>>> My objection has nothing to do with code+token flow. I think the
>>>>> change makes response_types irrelevant and is essentially a new
>>> protocol.
>>>>>=20
>>>>> As far as I understand it, the introduction of different code and
>>>>> token flows was precisely to allow different security-context
>>>>> components of the same client to securely operate under the same
>>>>> registration. I think if we change this we need to specify a lot
>>>>> more behavior, such as how a client can request authorization on
>>>>> behalf of
>>> several components simultaneously.
>>>>>=20
>>>>> On Wed, Mar 14, 2012 at 10:08, Eran Hammer 
>>>>> wrote:
>>>>>> This was already raised and addressed on this list last week.
>>>>>>=20
>>>>>> When someone defines and registers code+token, that specification
>>>>>> must
>>>>> define how such a client is registered in light of the text below.
>>>>> This might mean defining a new client type, choosing the
>>>>> confidential client type with other normative text limiting the use
>>>>> of the secret in the public component, etc.
>>>>>>=20
>>>>>> IOW, this section doesn't break anything because there is nothing
>>>>>> else
>>>>> defined to break. There is no way to avoid explicitly defining
>>>>> these requirements for a code+token response type, or any other new
>>>>> response type for that matter. The text below is required to ensure
>>>>> that the authorization server can properly enforce the rest of the
>>>>> normative security language in the specification.
>>>>>>=20
>>>>>> EH
>>>>>>=20
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>>>> Behalf Of Marius Scurtescu
>>>>>>> Sent: Wednesday, March 14, 2012 9:53 AM
>>>>>>> To: OAuth WG
>>>>>>> Cc: Breno de Medeiros
>>>>>>> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> Nat Sakimura started a thread on the OpenID Connect list about a
>>>>>>> breaking change introduced by rev 2.3
>>>>>>>=20
>>>>>>> The paragraph in question is in section 2.1:
>>>>>>>=20
>>>>>>> "A client application consisting of multiple components, each
>>>>>>> with its own client type (e.g. a distributed client with both a
>>>>>>> confidential server-based component and a public browser-based
>>>>>>> component), MUST register each component separately as a
>>>>>>> different client to ensure proper handling by the authorization
>>>>>>> server.  The authorization server MAY provider tools to manage
>>>>>>> such complex clients
>>>>> through a single administration interface."
>>>>>>>=20
>>>>>>> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf=
-
>>>>>>> oa
>>>>>>> uth
>>>>>>> -v2-
>>>>>>> 23.txt
>>>>>>>=20
>>>>>>> You can see the thread here:
>>>>>>> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-
>>>>>>> 20120312/001672.html
>>>>>>>=20
>>>>>>> This paragraph basically prevents response_type=3Dcode+token which
>>>>>>> is already implemented by many providers and also relied on by
>>>>>>> OpenID Connect.
>>>>>>>=20
>>>>>>> The intent, I think, was to prevent clients from embedding the
>>>>>>> client secret meant for a confidential client into a public client.
>>>>>>> JavaScript based clients using the token flow do not need the
>>>>>>> client secret, so this concern does not apply.
>>>>>>>=20
>>>>>>> Thoughts?
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>> Marius
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> --
>>>>> --Breno
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From breno@google.com  Wed Mar 14 13:13:21 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC4621E8019 for ; Wed, 14 Mar 2012 13:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.377
X-Spam-Level: 
X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Shg2Q065-Hk9 for ; Wed, 14 Mar 2012 13:13:20 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E60CD21E800E for ; Wed, 14 Mar 2012 13:13:19 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so2564261ggm.31 for ; Wed, 14 Mar 2012 13:13:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=kR3RK5ak+KE/hlvpyzCf/kouyUYHBA5pDD+7HBJ+wz8=; b=FrNk42/Q0RKs+U2Np5aX1Jp4p48qpTtfYUBHpqMKt9Q0eEJ9SucaFjzLUUWpgUt2l2 u6b4y8R6Otg9DCMKE1BwoQed20+37v/seZXtNjNoPH/Qct2J8h+KEvAKA1NDPbudsXnB 89In+eW2NAlPypEx8Vyty7QLXTkheZQzos6mv1vyxgoMf8KYz4gs+M6JSMk4xUyUn4lF 1h0s1eSwSe4KxCrwUkyEwCTa3xIo4BH0w/CL5Ftom25tql0bA+l1DRU1Yy223lpw71g2 KA9C728aun/r/Vxy1bYv+6Aj8IXDzt8xTxg0fEERyAfLwyZGtyfTejm5LF4WCk9dtDTG zW9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=kR3RK5ak+KE/hlvpyzCf/kouyUYHBA5pDD+7HBJ+wz8=; b=OTvZm4guwPrv3fpU74x/+OmclK/eJN/ldR0qfVTzeOnJvaXb8D0yU8CqkEB68wPCTn T62NudTZcr/Bg4Esh2loNiZRlhpJv5xRJCJZ8t3zstIAEQGoQhYzWSy39dWQ3m+YhmPt xAQRYB5Y0nldrBiUXlNyzqxTzoQE3S2EsTfW3rRy3SRG2oEzpXehBSG4ceF+gptdm+lP NrbmampGJAp96Ux/cBY5wCHCUAieZMnR8Sg4z5uVWmHqMibiQHE8ZuM1plEyVsGGJk5U U8q8U8JYOiA25kD1G3cup3CL5NxySFsyZqScAWN0gT9niRMqUTn9QZI6Y/RuU6AdtM8/ 2sVA==
Received: by 10.229.136.84 with SMTP id q20mr1333912qct.59.1331755999403; Wed, 14 Mar 2012 13:13:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.136.84 with SMTP id q20mr1333902qct.59.1331755999229; Wed, 14 Mar 2012 13:13:19 -0700 (PDT)
Received: by 10.229.48.140 with HTTP; Wed, 14 Mar 2012 13:13:18 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 14 Mar 2012 13:13:18 -0700
Message-ID: 
From: Breno de Medeiros 
To: Eran Hammer 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQm4E2ONM8mbw07iFn9e1B437/ALwAeACVf4jIgh0aSQw3oZff0wz5iuGTf7TOwpdLearGkzUxvsq4+wAuI0qBfGcLl7KK/JPqfsNilIpMId+JR6DlGcEF7wjfrjJ/LKLBVxNvoy
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:13:21 -0000

On Wed, Mar 14, 2012 at 12:23, Eran Hammer  wrote:
> Let's take a step back for a second.
>
> Previous versions of this document stated that during the registration pr=
ocess the client developer specifies the client type as described in 2.1. T=
his has been specified under "registration requirements" since -17 publishe=
d July 8th 2011. The only two types provided were (and still are) public an=
d confidential.
>
> While there was no MUST or SHALL directive, the text was pretty clear abo=
ut the need for each client registration to be tied to a single client type=
.

I disagree with this. The spec supplies two response_types explicitly
to deal with a single registration (single client_id) that can operate
in different security contexts, and provides means for this to
securely do so. The security considerations of the spec was previously
written in a consistent form.

This language is not consistent with that.

As an specific example, our server implementation is compliant with
the previous approach but not with the new one. Moreover, the current
writing of this section leaves unspecified how servers can be made
compliant if they support both token and code flows (if they only
support one flow type, then clearly this is a non-issue).

I am sorry, but with this language this is a different spec with
different compliance profiles and without supplying enough guidance
for creating interoperable server implementations for common
deployment models.

>
> -23 was an attempt to clarify this, by making it explicit that hybrid cli=
ents are not addressed by the specification, and have to be dealt with as t=
wo separate clients.
>
> The specification breaks if a client has more than one type. The authoriz=
ation server cannot enforce some of the security requirements if the client=
 type is unknown. This is all based on how the specification is written and=
 how the security consideration section is structured.
>
> The real issue raised here is how to handle hybrid clients which are beyo=
nd the scope of this specification.
>
> Here is an alternative text:
>
> =A0 A client application consisting of multiple components, each with its
> =A0 own client type (e.g. a distributed client with both a confidential
> =A0 server-based component and a public browser-based component), MUST
> =A0 register each component separately as a different client to ensure
> =A0 proper handling by the authorization server, unless the authorization
> =A0 server provides other registration options to specify such complex cl=
ients.
>
> It's basically saying that unless the authorization server provides a spe=
cial option other than 'public' and 'confidential', clients MUST register s=
uch applications separately for each component. It leaves the decision of h=
ow to deal with such clients completely up to the authorization server duri=
ng the registration process.
>
> I think we should also add a SHALL in section 2: "When registering a clie=
nt, the client developer SHALL:", which is implicit already.
>
> Another, less desirable alternative is to remove this section and add:
>
> =A0 The authorization server MAY provide the client with other client typ=
es
> =A0 options during the registration process. Such client types are beyond=
 the
> =A0 scope of this specification. Such additional client types will requir=
e a
> =A0 different set of security considerations not provided by this specifi=
cation.
>
> My intention was never to introduce a (breaking) change here, just to cla=
rify what was already the prescribed process. I'm open to other suggestions=
 as long as they account for the deep dependency this protocol has on clien=
t type identification.
>
> EH
>
>
>
>> -----Original Message-----
>> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
>> Sent: Wednesday, March 14, 2012 11:42 AM
>> To: Eran Hammer; Marius Scurtescu
>> Cc: Breno de Medeiros; OAuth WG
>> Subject: RE: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>
>> All of Marius, Breno, Nat, myself, and several others on the OpenID AB l=
ist
>> have read it this way. =A0I believe that either this change needs to be =
removed
>> (my preference!) or a sentence needs to be explicitly added that states =
that
>> "The same client_id MAY be used with both the code and token response
>> types" =A0to explicitly rule out this apparently common misinterpretatio=
n of the
>> new text.
>>
>> Otherwise, I agree that it will continue to be perceived by most people =
as a
>> breaking change.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike
>>
>> P.S. =A0When you make this change, you should also correct the typo in t=
his
>> sentence: "The authorization server MAY provider tools to manage such
>> complex clients through a single administration interface" by changing
>> "provider" to "provide".
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Eran Hammer
>> Sent: Wednesday, March 14, 2012 11:35 AM
>> To: Marius Scurtescu
>> Cc: Breno de Medeiros; OAuth WG
>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>
>> You are not reading it correctly.
>>
>> This is a *registration* requirement, meaning, the client has to inform =
the
>> server of the different components. If the server doesn't care, it can i=
ssue
>> one client identifier capable of both.
>>
>> This protocol assume the authorization server asked the client for its t=
ype
>> and based on that made decisions about the credentials issued and the
>> security properties of the client. It is also triggers a whole list of n=
ormative
>> language handling the different client types throughout the specificatio=
n.
>>
>> EH
>>
>> > -----Original Message-----
>> > From: Marius Scurtescu [mailto:mscurtescu@google.com]
>> > Sent: Wednesday, March 14, 2012 11:24 AM
>> > To: Eran Hammer
>> > Cc: Breno de Medeiros; OAuth WG
>> > Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>> >
>> > Before v23 a web server client could use either response_type=3Dcode o=
r
>> > response_type=3Dtoken, with the same client id. No security issues and
>> > this was supported for quite a while.
>> >
>> > With this latest change, if I am reading it correctly, this is not
>> > possible anymore. The client has to use two different client ids. It
>> > is very late in the game to introduce changes like this, unless there
>> > is an extremely good reason.
>> >
>> > Marius
>> >
>> >
>> >
>> > On Wed, Mar 14, 2012 at 11:09 AM, Eran Hammer 
>> > wrote:
>> > > If the server locks a client type to a particular grant type (or
>> > > response type)
>> > then this is true, you don't need to specify the response type in the
>> request.
>> > But this is based on a very limited set of potential response types. I
>> > can envision a code response type with different response syntax but
>> > same security properties, and same goes for token.
>> > >
>> > > In the past, a cookie response type was proposed to use the cookie
>> > headers in the server response instead of returning a token. The
>> > security properties of such a flow are very similar to those of token
>> > (from OAuth's perspective). This means a public client would be able
>> > to request either token or cookie response type.
>> > >
>> > > Also as noted, servers are allowed to provide different registration
>> > > options
>> > to clients, as long as the client identifies each discrete component.
>> > There is no requirement or even suggestion that the server issues
>> > different client identifiers to such complex clients. I think this is
>> > another point missed in your reading of the text.
>> > >
>> > > Hope this clarifies it.
>> > >
>> > > EH
>> > >
>> > >> -----Original Message-----
>> > >> From: Breno de Medeiros [mailto:breno@google.com]
>> > >> Sent: Wednesday, March 14, 2012 10:16 AM
>> > >> To: Eran Hammer
>> > >> Cc: Marius Scurtescu; OAuth WG
>> > >> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>> > >>
>> > >> Can you explain to me why response_type is necessary at all after
>> > >> this change.
>> > >>
>> > >> If a javascript client (candidate for token usage) and the web
>> > >> server component (candidate for code usage) cannot share
>> > >> registration (since they are different components with different
>> > >> security contexts of the same
>> > >> application) then there is no need to specify response_type. The
>> > >> server can infer the response type from the client and its security
>> context.
>> > >>
>> > >> My objection has nothing to do with code+token flow. I think the
>> > >> change makes response_types irrelevant and is essentially a new
>> > protocol.
>> > >>
>> > >> As far as I understand it, the introduction of different code and
>> > >> token flows was precisely to allow different security-context
>> > >> components of the same client to securely operate under the same
>> > >> registration. I think if we change this we need to specify a lot
>> > >> more behavior, such as how a client can request authorization on
>> > >> behalf of
>> > several components simultaneously.
>> > >>
>> > >> On Wed, Mar 14, 2012 at 10:08, Eran Hammer 
>> > >> wrote:
>> > >> > This was already raised and addressed on this list last week.
>> > >> >
>> > >> > When someone defines and registers code+token, that specification
>> > >> > must
>> > >> define how such a client is registered in light of the text below.
>> > >> This might mean defining a new client type, choosing the
>> > >> confidential client type with other normative text limiting the use
>> > >> of the secret in the public component, etc.
>> > >> >
>> > >> > IOW, this section doesn't break anything because there is nothing
>> > >> > else
>> > >> defined to break. There is no way to avoid explicitly defining
>> > >> these requirements for a code+token response type, or any other new
>> > >> response type for that matter. The text below is required to ensure
>> > >> that the authorization server can properly enforce the rest of the
>> > >> normative security language in the specification.
>> > >> >
>> > >> > EH
>> > >> >
>> > >> >
>> > >> >> -----Original Message-----
>> > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>> > >> >> Behalf Of Marius Scurtescu
>> > >> >> Sent: Wednesday, March 14, 2012 9:53 AM
>> > >> >> To: OAuth WG
>> > >> >> Cc: Breno de Medeiros
>> > >> >> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>> > >> >>
>> > >> >> Hi,
>> > >> >>
>> > >> >> Nat Sakimura started a thread on the OpenID Connect list about a
>> > >> >> breaking change introduced by rev 2.3
>> > >> >>
>> > >> >> The paragraph in question is in section 2.1:
>> > >> >>
>> > >> >> "A client application consisting of multiple components, each
>> > >> >> with its own client type (e.g. a distributed client with both a
>> > >> >> confidential server-based component and a public browser-based
>> > >> >> component), MUST register each component separately as a
>> > >> >> different client to ensure proper handling by the authorization
>> > >> >> server. =A0The authorization server MAY provider tools to manage
>> > >> >> such complex clients
>> > >> through a single administration interface."
>> > >> >>
>> > >> >> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-i=
etf-
>> > >> >> oa
>> > >> >> uth
>> > >> >> -v2-
>> > >> >> 23.txt
>> > >> >>
>> > >> >> You can see the thread here:
>> > >> >> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-
>> > >> >> 20120312/001672.html
>> > >> >>
>> > >> >> This paragraph basically prevents response_type=3Dcode+token whi=
ch
>> > >> >> is already implemented by many providers and also relied on by
>> > >> >> OpenID Connect.
>> > >> >>
>> > >> >> The intent, I think, was to prevent clients from embedding the
>> > >> >> client secret meant for a confidential client into a public clie=
nt.
>> > >> >> JavaScript based clients using the token flow do not need the
>> > >> >> client secret, so this concern does not apply.
>> > >> >>
>> > >> >> Thoughts?
>> > >> >>
>> > >> >> Thanks,
>> > >> >> Marius
>> > >> >> _______________________________________________
>> > >> >> OAuth mailing list
>> > >> >> OAuth@ietf.org
>> > >> >> https://www.ietf.org/mailman/listinfo/oauth
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> --Breno
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>



--=20
--Breno

From hannes.tschofenig@gmx.net  Wed Mar 14 13:15:04 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236E421F8593 for ; Wed, 14 Mar 2012 13:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level: 
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edQcBvRBF1Fj for ; Wed, 14 Mar 2012 13:15:03 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 129EA21F8599 for ; Wed, 14 Mar 2012 13:15:02 -0700 (PDT)
Received: (qmail invoked by alias); 14 Mar 2012 20:14:56 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp024) with SMTP; 14 Mar 2012 21:14:56 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18Vi3sqH4EVK7xpqjMiACJeIkvclT7zlhN3IES/lP VSFYsqPVXiHaE1
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 14 Mar 2012 22:14:55 +0200
Message-Id: <30401997-7A6A-4306-B909-2EEAE80AA90D@gmx.net>
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:15:04 -0000

Feedback appreciated!

Web Authorization Protocol WG 
=============================

THURSDAY, March 29, 2012
1300-1500 Afternoon Session I 

Room: 252A

Chairs: Hannes Tschofenig & Derek Atkins

1. Agenda Bashing, WG Status 
(+ Welcome Derek and Thank You Barry)

2. OAuth Threats Document (Torsten)
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/

3. OAuth Assertions (Mike)
https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns/

4. MAC Token (TBD)
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/

5. Re-charter finalization (all)

See mail sent separately to the mailing list. 




From barryleiba.mailing.lists@gmail.com  Wed Mar 14 13:19:39 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1BF21F8744 for ; Wed, 14 Mar 2012 13:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.984
X-Spam-Level: 
X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihDRlk0e8Mvg for ; Wed, 14 Mar 2012 13:19:39 -0700 (PDT)
Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3790921F8733 for ; Wed, 14 Mar 2012 13:19:39 -0700 (PDT)
Received: by yhgm50 with SMTP id m50so3381237yhg.27 for ; Wed, 14 Mar 2012 13:19:38 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=iifEKnuZW494cYdyMXCfJesFUAWRCFXcSrh/4RVWEAk=; b=OzQQmq9I6c9Jnd/raxQsHLL7US9eIFZMOf/XPndSeoNuf1Qs8a+3vbDi44OVc9Tu50 MlMg6lwMu3gCjqRttF+VIwE/38/cLU63ELUqf9r0e7DvvwE9MnY6+fLKMNN5phIBRNqP gNrkBQ2HlpXOkDIqytBa4dteA6hEPult+RLTUh2ii+R1UHfy9o3Vd7BGSNnv0oL5yEC+ b0Oc+uuxJhMGNE4qf7wRwCo/fYFFXWt+dSywpQ4J1hgRpWt4aRGPivYfG6+yXz3StPoe DJZMBsbHf4rwk/BKT2VCT9OFGHR37FSatyEkBA0zeJ4fgJ9dYHgNWhrWvWqm5+bAUO2m oPvQ==
MIME-Version: 1.0
Received: by 10.236.181.66 with SMTP id k42mr2234530yhm.55.1331756378837; Wed, 14 Mar 2012 13:19:38 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.106.16 with HTTP; Wed, 14 Mar 2012 13:19:38 -0700 (PDT)
In-Reply-To: 
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
Date: Wed, 14 Mar 2012 16:19:38 -0400
X-Google-Sender-Auth: 9XnlVjHo2xQD7ooqgdkFCyVTU3I
Message-ID: 
From: Barry Leiba 
To: OAuth WG 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:19:39 -0000

> I am sorry, but with this language this is a different spec with
> different compliance profiles and without supplying enough guidance
> for creating interoperable server implementations for common
> deployment models.

As I read this thread, I see two things come out clearly:

1. Eran didn't intend to make the change that some read into this, and

2. enough people interpret this as a change that Eran didn't intend
that it's worth fixing.

Everyone agrees on how it should be -- right?  So let's not worry
about whether the text is or isn't confusing, and instead focus on a
small change to the text that will keep the meaning that's intended
and that takes the confusion away from those who think something
drastic has changed.  That should be easy to do, and quick and
non-controversial to wrap up.

Barry

From hannes.tschofenig@gmx.net  Wed Mar 14 13:21:22 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CFA21F8772 for ; Wed, 14 Mar 2012 13:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level: 
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktjZR7Kma13q for ; Wed, 14 Mar 2012 13:21:18 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id F14D021F8767 for ; Wed, 14 Mar 2012 13:21:17 -0700 (PDT)
Received: (qmail invoked by alias); 14 Mar 2012 20:21:16 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp020) with SMTP; 14 Mar 2012 21:21:16 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+5/TBQy5255XIO5sngFRfd5gu4+97o4scqT+H0+n L9cBsNR6NAvxt/
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Mar 2012 22:21:15 +0200
Message-Id: 
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:21:22 -0000

So, here is a proposal:

-------

Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user=20
sharing his or her photo-sharing sites' long-term credential with the=20
printing site.=20

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server,=20
* a protocol for obtaining authorization tokens from an authorization=20
server with the resource owner's consent,=20
* protocols for presenting these authorization tokens to protected=20
resources for access to a resource, and=20
* consequently for sharing data in a security and privacy respective =
way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the=20
completion of OAuth 1.0 the working group started their work on OAuth =
2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the =
result=20
is available as a stand-alone document offering guidance for audiences=20=

beyond the community of protocol implementers.

The working group also developed security schemes for presenting =
authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access=20=

authentication specification.=20

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH =
token with=20
the SAML 2.0 bearer assertion profile.  This offers interworking with =
existing=20
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application =
service provider=20
community. To build on this success we aim for nothing more than to make =
OAuth the=20
authorization framework of choice for any Internet protocol. =
Consequently, the=20
ongoing standardization effort within the OAuth working group is focused =
on=20
enhancing interoperability of OAuth deployments. While the core OAuth =
specification=20
truly is an important building block it relies on other specifications =
in order to=20
claim completeness. Luckily, these components already exist and have =
been deployed=20
on the Internet. Through the IETF standards process they will be =
improved in=20
quality and will undergo a rigorous review process.=20

Goals and Milestones

[Editor's Note: Here are the completed items.]=20

Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a =
working group item
Done 	Submit 'HTTP Authentication: MAC Authentication' as a working =
group item
Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for =
consideration as a Proposed Standard
Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for =
consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates =
- are they realistic?]=20

Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the =
IESG for consideration as a Proposed Standard
Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth =
2.0' to the IESG for consideration as a Proposed Standard
Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for =
consideration as a Proposed Standard=20
Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for =
consideration as a Proposed Standard=20
May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' =
to the IESG for consideration as an Informational RFC

[Editor's Note: New work for the group. 5 items maximum! ]

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as =
a Proposed Standard

[Starting point for the work will be =
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration =
as a Proposed Standard

[Starting point for the work will be =
http://tools.ietf.org/html/draft-jones-json-web-token]

Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for =
OAuth 2.0' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be =
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the =
IESG for consideration as a Proposed Standard

[Starting point for the work will be =
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]=20

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as =
an Informational RFC

[Starting point for the work will be =
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]=20




From barryleiba.mailing.lists@gmail.com  Wed Mar 14 13:23:08 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C73121F8794 for ; Wed, 14 Mar 2012 13:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.984
X-Spam-Level: 
X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMj-v2wsMEEi for ; Wed, 14 Mar 2012 13:23:07 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E11621F8790 for ; Wed, 14 Mar 2012 13:23:07 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so2572981ghb.31 for ; Wed, 14 Mar 2012 13:23:07 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RkTUcEXWoZWU4Mvf190hAmwap7Ey0aaTh88NpzAuRDs=; b=MdgEkEYgY6GttNrxDUBFDNI+cyzRYwuZeE4O0kh2LJOrDn9T+2XvlyOYJfA3pehbpT BxZ2mRtPjj/I6zLSN3xI+hpSZUKqGmnDGOHEh2v+TDVE3ZuYD3wpkjhGZ+K4RS9Q/lle CPNjUngxry12Ij/CAuDAT+pPxEt2ls+C8QbpfA9kfg4dGWPLFIURCHVB0VkmOD7gCbfQ JwfZSVUJPmA3hm2xOPLk/KFvvEXUxLjxwaSds6FdqSLvJqcjaQFEuiZoa6d+PH0aWj+b pdDc0YOhyC4KvudwZNn3zqlHktadKt8SA+MgoQnqmHnNPoDG34XB21mCg7gvdh1/AXIL 18TA==
MIME-Version: 1.0
Received: by 10.236.181.66 with SMTP id k42mr2247940yhm.55.1331756586977; Wed, 14 Mar 2012 13:23:06 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.106.16 with HTTP; Wed, 14 Mar 2012 13:23:06 -0700 (PDT)
In-Reply-To: <30401997-7A6A-4306-B909-2EEAE80AA90D@gmx.net>
References: <30401997-7A6A-4306-B909-2EEAE80AA90D@gmx.net>
Date: Wed, 14 Mar 2012 16:23:06 -0400
X-Google-Sender-Auth: 5kAohYp1vnQQw8x89dd4Pbgr7PI
Message-ID: 
From: Barry Leiba 
To: Hannes Tschofenig 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:23:08 -0000

Looks good to me.  One note:

> 2. OAuth Threats Document (Torsten)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/

I have been terribly remiss on this, so here's the thing:

- We have completed WGLC on this, and are awaiting my shepherd review
(which will include a recommendation for the remaining unresolved
issue).

- I will do this before I leave chairdom and head into the abyss that
is the IESG.

- Torsten, please let me know if there's anything outstanding that you
have to do; else it's all waiting for my action.

Unless I've missed something, this agenda item should be brief indeed.

Barry, two more weeks

From barryleiba.mailing.lists@gmail.com  Wed Mar 14 13:24:42 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0645621F8823 for ; Wed, 14 Mar 2012 13:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.984
X-Spam-Level: 
X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpltphJCtYze for ; Wed, 14 Mar 2012 13:24:41 -0700 (PDT)
Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFC221F8767 for ; Wed, 14 Mar 2012 13:24:40 -0700 (PDT)
Received: by yhgm50 with SMTP id m50so3389500yhg.27 for ; Wed, 14 Mar 2012 13:24:40 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3LCFj4AxpZRXU1JC98fW82HfrxbQJiQHYwY1tHI5KKI=; b=ooFMJKn9pvj5bXaJ6pXV104MUUIZwJrfnO68Wz4xV4mvS5V+YebqhlENRUXbp9yeqp FiN5MTZu3gtQekc5lsk3yxvjbTqeRq2PZmbGWyG0HLlBiAJog1rEgj9DmAAMHwT0srkA U+oE1Am0Z2W8yejVuA3cXbXY6JniY7EVg7MYcQNivoR3FJcgrmssXAN3QC3amhBe3d+d 1y38Lqz21Yp/Ga2HxpG+Tsot3+ipqDXGs7SHRMiV5+AVb/iiDIOgYHF7ok48ecxBJySJ oFNvJs15GuOpiAnKcL7m0SrB50s6XICLBwOLke0JcJHnKoi1j/NKFugE1f+RyN0JWYiI qETg==
MIME-Version: 1.0
Received: by 10.236.181.66 with SMTP id k42mr2254103yhm.55.1331756680295; Wed, 14 Mar 2012 13:24:40 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.106.16 with HTTP; Wed, 14 Mar 2012 13:24:40 -0700 (PDT)
In-Reply-To: <30401997-7A6A-4306-B909-2EEAE80AA90D@gmx.net>
References: <30401997-7A6A-4306-B909-2EEAE80AA90D@gmx.net>
Date: Wed, 14 Mar 2012 16:24:40 -0400
X-Google-Sender-Auth: XKWFf1sdRGP_fydpc6il4xWBf78
Message-ID: 
From: Barry Leiba 
To: Hannes Tschofenig 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:24:42 -0000

Oh, and...

> 4. MAC Token (TBD)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/

I believe that in Eran's last communication about this he said that he
does, after all, have the time and inclination to finish it, and would
like to.

b

From igor.faynberg@alcatel-lucent.com  Wed Mar 14 13:26:10 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3265221F8828 for ; Wed, 14 Mar 2012 13:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.549
X-Spam-Level: 
X-Spam-Status: No, score=-9.549 tagged_above=-999 required=5 tests=[AWL=1.050,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msB3+8REsBVD for ; Wed, 14 Mar 2012 13:26:09 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2467C21F8826 for ; Wed, 14 Mar 2012 13:26:08 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2EKQ8Qw007743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Mar 2012 15:26:08 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2EKQ7xs008465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 14 Mar 2012 15:26:08 -0500
Received: from [135.222.134.168] (USMUYN0L055118.mh.lucent.com [135.222.134.168]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2EKQ7Z0029122; Wed, 14 Mar 2012 15:26:07 -0500 (CDT)
Message-ID: <4F60FEDF.1030600@alcatel-lucent.com>
Date: Wed, 14 Mar 2012 16:26:07 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: oauth@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:26:10 -0000

Looks good and comprehensive to me.

Igor

On 3/14/2012 4:21 PM, Hannes Tschofenig wrote:
> So, here is a proposal:
>
> -------
>
> Web Authorization Protocol (oauth)
>
> Description of Working Group
>
> The Web Authorization (OAuth) protocol allows a user to grant
> a third-party Web site or application access to the user's protected
> resources, without necessarily revealing their long-term credentials,
> or even their identity. For example, a photo-sharing site that supports
> OAuth could allow its users to use a third-party printing Web site to
> print their private pictures, without allowing the printing site to
> gain full control of the user's account and without having the user
> sharing his or her photo-sharing sites' long-term credential with the
> printing site.
>
> The OAuth protocol suite encompasses
> * a procedure for allowing a client to discover a resource server,
> * a protocol for obtaining authorization tokens from an authorization
> server with the resource owner's consent,
> * protocols for presenting these authorization tokens to protected
> resources for access to a resource, and
> * consequently for sharing data in a security and privacy respective way.
>
> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
> was published as an informational document (RFC 5849). With the
> completion of OAuth 1.0 the working group started their work on OAuth 2.0
> to incorporate implementation experience with version 1.0, additional
> use cases, and various other security, readability, and interoperability
> improvements. An extensive security analysis was conducted and the result
> is available as a stand-alone document offering guidance for audiences
> beyond the community of protocol implementers.
>
> The working group also developed security schemes for presenting authorization
> tokens to access a protected resource. This led to the publication of
> the bearer token as well as the message authentication code (MAC) access
> authentication specification.
>
> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with
> the SAML 2.0 bearer assertion profile.  This offers interworking with existing
> identity management solutions, in particular SAML based deployments.
>
> OAuth has enjoyed widespread adoption by the Internet application service provider
> community. To build on this success we aim for nothing more than to make OAuth the
> authorization framework of choice for any Internet protocol. Consequently, the
> ongoing standardization effort within the OAuth working group is focused on
> enhancing interoperability of OAuth deployments. While the core OAuth specification
> truly is an important building block it relies on other specifications in order to
> claim completeness. Luckily, these components already exist and have been deployed
> on the Internet. Through the IETF standards process they will be improved in
> quality and will undergo a rigorous review process.
>
> Goals and Milestones
>
> [Editor's Note: Here are the completed items.]
>
> Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item
> Done 	Submit 'HTTP Authentication: MAC Authentication' as a working group item
> Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard
> Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard
>
> [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?]
>
> Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard
> Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard
> Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard
> May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC
>
> [Editor's Note: New work for the group. 5 items maximum! ]
>
> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard
>
> [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
>
> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]
>
> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
>
> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
>
> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From eran@hueniverse.com  Wed Mar 14 13:36:52 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF28E21F884B for ; Wed, 14 Mar 2012 13:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level: 
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dakcemGHmMf for ; Wed, 14 Mar 2012 13:36:52 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 7DFFE21F87EA for ; Wed, 14 Mar 2012 13:36:51 -0700 (PDT)
Received: (qmail 6857 invoked from network); 14 Mar 2012 20:36:50 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Mar 2012 20:36:50 -0000
Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id lYaK1i00110TkE001YaMve; Wed, 14 Mar 2012 13:34:21 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 14 Mar 2012 13:33:42 -0700
From: Eran Hammer 
To: Hannes Tschofenig , "oauth@ietf.org WG" 
Date: Wed, 14 Mar 2012 13:33:34 -0700
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: Ac0CIBOaEwVZ+8xDSkqk1Y4wRm5yvwAAUk8A
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08971@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:36:52 -0000

Looks great!

Not sure if 'JSON Web Token (JWT)' belongs on this list, but not a big prob=
lem.

EH


> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Hannes Tschofenig
> Sent: Wednesday, March 14, 2012 1:21 PM
> To: oauth@ietf.org WG
> Subject: [OAUTH-WG] OAuth WG Re-Chartering
>=20
> So, here is a proposal:
>=20
> -------
>=20
> Web Authorization Protocol (oauth)
>=20
> Description of Working Group
>=20
> The Web Authorization (OAuth) protocol allows a user to grant
> a third-party Web site or application access to the user's protected
> resources, without necessarily revealing their long-term credentials,
> or even their identity. For example, a photo-sharing site that supports
> OAuth could allow its users to use a third-party printing Web site to
> print their private pictures, without allowing the printing site to
> gain full control of the user's account and without having the user
> sharing his or her photo-sharing sites' long-term credential with the
> printing site.
>=20
> The OAuth protocol suite encompasses
> * a procedure for allowing a client to discover a resource server,
> * a protocol for obtaining authorization tokens from an authorization
> server with the resource owner's consent,
> * protocols for presenting these authorization tokens to protected
> resources for access to a resource, and
> * consequently for sharing data in a security and privacy respective way.
>=20
> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
> was published as an informational document (RFC 5849). With the
> completion of OAuth 1.0 the working group started their work on OAuth 2.0
> to incorporate implementation experience with version 1.0, additional
> use cases, and various other security, readability, and interoperability
> improvements. An extensive security analysis was conducted and the result
> is available as a stand-alone document offering guidance for audiences
> beyond the community of protocol implementers.
>=20
> The working group also developed security schemes for presenting
> authorization
> tokens to access a protected resource. This led to the publication of
> the bearer token as well as the message authentication code (MAC) access
> authentication specification.
>=20
> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH
> token with
> the SAML 2.0 bearer assertion profile.  This offers interworking with exi=
sting
> identity management solutions, in particular SAML based deployments.
>=20
> OAuth has enjoyed widespread adoption by the Internet application service
> provider
> community. To build on this success we aim for nothing more than to make
> OAuth the
> authorization framework of choice for any Internet protocol. Consequently=
,
> the
> ongoing standardization effort within the OAuth working group is focused =
on
> enhancing interoperability of OAuth deployments. While the core OAuth
> specification
> truly is an important building block it relies on other specifications in=
 order to
> claim completeness. Luckily, these components already exist and have been
> deployed
> on the Internet. Through the IETF standards process they will be improved=
 in
> quality and will undergo a rigorous review process.
>=20
> Goals and Milestones
>=20
> [Editor's Note: Here are the completed items.]
>=20
> Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a
> working group item
> Done 	Submit 'HTTP Authentication: MAC Authentication' as a working
> group item
> Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for
> consideration as a Proposed Standard
> Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for
> consideration as a Proposed Standard
>=20
> [Editor's Note: Finishing existing work. Double-check the proposed dates =
-
> are they realistic?]
>=20
> Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the
> IESG for consideration as a Proposed Standard
> Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to
> the IESG for consideration as a Proposed Standard
> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for considera=
tion
> as a Proposed Standard
> Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for
> consideration as a Proposed Standard
> May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' t=
o
> the IESG for consideration as an Informational RFC
>=20
> [Editor's Note: New work for the group. 5 items maximum! ]
>=20
> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a
> Proposed Standard
>=20
> [Starting point for the work will be http://datatracker.ietf.org/doc/draf=
t-
> lodderstedt-oauth-revocation/]
>=20
> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration =
as
> a Proposed Standard
>=20
> [Starting point for the work will be http://tools.ietf.org/html/draft-jon=
es-
> json-web-token]
>=20
> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth
> 2.0' to the IESG for consideration as a Proposed Standard
>=20
> [Starting point for the work will be http://tools.ietf.org/html/draft-jon=
es-
> oauth-jwt-bearer]
>=20
> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the I=
ESG
> for consideration as a Proposed Standard
>=20
> [Starting point for the work will be http://tools.ietf.org/html/draft-har=
djono-
> oauth-dynreg]
>=20
> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an
> Informational RFC
>=20
> [Starting point for the work will be http://tools.ietf.org/html/draft-zel=
tsan-
> oauth-use-cases]
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From eran@hueniverse.com  Wed Mar 14 13:44:08 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566EE21F8877 for ; Wed, 14 Mar 2012 13:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98rcMmS9UtjJ for ; Wed, 14 Mar 2012 13:44:07 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id D02FB21F8830 for ; Wed, 14 Mar 2012 13:44:07 -0700 (PDT)
Received: (qmail 13558 invoked from network); 14 Mar 2012 20:44:07 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Mar 2012 20:44:07 -0000
Received: from P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id lYk11i0090SoFT401Yk7EL; Wed, 14 Mar 2012 13:44:07 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 14 Mar 2012 13:29:08 -0700
From: Eran Hammer 
To: Barry Leiba , OAuth WG 
Date: Wed, 14 Mar 2012 13:29:00 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0CH8w+h0BU0mxlTl6CuYP5n5P96gAATnCw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF0896E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:44:08 -0000

I've proposed two alternative languages and open to more. It would be great=
 if people could just reply stating which they like best.

EH

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Barry Leiba
> Sent: Wednesday, March 14, 2012 1:20 PM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>=20
> > I am sorry, but with this language this is a different spec with
> > different compliance profiles and without supplying enough guidance
> > for creating interoperable server implementations for common
> > deployment models.
>=20
> As I read this thread, I see two things come out clearly:
>=20
> 1. Eran didn't intend to make the change that some read into this, and
>=20
> 2. enough people interpret this as a change that Eran didn't intend that =
it's
> worth fixing.
>=20
> Everyone agrees on how it should be -- right?  So let's not worry about
> whether the text is or isn't confusing, and instead focus on a small chan=
ge to
> the text that will keep the meaning that's intended and that takes the
> confusion away from those who think something drastic has changed.  That
> should be easy to do, and quick and non-controversial to wrap up.
>=20
> Barry
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From barryleiba@gmail.com  Wed Mar 14 13:46:22 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E56621F887A for ; Wed, 14 Mar 2012 13:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.984
X-Spam-Level: 
X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtEOXICqpux6 for ; Wed, 14 Mar 2012 13:46:21 -0700 (PDT)
Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id A1D8421F8878 for ; Wed, 14 Mar 2012 13:46:21 -0700 (PDT)
Received: by yhgm50 with SMTP id m50so3424544yhg.27 for ; Wed, 14 Mar 2012 13:46:21 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a20CdALtqJ6tcXMnR/9bAqBosQsICkJEIv39p+RVpO8=; b=BAsgBAYtcIJY1aZb4dq0ojlnECqtaNn5+c8R7DpH1k68h9xp+rRA+NxR0sUKbjEMgC yFonIqv5K0CQTP/FQ+Im7ba8nsglyg8HbXRVz2AzodWn9o4EaAWRZlRc6hSQlxkGdinR RoCFVT2TpOodCIeHjEQBq4WM8KtGId7lMSCXrs3G+Jd3gYhzFemeI41/kWn1CjbORzs8 kc9571UfCsHrzKja//zowGdGRRZJL7vCdX3Kg2/HBINQ33HZ9ksV5Oe2AheHui653Yi6 RGDyiwAVrjNWNeHDhsSDweQ+JDChamdoISF8zuLNX/QsXGvun8dBrMrZ4vGyKPiSjeQi ovig==
MIME-Version: 1.0
Received: by 10.182.225.69 with SMTP id ri5mr4940355obc.74.1331757981125; Wed, 14 Mar 2012 13:46:21 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.60.125.37 with HTTP; Wed, 14 Mar 2012 13:46:21 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF0896E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF0896E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 14 Mar 2012 16:46:21 -0400
X-Google-Sender-Auth: mt5YqUxAd248j8oC3_Tcj52mNyU
Message-ID: 
From: Barry Leiba 
To: Eran Hammer 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:46:22 -0000

Off list.

> It would be great if people could just reply stating which they like best=
.

=D7=9B=D7=9F

Sometimes, one just has to whack people over the head.

b

From barryleiba@gmail.com  Wed Mar 14 13:46:55 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC3021E800C for ; Wed, 14 Mar 2012 13:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.983
X-Spam-Level: 
X-Spam-Status: No, score=-102.983 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqyp0f5rentH for ; Wed, 14 Mar 2012 13:46:50 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31D7121F887B for ; Wed, 14 Mar 2012 13:46:50 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so2603226ggm.31 for ; Wed, 14 Mar 2012 13:46:49 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=kmF5RCQs/ST67mHvTDtmWmScKwHOCIKorOdYrKGYhB4=; b=cRZ3ZpU515zGj41dJuxQ2DOmZiNPLJVFMdJo/Yy5C0IYAek8ocWH4bPXh/axIZ1nwt 3soUw3+U6lSCu+ZeK8ka4h8F+NhkVBvtaIqrbQKfFeGp9c4V8Ezyh/oq/akXDpZzyI7e xSBK1fiq3eGgYHLz7Wtyc4Ht1F9/1Ae8X+nyXRyS5HMwshNteQCzvQJ/qjmt43dUVt7l VH8d+KVIU260s+pLnx+csqFoLVJFy3QlyEvPn6ZaNecKv3JUs5PJnhzcJxgQOrRpYOLp VXp0n2X6ZY3ugl1UfmmhjtIOQWVnKtyoMLQuOGIWmv+wmVGsYOMGctrJtCkY94Nvn7As GDLA==
MIME-Version: 1.0
Received: by 10.60.18.163 with SMTP id x3mr5133215oed.64.1331758009342; Wed, 14 Mar 2012 13:46:49 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.60.125.37 with HTTP; Wed, 14 Mar 2012 13:46:49 -0700 (PDT)
In-Reply-To: 
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF0896E@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
Date: Wed, 14 Mar 2012 16:46:49 -0400
X-Google-Sender-Auth: VDIM9Dex0zNZuZE6tws_ffNC7zg
Message-ID: 
From: Barry Leiba 
To: OAuth WG 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:46:55 -0000

> Off list.

Or not so much off list.  He-he.

b

From Michael.Jones@microsoft.com  Wed Mar 14 13:54:56 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ABC21F879B for ; Wed, 14 Mar 2012 13:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEwuyhvNZCXu for ; Wed, 14 Mar 2012 13:54:55 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id B77AD21F8760 for ; Wed, 14 Mar 2012 13:54:54 -0700 (PDT)
Received: from mail50-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Mar 2012 20:54:55 +0000
Received: from mail50-am1 (localhost [127.0.0.1])	by mail50-am1-R.bigfish.com (Postfix) with ESMTP id E4A722405D6; Wed, 14 Mar 2012 20:54:54 +0000 (UTC)
X-SpamScore: -33
X-BigFish: VS-33(zzbb2dI9371Ic85fh4015I199bRzz1202hzz1033IL8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail50-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail50-am1 (localhost.localdomain [127.0.0.1]) by mail50-am1 (MessageSwitch) id 1331758492916029_17968; Wed, 14 Mar 2012 20:54:52 +0000 (UTC)
Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.237])	by mail50-am1.bigfish.com (Postfix) with ESMTP id D3A9E4E0046; Wed, 14 Mar 2012 20:54:52 +0000 (UTC)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Mar 2012 20:54:50 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0283.004; Wed, 14 Mar 2012 20:54:44 +0000
From: Mike Jones 
To: Hannes Tschofenig , "oauth@ietf.org WG" 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAMCRIf4APwgUm5DSot8V56SZZqRR3K
Date: Wed, 14 Mar 2012 20:54:44 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436641D81ETK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 20:54:56 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436641D81ETK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is missing Simple Web Discovery, which there was substantial support f=
or including during the rechartering discussion in Taipei.  Considering Ope=
nID Connect as a motivating use case for OAuth, SWD is the one spec that wo=
uld then be missing for this OAuth use case.

Please add it to the list.

Thanks,
-- Mike
________________________________
From: Hannes Tschofenig
Sent: 3/14/2012 1:21 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] OAuth WG Re-Chartering

So, here is a proposal:

-------

Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user
sharing his or her photo-sharing sites' long-term credential with the
printing site.

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server,
* a protocol for obtaining authorization tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these authorization tokens to protected
resources for access to a resource, and
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result
is available as a stand-alone document offering guidance for audiences
beyond the community of protocol implementers.

The working group also developed security schemes for presenting authorizat=
ion
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access
authentication specification.

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH toke=
n with
the SAML 2.0 bearer assertion profile.  This offers interworking with exist=
ing
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application service p=
rovider
community. To build on this success we aim for nothing more than to make OA=
uth the
authorization framework of choice for any Internet protocol. Consequently, =
the
ongoing standardization effort within the OAuth working group is focused on
enhancing interoperability of OAuth deployments. While the core OAuth speci=
fication
truly is an important building block it relies on other specifications in o=
rder to
claim completeness. Luckily, these components already exist and have been d=
eployed
on the Internet. Through the IETF standards process they will be improved i=
n
quality and will undergo a rigorous review process.

Goals and Milestones

[Editor's Note: Here are the completed items.]

Done     Submit 'OAuth 2.0 Threat Model and Security Considerations' as a w=
orking group item
Done     Submit 'HTTP Authentication: MAC Authentication' as a working grou=
p item
Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for con=
sideration as a Proposed Standard
Done     Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for cons=
ideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates - =
are they realistic?]

Jun. 2012        Submit 'HTTP Authentication: MAC Authentication' to the IE=
SG for consideration as a Proposed Standard
Apr. 2012        Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' =
to the IESG for consideration as a Proposed Standard
Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for considerati=
on as a Proposed Standard
Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for con=
sideration as a Proposed Standard
May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to =
the IESG for consideration as an Informational RFC

[Editor's Note: New work for the group. 5 items maximum! ]

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a P=
roposed Standard

[Starting point for the work will be http://datatracker.ietf.org/doc/draft-=
lodderstedt-oauth-revocation/]

Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as=
 a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones=
-json-web-token]

Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2=
.0' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones=
-oauth-jwt-bearer]

Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IES=
G for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-hardj=
ono-oauth-dynreg]

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an I=
nformational RFC

[Starting point for the work will be http://tools.ietf.org/html/draft-zelts=
an-oauth-use-cases]



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


--_000_4E1F6AAD24975D4BA5B16804296739436641D81ETK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













This is missi=
ng Simple Web Discovery, which there was substantial support for including =
during the rechartering discussion in Taipei.  Considering OpenID Conn=
ect as a motivating use case for OAuth,
 SWD is the one spec that would then be missing for this OAuth use case.


Please add it to the list.



Thanks,

-- Mike







From:
Hannes=
 Tschofenig

Sent:
3/14/2=
012 1:21 PM

To:
oauth@=
ietf.org WG

Subject:
[OAUTH=
-WG] OAuth WG Re-Chartering







So, here is a proposal:



-------



Web Authorization Protocol (oauth)



Description of Working Group



The Web Authorization (OAuth) protocol allows a user to grant

a third-party Web site or application access to the user's protected

resources, without necessarily revealing their long-term credentials,

or even their identity. For example, a photo-sharing site that supports

OAuth could allow its users to use a third-party printing Web site to

print their private pictures, without allowing the printing site to

gain full control of the user's account and without having the user 

sharing his or her photo-sharing sites' long-term credential with the 

printing site. 



The OAuth protocol suite encompasses

* a procedure for allowing a client to discover a resource server, 

* a protocol for obtaining authorization tokens from an authorization 

server with the resource owner's consent, 

* protocols for presenting these authorization tokens to protected 

resources for access to a resource, and 

* consequently for sharing data in a security and privacy respective way.


In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,

was published as an informational document (RFC 5849). With the 

completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional

use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result <=
br>
is available as a stand-alone document offering guidance for audiences 

beyond the community of protocol implementers.



The working group also developed security schemes for presenting authorizat=
ion

tokens to access a protected resource. This led to the publication of

the bearer token as well as the message authentication code (MAC) access 
authentication specification. 



OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH toke=
n with


the SAML 2.0 bearer assertion profile.  This offers interworking with =
existing 

identity management solutions, in particular SAML based deployments.



OAuth has enjoyed widespread adoption by the Internet application service p=
rovider


community. To build on this success we aim for nothing more than to make OA=
uth the


authorization framework of choice for any Internet protocol. Consequently, =
the 

ongoing standardization effort within the OAuth working group is focused on=
 

enhancing interoperability of OAuth deployments. While the core OAuth speci=
fication


truly is an important building block it relies on other specifications in o=
rder to


claim completeness. Luckily, these components already exist and have been d=
eployed


on the Internet. Through the IETF standards process they will be improved i=
n 

quality and will undergo a rigorous review process. 



Goals and Milestones



[Editor's Note: Here are the completed items.] 



Done     Submit 'OAuth 2.0 Threat Model and Security Co=
nsiderations' as a working group item

Done     Submit 'HTTP Authentication: MAC Authenticatio=
n' as a working group item

Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens'=
 to the IESG for consideration as a Proposed Standard

Done     Submit 'The OAuth 2.0 Authorization Protocol' =
to the IESG for consideration as a Proposed Standard



[Editor's Note: Finishing existing work. Double-check the proposed dates - =
are they realistic?]




Jun. 2012        Submit 'HTTP Authentica=
tion: MAC Authentication' to the IESG for consideration as a Proposed Stand=
ard

Apr. 2012        Submit 'SAML 2.0 Bearer=
 Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Propo=
sed Standard

Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consid=
eration as a Proposed Standard


Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG fo=
r consideration as a Proposed Standard


May 2012    Submit 'OAuth 2.0 Threat Model and Security Cons=
iderations' to the IESG for consideration as an Informational RFC



[Editor's Note: New work for the group. 5 items maximum! ]



Aug. 2012    Submit 'Token Revocation' to the IESG for consi=
deration as a Proposed Standard



[Starting point for the work will be 
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]


Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for c=
onsideration as a Proposed Standard



[Starting point for the work will be 
http://tools.ietf.org/html/draft-jones-json-web-token]



Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profi=
les for OAuth 2.0' to the IESG for consideration as a Proposed Standard



[Starting point for the work will be 
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]



Jan. 2013    Submit 'OAuth Dynamic Client Registration Proto=
col' to the IESG for consideration as a Proposed Standard



[Starting point for the work will be 
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] 



Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consid=
eration as an Informational RFC



[Starting point for the work will be 
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] 







_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth









--_000_4E1F6AAD24975D4BA5B16804296739436641D81ETK5EX14MBXC284r_--

From eran@hueniverse.com  Wed Mar 14 14:00:51 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5710821F8849 for ; Wed, 14 Mar 2012 14:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Level: 
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3p-gJPruiFI for ; Wed, 14 Mar 2012 14:00:50 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 015D021F8847 for ; Wed, 14 Mar 2012 14:00:49 -0700 (PDT)
Received: (qmail 10324 invoked from network); 14 Mar 2012 21:00:36 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Mar 2012 21:00:36 -0000
Received: from P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id lZ0U1i0060SoFT401Z0bRs; Wed, 14 Mar 2012 14:00:36 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 14 Mar 2012 13:41:09 -0700
From: Eran Hammer 
To: Barry Leiba , Hannes Tschofenig 
Date: Wed, 14 Mar 2012 13:41:00 -0700
Thread-Topic: [OAUTH-WG] Agenda Proposal
Thread-Index: Ac0CInJA9JpOVWC3R/Cjg0dnQejmDgAACClg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08976@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <30401997-7A6A-4306-B909-2EEAE80AA90D@gmx.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 21:00:51 -0000

I'll see this one through. I have some open issues to sum on the list short=
ly which prevented me from getting a new draft submitted in time. Overall, =
we're pretty much done and in agreement. The next draft which should not be=
 a major change, will be ready for WGLC. We can have this sent to the IESG =
by end of April.

EH

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Barry Leiba
> Sent: Wednesday, March 14, 2012 1:25 PM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Agenda Proposal
>=20
> Oh, and...
>=20
> > 4. MAC Token (TBD)
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/
>=20
> I believe that in Eran's last communication about this he said that he do=
es,
> after all, have the time and inclination to finish it, and would like to.
>=20
> b
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From eran@hueniverse.com  Wed Mar 14 14:47:27 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59AA11E8075 for ; Wed, 14 Mar 2012 14:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Level: 
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fNtjsa9Rbvh for ; Wed, 14 Mar 2012 14:47:23 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 236D521F86C9 for ; Wed, 14 Mar 2012 14:47:23 -0700 (PDT)
Received: (qmail 23068 invoked from network); 14 Mar 2012 21:44:28 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Mar 2012 21:44:28 -0000
Received: from P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id lZkU1i0010RWb6o01ZkUyN; Wed, 14 Mar 2012 14:44:28 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 14 Mar 2012 14:43:34 -0700
From: Eran Hammer 
To: Mike Jones , Hannes Tschofenig , "oauth@ietf.org WG" 
Date: Wed, 14 Mar 2012 14:43:26 -0700
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAMCRIf4APwgUm5DSot8V56SZZqRR3KgAAKnQA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08986@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AFF08986P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 21:47:27 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E723453AFF08986P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am strongly opposed to SWD being part of *this* working group. My objecti=
on is based on:


1.       This is clearly an APP area document, not a SEC area document. Get=
ting this work done through the OAuth WG will skip the most relevant audien=
ce for this document as a general purpose tool.

2.       This has nothing to do with OAuth directly. It has the same "enabl=
ing" relationship to OAuth as HTTP or JSON.

3.       This work overlaps with other efforts at the IETF, W3C, and OASIS.=
 If there is strong interest in this work, it should first be coordinated w=
ith the other groups and organizations.

4.       The APPs AD should look into creating a new WG for this if there i=
s strong interest, but I believe this belongs on the APPs General WG.

5.       The OpenID Foundation is free to standardize this within its own p=
rocess as it chose to do with many other documents related to OpenID. I wou=
ld assume the OpenID Foundation values their work and reputation enough to =
stand behind this if they require it for other foundation work.

This is not an objection to SWD in general (nor an endorsement), just an ob=
jection to this work belonging in the OAuth working group.

Btw, there is existing history here. XRD, JRD, host-meta, and well-known UR=
Is were all initiated originally as part of OAuth 1.0 Discovery, but no one=
 working on these efforts suggested they belonged in the OAuth WG.

EH


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M=
ike Jones
Sent: Wednesday, March 14, 2012 1:55 PM
To: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

This is missing Simple Web Discovery, which there was substantial support f=
or including during the rechartering discussion in Taipei.  Considering Ope=
nID Connect as a motivating use case for OAuth, SWD is the one spec that wo=
uld then be missing for this OAuth use case.

Please add it to the list.

Thanks,
-- Mike
________________________________
From: Hannes Tschofenig
Sent: 3/14/2012 1:21 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] OAuth WG Re-Chartering
So, here is a proposal:

-------

Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user
sharing his or her photo-sharing sites' long-term credential with the
printing site.

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server,
* a protocol for obtaining authorization tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these authorization tokens to protected
resources for access to a resource, and
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result
is available as a stand-alone document offering guidance for audiences
beyond the community of protocol implementers.

The working group also developed security schemes for presenting authorizat=
ion
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access
authentication specification.

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH toke=
n with
the SAML 2.0 bearer assertion profile.  This offers interworking with exist=
ing
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application service p=
rovider
community. To build on this success we aim for nothing more than to make OA=
uth the
authorization framework of choice for any Internet protocol. Consequently, =
the
ongoing standardization effort within the OAuth working group is focused on
enhancing interoperability of OAuth deployments. While the core OAuth speci=
fication
truly is an important building block it relies on other specifications in o=
rder to
claim completeness. Luckily, these components already exist and have been d=
eployed
on the Internet. Through the IETF standards process they will be improved i=
n
quality and will undergo a rigorous review process.

Goals and Milestones

[Editor's Note: Here are the completed items.]

Done     Submit 'OAuth 2.0 Threat Model and Security Considerations' as a w=
orking group item
Done     Submit 'HTTP Authentication: MAC Authentication' as a working grou=
p item
Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for con=
sideration as a Proposed Standard
Done     Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for cons=
ideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates - =
are they realistic?]

Jun. 2012        Submit 'HTTP Authentication: MAC Authentication' to the IE=
SG for consideration as a Proposed Standard
Apr. 2012        Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' =
to the IESG for consideration as a Proposed Standard
Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for considerati=
on as a Proposed Standard
Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for con=
sideration as a Proposed Standard
May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to =
the IESG for consideration as an Informational RFC

[Editor's Note: New work for the group. 5 items maximum! ]

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a P=
roposed Standard

[Starting point for the work will be http://datatracker.ietf.org/doc/draft-=
lodderstedt-oauth-revocation/]

Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as=
 a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones=
-json-web-token]

Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2=
.0' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones=
-oauth-jwt-bearer]

Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IES=
G for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-hardj=
ono-oauth-dynreg]

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an I=
nformational RFC

[Starting point for the work will be http://tools.ietf.org/html/draft-zelts=
an-oauth-use-cases]



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

--_000_90C41DD21FB7C64BB94121FBBC2E723453AFF08986P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I am stro=
ngly opposed to SWD being part of *this* working group. My objection=
 is based on:
 <=
/o:p>
1.   &nb=
sp;   This is clearly an APP area document, not a SEC area document. Getting th=
is work done through the OAuth WG will skip the most relevant audience for =
this document as a general purpose tool.
2.       This has nothing to do with=
 OAuth directly. It has the same “enabling” relationship to OAu=
th as HTTP or JSON.
3.       This work overlaps with other efforts at the IE=
TF, W3C, and OASIS. If there is strong interest in this work, it should fir=
st be coordinated with the other groups and organizations.
4.     &n=
bsp; The APPs =
AD should look into creating a new WG for this if there is strong interest,=
 but I believe this belongs on the APPs General WG.
5.       The OpenID Found=
ation is free to standardize this within its own process as it chose to do =
with many other documents related to OpenID. I would assume the OpenID Foun=
dation values their work and reputation enough to stand behind this if they=
 require it for other foundation work.
 
This=
 is not an objection to SWD in general (nor an endorsement), just an object=
ion to this work belonging in the OAuth working group.
 
Btw, there is existing history here. XRD, JRD, host-meta, and wel=
l-known URIs were all initiated originally as part of OAuth 1.0 Discovery, =
but no one working on these efforts suggested they belonged in the OAuth WG=
.
 =

EH
 
 =
;
From: oauth-boun=
ces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones=

Sent: Wednesday, March 14, 2012 1:55 PM
To: Hannes Tsc=
hofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Ch=
artering
 <=
/o:p>
This is missing Simple Web Discovery,=
 which there was substantial support for including during the rechartering =
discussion in Taipei.  Considering OpenID Connect as a motivating use =
case for OAuth, SWD is the one spec that would then be missing for this OAu=
th use case.

Please add it to the list.

Thanks,
-- Mike
From: Hannes Tschofenig
Sent: 3/14/2012 1:21 PM
To: o=
auth@ietf.org WG
Subject: [OAUTH-WG] OAuth WG Re-Chartering
So, here is a proposal:

-----=
--

Web Authorization Protocol (oauth)

Description of Working =
Group

The Web Authorization (OAuth) protocol allows a user to grant<=
br>a third-party Web site or application access to the user's protected
=
resources, without necessarily revealing their long-term credentials,
or=
 even their identity. For example, a photo-sharing site that supports
OA=
uth could allow its users to use a third-party printing Web site to
prin=
t their private pictures, without allowing the printing site to
gain ful=
l control of the user's account and without having the user 
sharing his=
 or her photo-sharing sites' long-term credential with the 
printing sit=
e. 

The OAuth protocol suite encompasses
* a procedure for allowi=
ng a client to discover a resource server, 
* a protocol for obtaining a=
uthorization tokens from an authorization 
server with the resource owne=
r's consent, 
* protocols for presenting these authorization tokens to p=
rotected 
resources for access to a resource, and 
* consequently for=
 sharing data in a security and privacy respective way.

In April 201=
0 the OAuth 1.0 specification, documenting pre-IETF work,
was published =
as an informational document (RFC 5849). With the 
completion of OAuth 1=
.0 the working group started their work on OAuth 2.0
to incorporate impl=
ementation experience with version 1.0, additional
use cases, and variou=
s other security, readability, and interoperability
improvements. An ext=
ensive security analysis was conducted and the result 
is available as a=
 stand-alone document offering guidance for audiences 
beyond the commun=
ity of protocol implementers.

The working group also developed secur=
ity schemes for presenting authorization
tokens to access a protected re=
source. This led to the publication of
the bearer token as well as the m=
essage authentication code (MAC) access 
authentication specification. <=
br>
OAuth 2.0 added the ability to trade a SAML assertion against an OAU=
TH token with 
the SAML 2.0 bearer assertion profile.  This offers =
interworking with existing 
identity management solutions, in particular=
 SAML based deployments.

OAuth has enjoyed widespread adoption by th=
e Internet application service provider 
community. To build on this suc=
cess we aim for nothing more than to make OAuth the 
authorization frame=
work of choice for any Internet protocol. Consequently, the 
ongoing sta=
ndardization effort within the OAuth working group is focused on 
enhanc=
ing interoperability of OAuth deployments. While the core OAuth specificati=
on 
truly is an important building block it relies on other specificatio=
ns in order to 
claim completeness. Luckily, these components already ex=
ist and have been deployed 
on the Internet. Through the IETF standards =
process they will be improved in 
quality and will undergo a rigorous re=
view process. 

Goals and Milestones

[Editor's Note: Here are =
the completed items.] 

Done     Submit 'OAuth 2.=
0 Threat Model and Security Considerations' as a working group item
Done=
     Submit 'HTTP Authentication: MAC Authentication' a=
s a working group item
Done     Submit 'The OAuth 2.=
0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Stan=
dard
Done     Submit 'The OAuth 2.0 Authorization Pr=
otocol' to the IESG for consideration as a Proposed Standard

[Editor=
's Note: Finishing existing work. Double-check the proposed dates - are the=
y realistic?] 

Jun. 2012        S=
ubmit 'HTTP Authentication: MAC Authentication' to the IESG for considerati=
on as a Proposed Standard
Apr. 2012      &=
nbsp; Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG=
 for consideration as a Proposed Standard
Apr. 2012  Submit 'OAuth =
2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard=
 
Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IE=
SG for consideration as a Proposed Standard 
May 2012    =
Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for=
 consideration as an Informational RFC

[Editor's Note: New work for =
the group. 5 items maximum! ]

Aug. 2012    Submit 'To=
ken Revocation' to the IESG for consideration as a Proposed Standard
[Starting point for the work will be http://datatracker.ietf.org/doc/=
draft-lodderstedt-oauth-revocation/]

Nov. 2012   =
 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed =
Standard

[Starting point for the work will be http://tools.ietf.org/html/draf=
t-jones-json-web-token]

Nov. 2012    Submit 'JSON=
 Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consi=
deration as a Proposed Standard

[Starting point for the work will be=
 http:/=
/tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

Jan. 2013&nbs=
p;   Submit 'OAuth Dynamic Client Registration Protocol' to the I=
ESG for consideration as a Proposed Standard

[Starting point for the=
 work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] 

S=
ep. 2012    Submit 'OAuth Use Cases' to the IESG for conside=
ration as an Informational RFC

[Starting point for the work will be =
http:/=
/tools.ietf.org/html/draft-zeltsan-oauth-use-cases] 



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

=

--_000_90C41DD21FB7C64BB94121FBBC2E723453AFF08986P3PW5EX1MB01E_--

From jricher@mitre.org  Wed Mar 14 14:53:41 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E6D21F87EE for ; Wed, 14 Mar 2012 14:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.575
X-Spam-Level: 
X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dzKkZ5ANol1 for ; Wed, 14 Mar 2012 14:53:40 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4415021F87FC for ; Wed, 14 Mar 2012 14:53:40 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C3F5221B03D1; Wed, 14 Mar 2012 17:53:39 -0400 (EDT)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B2ADC21B03C8; Wed, 14 Mar 2012 17:53:39 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.126]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Wed, 14 Mar 2012 17:53:39 -0400
From: "Richer, Justin P." 
To: Hannes Tschofenig 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAMLrJnb2MYa0aucATvktxjjJZqmKGA
Date: Wed, 14 Mar 2012 21:53:39 +0000
Message-ID: <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.8.253]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 21:53:41 -0000

Methods of connecting the PR to the AS are something that several groups ha=
ve invented outside of the OAuth WG, and I think we should try to pull some=
 of this work together. OAuth2 gives us a logical separation of the concern=
s but not a way to knit them back together.=20

Proposals for inclusion in the discussion include UMA's Step 3, OpenID Conn=
ect's CheckID, and several "token introspection" endpoints in various imple=
mentations.

 -- Justin

On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:

> So, here is a proposal:
>=20
> -------
>=20
> Web Authorization Protocol (oauth)
>=20
> Description of Working Group
>=20
> The Web Authorization (OAuth) protocol allows a user to grant
> a third-party Web site or application access to the user's protected
> resources, without necessarily revealing their long-term credentials,
> or even their identity. For example, a photo-sharing site that supports
> OAuth could allow its users to use a third-party printing Web site to
> print their private pictures, without allowing the printing site to
> gain full control of the user's account and without having the user=20
> sharing his or her photo-sharing sites' long-term credential with the=20
> printing site.=20
>=20
> The OAuth protocol suite encompasses
> * a procedure for allowing a client to discover a resource server,=20
> * a protocol for obtaining authorization tokens from an authorization=20
> server with the resource owner's consent,=20
> * protocols for presenting these authorization tokens to protected=20
> resources for access to a resource, and=20
> * consequently for sharing data in a security and privacy respective way.
>=20
> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
> was published as an informational document (RFC 5849). With the=20
> completion of OAuth 1.0 the working group started their work on OAuth 2.0
> to incorporate implementation experience with version 1.0, additional
> use cases, and various other security, readability, and interoperability
> improvements. An extensive security analysis was conducted and the result=
=20
> is available as a stand-alone document offering guidance for audiences=20
> beyond the community of protocol implementers.
>=20
> The working group also developed security schemes for presenting authoriz=
ation
> tokens to access a protected resource. This led to the publication of
> the bearer token as well as the message authentication code (MAC) access=
=20
> authentication specification.=20
>=20
> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH to=
ken with=20
> the SAML 2.0 bearer assertion profile.  This offers interworking with exi=
sting=20
> identity management solutions, in particular SAML based deployments.
>=20
> OAuth has enjoyed widespread adoption by the Internet application service=
 provider=20
> community. To build on this success we aim for nothing more than to make =
OAuth the=20
> authorization framework of choice for any Internet protocol. Consequently=
, the=20
> ongoing standardization effort within the OAuth working group is focused =
on=20
> enhancing interoperability of OAuth deployments. While the core OAuth spe=
cification=20
> truly is an important building block it relies on other specifications in=
 order to=20
> claim completeness. Luckily, these components already exist and have been=
 deployed=20
> on the Internet. Through the IETF standards process they will be improved=
 in=20
> quality and will undergo a rigorous review process.=20
>=20
> Goals and Milestones
>=20
> [Editor's Note: Here are the completed items.]=20
>=20
> Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a wo=
rking group item
> Done 	Submit 'HTTP Authentication: MAC Authentication' as a working group=
 item
> Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for con=
sideration as a Proposed Standard
> Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consi=
deration as a Proposed Standard
>=20
> [Editor's Note: Finishing existing work. Double-check the proposed dates =
- are they realistic?]=20
>=20
> Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the IESG f=
or consideration as a Proposed Standard
> Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to t=
he IESG for consideration as a Proposed Standard
> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for considera=
tion as a Proposed Standard=20
> Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for c=
onsideration as a Proposed Standard=20
> May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' t=
o the IESG for consideration as an Informational RFC
>=20
> [Editor's Note: New work for the group. 5 items maximum! ]
>=20
> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a=
 Proposed Standard
>=20
> [Starting point for the work will be http://datatracker.ietf.org/doc/draf=
t-lodderstedt-oauth-revocation/]
>=20
> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration =
as a Proposed Standard
>=20
> [Starting point for the work will be http://tools.ietf.org/html/draft-jon=
es-json-web-token]
>=20
> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth=
 2.0' to the IESG for consideration as a Proposed Standard
>=20
> [Starting point for the work will be http://tools.ietf.org/html/draft-jon=
es-oauth-jwt-bearer]
>=20
> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the I=
ESG for consideration as a Proposed Standard
>=20
> [Starting point for the work will be http://tools.ietf.org/html/draft-har=
djono-oauth-dynreg]=20
>=20
> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an=
 Informational RFC
>=20
> [Starting point for the work will be http://tools.ietf.org/html/draft-zel=
tsan-oauth-use-cases]=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From eran@hueniverse.com  Wed Mar 14 15:27:30 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E0011E8079 for ; Wed, 14 Mar 2012 15:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWXPv6RVovZ1 for ; Wed, 14 Mar 2012 15:27:29 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 720F311E8075 for ; Wed, 14 Mar 2012 15:27:29 -0700 (PDT)
Received: (qmail 302 invoked from network); 14 Mar 2012 22:02:55 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Mar 2012 22:02:55 -0000
Received: from P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id la2n1i0020SoFT401a2vbV; Wed, 14 Mar 2012 15:02:55 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 14 Mar 2012 15:02:50 -0700
From: Eran Hammer 
To: "Richer, Justin P." , Hannes Tschofenig 
Date: Wed, 14 Mar 2012 15:02:42 -0700
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAMLrJnb2MYa0aucATvktxjjJZqmKGA//+/NsA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08993@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org>
In-Reply-To: <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 22:27:31 -0000

The best way is to get some drafts going and then revisit after the propose=
d charter is completed. I think the 5 new items limit along with the existi=
ng work is as much as this WG can take for the time being.

Getting some market experience would be great too.

EH

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Richer, Justin P.
> Sent: Wednesday, March 14, 2012 2:54 PM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>=20
> Methods of connecting the PR to the AS are something that several groups
> have invented outside of the OAuth WG, and I think we should try to pull
> some of this work together. OAuth2 gives us a logical separation of the
> concerns but not a way to knit them back together.
>=20
> Proposals for inclusion in the discussion include UMA's Step 3, OpenID
> Connect's CheckID, and several "token introspection" endpoints in various
> implementations.
>=20
>  -- Justin
>=20
> On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:
>=20
> > So, here is a proposal:
> >
> > -------
> >
> > Web Authorization Protocol (oauth)
> >
> > Description of Working Group
> >
> > The Web Authorization (OAuth) protocol allows a user to grant a
> > third-party Web site or application access to the user's protected
> > resources, without necessarily revealing their long-term credentials,
> > or even their identity. For example, a photo-sharing site that
> > supports OAuth could allow its users to use a third-party printing Web
> > site to print their private pictures, without allowing the printing
> > site to gain full control of the user's account and without having the
> > user sharing his or her photo-sharing sites' long-term credential with
> > the printing site.
> >
> > The OAuth protocol suite encompasses
> > * a procedure for allowing a client to discover a resource server,
> > * a protocol for obtaining authorization tokens from an authorization
> > server with the resource owner's consent,
> > * protocols for presenting these authorization tokens to protected
> > resources for access to a resource, and
> > * consequently for sharing data in a security and privacy respective wa=
y.
> >
> > In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
> > was published as an informational document (RFC 5849). With the
> > completion of OAuth 1.0 the working group started their work on OAuth
> > 2.0 to incorporate implementation experience with version 1.0,
> > additional use cases, and various other security, readability, and
> > interoperability improvements. An extensive security analysis was
> > conducted and the result is available as a stand-alone document
> > offering guidance for audiences beyond the community of protocol
> implementers.
> >
> > The working group also developed security schemes for presenting
> > authorization tokens to access a protected resource. This led to the
> > publication of the bearer token as well as the message authentication
> > code (MAC) access authentication specification.
> >
> > OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH
> > token with the SAML 2.0 bearer assertion profile.  This offers
> > interworking with existing identity management solutions, in particular
> SAML based deployments.
> >
> > OAuth has enjoyed widespread adoption by the Internet application
> > service provider community. To build on this success we aim for
> > nothing more than to make OAuth the authorization framework of choice
> > for any Internet protocol. Consequently, the ongoing standardization
> > effort within the OAuth working group is focused on enhancing
> > interoperability of OAuth deployments. While the core OAuth
> > specification truly is an important building block it relies on other
> > specifications in order to claim completeness. Luckily, these
> > components already exist and have been deployed on the Internet.
> Through the IETF standards process they will be improved in quality and w=
ill
> undergo a rigorous review process.
> >
> > Goals and Milestones
> >
> > [Editor's Note: Here are the completed items.]
> >
> > Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations'
> as a working group item
> > Done 	Submit 'HTTP Authentication: MAC Authentication' as a
> working group item
> > Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG
> for consideration as a Proposed Standard
> > Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for
> consideration as a Proposed Standard
> >
> > [Editor's Note: Finishing existing work. Double-check the proposed
> > dates - are they realistic?]
> >
> > Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the
> IESG for consideration as a Proposed Standard
> > Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to
> the IESG for consideration as a Proposed Standard
> > Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for
> > consideration as a Proposed Standard Apr. 2012  Submit 'An IETF URN Sub=
-
> Namespace for OAuth' to the IESG for consideration as a Proposed Standard
> > May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations'=
 to
> the IESG for consideration as an Informational RFC
> >
> > [Editor's Note: New work for the group. 5 items maximum! ]
> >
> > Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as=
 a
> Proposed Standard
> >
> > [Starting point for the work will be
> > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
> >
> > Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideratio=
n
> as a Proposed Standard
> >
> > [Starting point for the work will be
> > http://tools.ietf.org/html/draft-jones-json-web-token]
> >
> > Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
> OAuth 2.0' to the IESG for consideration as a Proposed Standard
> >
> > [Starting point for the work will be
> > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
> >
> > Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the=
 IESG
> for consideration as a Proposed Standard
> >
> > [Starting point for the work will be
> > http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
> >
> > Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as =
an
> Informational RFC
> >
> > [Starting point for the work will be
> > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
> >
> >
> >
> > _______________________________________________
> > 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 tonynad@microsoft.com  Wed Mar 14 15:51:24 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0098111E8081 for ; Wed, 14 Mar 2012 15:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.466
X-Spam-Level: 
X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YvkpTygCAEf for ; Wed, 14 Mar 2012 15:51:22 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id AA97411E8075 for ; Wed, 14 Mar 2012 15:51:21 -0700 (PDT)
Received: from mail9-am1-R.bigfish.com (10.3.201.245) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Mar 2012 22:51:22 +0000
Received: from mail9-am1 (localhost [127.0.0.1])	by mail9-am1-R.bigfish.com (Postfix) with ESMTP id C17202E0531	for ; Wed, 14 Mar 2012 22:51:21 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VS-38(zzbb2dI9371Ic85fh1432N98dK199bRzz1202h1082kzz1033IL8275dhz2fh2a8h683h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail9-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail9-am1 (localhost.localdomain [127.0.0.1]) by mail9-am1 (MessageSwitch) id 1331765479274922_31497; Wed, 14 Mar 2012 22:51:19 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.230])	by mail9-am1.bigfish.com (Postfix) with ESMTP id 3D33A480043	for ; Wed, 14 Mar 2012 22:51:19 +0000 (UTC)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Mar 2012 22:51:18 +0000
Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 14 Mar 2012 22:51:14 +0000
Received: from mail90-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Mar 2012 22:51:14 +0000
Received: from mail90-tx2 (localhost [127.0.0.1])	by mail90-tx2-R.bigfish.com (Postfix) with ESMTP id 7F4F91E0394	for ; Wed, 14 Mar 2012 22:51:14 +0000 (UTC)
Received: from mail90-tx2 (localhost.localdomain [127.0.0.1]) by mail90-tx2 (MessageSwitch) id 1331765472414458_13266; Wed, 14 Mar 2012 22:51:12 +0000 (UTC)
Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.246])	by mail90-tx2.bigfish.com (Postfix) with ESMTP id 5A4E92C01B2; Wed, 14 Mar 2012 22:51:12 +0000 (UTC)
Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Mar 2012 22:51:10 +0000
Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.177]) by BL2PRD0310HT002.namprd03.prod.outlook.com ([10.255.97.37]) with mapi id 14.16.0135.002; Wed, 14 Mar 2012 22:51:08 +0000
From: Anthony Nadalin 
To: "igor.faynberg@alcatel-lucent.com" , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAlqWkT0kJGqkyL+cY6VRZ7apZqPR6AgAAog+A=
Date: Wed, 14 Mar 2012 22:51:06 +0000
Message-ID: 
References: , <4F60FEDF.1030600@alcatel-lucent.com>
In-Reply-To: <4F60FEDF.1030600@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [32.147.5.16]
Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E73C081C3DBL2PRD0310MB362_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT002.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com
X-OriginatorOrg: microsoft.com
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 22:51:24 -0000

--_000_B26C1EF377CB694EAB6BDDC8E624B6E73C081C3DBL2PRD0310MB362_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Agree contents looks good

Sent from my Windows Phone
________________________________
From: Igor Faynberg
Sent: 3/14/2012 4:26 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Looks good and comprehensive to me.

Igor

On 3/14/2012 4:21 PM, Hannes Tschofenig wrote:
> So, here is a proposal:
>
> -------
>
> Web Authorization Protocol (oauth)
>
> Description of Working Group
>
> The Web Authorization (OAuth) protocol allows a user to grant
> a third-party Web site or application access to the user's protected
> resources, without necessarily revealing their long-term credentials,
> or even their identity. For example, a photo-sharing site that supports
> OAuth could allow its users to use a third-party printing Web site to
> print their private pictures, without allowing the printing site to
> gain full control of the user's account and without having the user
> sharing his or her photo-sharing sites' long-term credential with the
> printing site.
>
> The OAuth protocol suite encompasses
> * a procedure for allowing a client to discover a resource server,
> * a protocol for obtaining authorization tokens from an authorization
> server with the resource owner's consent,
> * protocols for presenting these authorization tokens to protected
> resources for access to a resource, and
> * consequently for sharing data in a security and privacy respective way.
>
> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
> was published as an informational document (RFC 5849). With the
> completion of OAuth 1.0 the working group started their work on OAuth 2.0
> to incorporate implementation experience with version 1.0, additional
> use cases, and various other security, readability, and interoperability
> improvements. An extensive security analysis was conducted and the result
> is available as a stand-alone document offering guidance for audiences
> beyond the community of protocol implementers.
>
> The working group also developed security schemes for presenting authoriz=
ation
> tokens to access a protected resource. This led to the publication of
> the bearer token as well as the message authentication code (MAC) access
> authentication specification.
>
> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH to=
ken with
> the SAML 2.0 bearer assertion profile.  This offers interworking with exi=
sting
> identity management solutions, in particular SAML based deployments.
>
> OAuth has enjoyed widespread adoption by the Internet application service=
 provider
> community. To build on this success we aim for nothing more than to make =
OAuth the
> authorization framework of choice for any Internet protocol. Consequently=
, the
> ongoing standardization effort within the OAuth working group is focused =
on
> enhancing interoperability of OAuth deployments. While the core OAuth spe=
cification
> truly is an important building block it relies on other specifications in=
 order to
> claim completeness. Luckily, these components already exist and have been=
 deployed
> on the Internet. Through the IETF standards process they will be improved=
 in
> quality and will undergo a rigorous review process.
>
> Goals and Milestones
>
> [Editor's Note: Here are the completed items.]
>
> Done   Submit 'OAuth 2.0 Threat Model and Security Considerations' as a w=
orking group item
> Done   Submit 'HTTP Authentication: MAC Authentication' as a working grou=
p item
> Done   Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for con=
sideration as a Proposed Standard
> Done   Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for cons=
ideration as a Proposed Standard
>
> [Editor's Note: Finishing existing work. Double-check the proposed dates =
- are they realistic?]
>
> Jun. 2012      Submit 'HTTP Authentication: MAC Authentication' to the IE=
SG for consideration as a Proposed Standard
> Apr. 2012      Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' =
to the IESG for consideration as a Proposed Standard
> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for considera=
tion as a Proposed Standard
> Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for c=
onsideration as a Proposed Standard
> May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' t=
o the IESG for consideration as an Informational RFC
>
> [Editor's Note: New work for the group. 5 items maximum! ]
>
> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a=
 Proposed Standard
>
> [Starting point for the work will be http://datatracker.ietf.org/doc/draf=
t-lodderstedt-oauth-revocation/]
>
> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration =
as a Proposed Standard
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-jon=
es-json-web-token]
>
> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth=
 2.0' to the IESG for consideration as a Proposed Standard
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-jon=
es-oauth-jwt-bearer]
>
> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the I=
ESG for consideration as a Proposed Standard
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-har=
djono-oauth-dynreg]
>
> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an=
 Informational RFC
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-zel=
tsan-oauth-use-cases]
>
>
>
> _______________________________________________
> 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




--_000_B26C1EF377CB694EAB6BDDC8E624B6E73C081C3DBL2PRD0310MB362_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













Agree content=
s looks good



Sent from my Windows Phone







From:
Igor F=
aynberg

Sent:
3/14/2=
012 4:26 PM

To:
oauth@=
ietf.org

Subject:
Re: [O=
AUTH-WG] OAuth WG Re-Chartering







Looks good and comprehensive to me.



Igor



On 3/14/2012 4:21 PM, Hannes Tschofenig wrote:

> So, here is a proposal:

>

> -------

>

> Web Authorization Protocol (oauth)

>

> Description of Working Group

>

> The Web Authorization (OAuth) protocol allows a user to grant

> a third-party Web site or application access to the user's protected
> resources, without necessarily revealing their long-term credentials,<=
br>
> or even their identity. For example, a photo-sharing site that support=
s

> OAuth could allow its users to use a third-party printing Web site to<=
br>
> print their private pictures, without allowing the printing site to
> gain full control of the user's account and without having the user
> sharing his or her photo-sharing sites' long-term credential with the<=
br>
> printing site.

>

> The OAuth protocol suite encompasses

> * a procedure for allowing a client to discover a resource server,

> * a protocol for obtaining authorization tokens from an authorization<=
br>
> server with the resource owner's consent,

> * protocols for presenting these authorization tokens to protected

> resources for access to a resource, and

> * consequently for sharing data in a security and privacy respective w=
ay.

>

> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,<=
br>
> was published as an informational document (RFC 5849). With the

> completion of OAuth 1.0 the working group started their work on OAuth =
2.0

> to incorporate implementation experience with version 1.0, additional<=
br>
> use cases, and various other security, readability, and interoperabili=
ty

> improvements. An extensive security analysis was conducted and the res=
ult

> is available as a stand-alone document offering guidance for audiences=


> beyond the community of protocol implementers.

>

> The working group also developed security schemes for presenting autho=
rization

> tokens to access a protected resource. This led to the publication of<=
br>
> the bearer token as well as the message authentication code (MAC) acce=
ss

> authentication specification.

>

> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH=
 token with

> the SAML 2.0 bearer assertion profile.  This offers interworking =
with existing

> identity management solutions, in particular SAML based deployments.
>

> OAuth has enjoyed widespread adoption by the Internet application serv=
ice provider

> community. To build on this success we aim for nothing more than to ma=
ke OAuth the

> authorization framework of choice for any Internet protocol. Consequen=
tly, the

> ongoing standardization effort within the OAuth working group is focus=
ed on

> enhancing interoperability of OAuth deployments. While the core OAuth =
specification

> truly is an important building block it relies on other specifications=
 in order to

> claim completeness. Luckily, these components already exist and have b=
een deployed

> on the Internet. Through the IETF standards process they will be impro=
ved in

> quality and will undergo a rigorous review process.

>

> Goals and Milestones

>

> [Editor's Note: Here are the completed items.]

>

> Done   Submit 'OAuth 2.0 Threat Model and Security Considera=
tions' as a working group item

> Done   Submit 'HTTP Authentication: MAC Authentication' as a=
 working group item

> Done   Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the=
 IESG for consideration as a Proposed Standard

> Done   Submit 'The OAuth 2.0 Authorization Protocol' to the =
IESG for consideration as a Proposed Standard

>

> [Editor's Note: Finishing existing work. Double-check the proposed dat=
es - are they realistic?]

>

> Jun. 2012      Submit 'HTTP Authentication: M=
AC Authentication' to the IESG for consideration as a Proposed Standard

> Apr. 2012      Submit 'SAML 2.0 Bearer Assert=
ion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Sta=
ndard

> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for c=
onsideration as a Proposed Standard

> Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IE=
SG for consideration as a Proposed Standard

> May 2012    Submit 'OAuth 2.0 Threat Model and Security=
 Considerations' to the IESG for consideration as an Informational RFC

>

> [Editor's Note: New work for the group. 5 items maximum! ]

>

> Aug. 2012    Submit 'Token Revocation' to the IESG for =
consideration as a Proposed Standard

>

> [Starting point for the work will be 
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
>

> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG =
for consideration as a Proposed Standard

>

> [Starting point for the work will be 
http://tools.ietf.org/html/draft-jones-json-web-token]

>

> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token =
Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standar=
d

>

> [Starting point for the work will be 
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

>

> Jan. 2013    Submit 'OAuth Dynamic Client Registration =
Protocol' to the IESG for consideration as a Proposed Standard

>

> [Starting point for the work will be 
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]

>

> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for c=
onsideration as an Informational RFC

>

> [Starting point for the work will be 
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]

>

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

> https://www.ie=
tf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth













--_000_B26C1EF377CB694EAB6BDDC8E624B6E73C081C3DBL2PRD0310MB362_--

From bcampbell@pingidentity.com  Wed Mar 14 15:56:27 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5792321F8725 for ; Wed, 14 Mar 2012 15:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.623
X-Spam-Level: 
X-Spam-Status: No, score=-5.623 tagged_above=-999 required=5 tests=[AWL=0.354,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv9dYh4GXcm2 for ; Wed, 14 Mar 2012 15:56:25 -0700 (PDT)
Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC521F8722 for ; Wed, 14 Mar 2012 15:56:24 -0700 (PDT)
Received: from mail-vx0-f179.google.com ([209.85.220.179]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKT2EiF3qSIMlYkfRZzkz7CYfmbyQO49i8@postini.com; Wed, 14 Mar 2012 15:56:24 PDT
Received: by vcbf11 with SMTP id f11so2502737vcb.10 for ; Wed, 14 Mar 2012 15:56:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=5nKFtnQwYeXXTgTjVCMHeFqb+7qGHFEGgsWZYNpzBiY=; b=bRzsyB7ykPr+8PbFQekjZJDnesho+21JsqEhRpxcSMMx3BD4fNLs7JUFpcCfMIcBqS CFA70ay6NlZbMrhVnw4Dxto7DXwBkokq6omIovVLHKeH6MbYSkfaUkI91mwP2S0v9SgQ xzVkg/R91s2a3SYSi7BbIQdAJDvySLNWc5gaiWqyKeosnROdfzVZC+c4usndDp5JOTbr ZhOwPJrkzwbgyDQCzF8v3foYCq+x1xJqgBO9FsbSa8HgTnIQPD+LeM7OuMExeyXQghR5 CgbCqeSPg7pepmG/2GnTpDNRrZsg6ULEhCvIqAE8zHLopWvfen8bCP5pmu+BcOx/mBY3 msgg==
Received: by 10.52.91.16 with SMTP id ca16mr3121747vdb.125.1331765414254; Wed, 14 Mar 2012 15:50:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.171.172 with HTTP; Wed, 14 Mar 2012 15:49:44 -0700 (PDT)
From: Brian Campbell 
Date: Wed, 14 Mar 2012 16:49:44 -0600
Message-ID: 
To: Hannes Tschofenig 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkOu5pKZrCzvbhJgqX3Xj5o36qZmCHFATEopFgCsFxvPXH6ZcIVBiJfrbk0+4+CnpiiIMXw
Cc: "oauth@ietf.org WG" 
Subject: [OAUTH-WG] Assertions (was Agenda Proposal)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 22:56:27 -0000

Unfortunately I will not be in Paris for the Thrus meeting but I'd
love to see the assertion drafts progress. So thanks to Hannes for
putting it on the agenda and to Mike for owning that portion of it.

There's been some light discussion on this list around the assertion
stuff but, as far as I know, there's only been one question raised
that might potentially involve changes:
http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html

Just a nit/clarification that while draft-ietf-oauth-urn-sub-ns is
used by draft-ietf-oauth-saml2-bearer, it is intended to have a
broader scope and not just limited to assertions. It should be a means
of registering urn:ietf:params:oauth:* URNs for any OAuth related
specifications or extensions that might need one.

On Wed, Mar 14, 2012 at 2:14 PM, Hannes Tschofenig
 wrote:
> Feedback appreciated!
>
> 3. OAuth Assertions (Mike)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
> https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
> https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns/

From cmortimore@salesforce.com  Wed Mar 14 16:03:02 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2BA21F87EE for ; Wed, 14 Mar 2012 16:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaTJbjZxfcT6 for ; Wed, 14 Mar 2012 16:03:00 -0700 (PDT)
Received: from exprod8og101.obsmtp.com (exprod8og101.obsmtp.com [64.18.3.82]) by ietfa.amsl.com (Postfix) with SMTP id 7E31B21F87CA for ; Wed, 14 Mar 2012 16:03:00 -0700 (PDT)
Received: from exsfm-hub5.internal.salesforce.com ([204.14.239.233]) by exprod8ob101.postini.com ([64.18.7.12]) with SMTP ID DSNKT2EjpDf0lKWZPeG6qLrmBGuAgzv41NBO@postini.com; Wed, 14 Mar 2012 16:03:00 PDT
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.57]) by exsfm-hub5.internal.salesforce.com ([10.1.127.5]) with mapi; Wed, 14 Mar 2012 16:03:00 -0700
From: Chuck Mortimore 
To: Brian Campbell , Hannes Tschofenig 
Date: Wed, 14 Mar 2012 16:02:58 -0700
Thread-Topic: [OAUTH-WG] Assertions (was Agenda Proposal)
Thread-Index: Ac0CNbHhb5CT9jv+RlWPJpW2kRW9/AAAOcAa
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CB8671B228A2Acmortimoresalesforcecom_"
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertions (was Agenda Proposal)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 23:03:02 -0000

--_000_CB8671B228A2Acmortimoresalesforcecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'll be there to help support this part of the discussion as well.

-cmort


On 3/14/12 3:49 PM, "Brian Campbell"  wrote:

Unfortunately I will not be in Paris for the Thrus meeting but I'd
love to see the assertion drafts progress. So thanks to Hannes for
putting it on the agenda and to Mike for owning that portion of it.

There's been some light discussion on this list around the assertion
stuff but, as far as I know, there's only been one question raised
that might potentially involve changes:
http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html

Just a nit/clarification that while draft-ietf-oauth-urn-sub-ns is
used by draft-ietf-oauth-saml2-bearer, it is intended to have a
broader scope and not just limited to assertions. It should be a means
of registering urn:ietf:params:oauth:* URNs for any OAuth related
specifications or extensions that might need one.

On Wed, Mar 14, 2012 at 2:14 PM, Hannes Tschofenig
 wrote:
> Feedback appreciated!
>
> 3. OAuth Assertions (Mike)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
> https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
> https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--_000_CB8671B228A2Acmortimoresalesforcecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Re: [OAUTH-WG] Assertions (was Agenda Proposal)


I’ll be t=
here to help support this part of the discussion as well.



-cmort





On 3/14/12 3:49 PM, "Brian Campbell" <bcampbell@pingidentity.com> wrote:




Unfortunately I will not be in Paris for the Thrus meeting but I=
'd

love to see the assertion drafts progress. So thanks to Hannes for

putting it on the agenda and to Mike for owning that portion of it.



There's been some light discussion on this list around the assertion

stuff but, as far as I know, there's only been one question raised

that might potentially involve changes:

http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html



Just a nit/clarification that while draft-ietf-oauth-urn-sub-ns is

used by draft-ietf-oauth-saml2-bearer, it is intended to have a

broader scope and not just limited to assertions. It should be a means

of registering urn:ietf:params:oauth:* URNs for any OAuth related

specifications or extensions that might need one.



On Wed, Mar 14, 2012 at 2:14 PM, Hannes Tschofenig

<hannes.tschofenig@gmx.net>=
 wrote:

> Feedback appreciated!

>

> 3. OAuth Assertions (Mike)

> https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/

> https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
> https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns/

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth









--_000_CB8671B228A2Acmortimoresalesforcecom_--

From jricher@mitre.org  Wed Mar 14 19:51:23 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370D811E8087 for ; Wed, 14 Mar 2012 19:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.576
X-Spam-Level: 
X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3Ue6tegQgwS for ; Wed, 14 Mar 2012 19:51:22 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB8D11E8075 for ; Wed, 14 Mar 2012 19:51:22 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 72A7021B003C; Wed, 14 Mar 2012 22:51:21 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 31A6D21B059F; Wed, 14 Mar 2012 22:51:21 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.126]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Wed, 14 Mar 2012 22:51:21 -0400
From: "Richer, Justin P." 
To: Eran Hammer 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAMLrJnb2MYa0aucATvktxjjJZqmKGA//+/NsCAAJP1gA==
Date: Thu, 15 Mar 2012 02:51:19 +0000
Message-ID: <39E4BAA2-4DAC-4052-A716-025E298BDCCF@mitre.org>
References:  <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org> <90C41DD21FB7C64BB94121FBBC2E723453AFF08993@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08993@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.33.94]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <82791D9AE50C2C41B802B528BBFAF176@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 02:51:23 -0000

Makes sense to limit the scope within this WG and try to spin new ones wher=
e appropriate for other work (or find homes in others). We wouldn't want th=
e OAuth WG to just be a convenient hanging-point for vaguely related things=
. That said, the AS-PR connection is a real and present known gap introduce=
d in OAuth2 (since OAuth1 didn't even think of them as separate entities) a=
nd *somebody* should be trying to codify the best ways to fill that gap and=
 I think this is a good place to do it.

Along those lines, I don't think that SWD really belongs in the OAuth group=
 either *except* for the fact that there's a Discovery mandate below that n=
obody's contesting. It's arguable that this simply covers the WWW-Authentic=
ate header and its value in different contexts, but we all know this is inc=
omplete discovery at best. JWT also doesn't feel like it really belongs her=
e, but since JOSE won't have it, it's a fairly important orphan that's alre=
ady seeing deployment experience.

Add to all of this that I have two other drafts that I'd like to see dusted=
 off and moved forward through some process -- alternate encoding (XML and =
Form parameters) from the token endpoint, and the UX/dynreg related "instan=
ce information" draft. I'll have versions of both of these uploaded once th=
e IETF tracker takes the locks off at the end of the month. Neither of thes=
e saw much WG feedback or support before, though, so I'm open to suggestion=
s of what a better home for them might be, if there is one. Or maybe we sho=
uld make a new group for all the orphaned open web specs?

 -- Justin

On Mar 14, 2012, at 6:02 PM, Eran Hammer wrote:

> The best way is to get some drafts going and then revisit after the propo=
sed charter is completed. I think the 5 new items limit along with the exis=
ting work is as much as this WG can take for the time being.
>=20
> Getting some market experience would be great too.
>=20
> EH
>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Richer, Justin P.
>> Sent: Wednesday, March 14, 2012 2:54 PM
>> To: Hannes Tschofenig
>> Cc: oauth@ietf.org WG
>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>=20
>> Methods of connecting the PR to the AS are something that several groups
>> have invented outside of the OAuth WG, and I think we should try to pull
>> some of this work together. OAuth2 gives us a logical separation of the
>> concerns but not a way to knit them back together.
>>=20
>> Proposals for inclusion in the discussion include UMA's Step 3, OpenID
>> Connect's CheckID, and several "token introspection" endpoints in variou=
s
>> implementations.
>>=20
>> -- Justin
>>=20
>> On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:
>>=20
>>> So, here is a proposal:
>>>=20
>>> -------
>>>=20
>>> Web Authorization Protocol (oauth)
>>>=20
>>> Description of Working Group
>>>=20
>>> The Web Authorization (OAuth) protocol allows a user to grant a
>>> third-party Web site or application access to the user's protected
>>> resources, without necessarily revealing their long-term credentials,
>>> or even their identity. For example, a photo-sharing site that
>>> supports OAuth could allow its users to use a third-party printing Web
>>> site to print their private pictures, without allowing the printing
>>> site to gain full control of the user's account and without having the
>>> user sharing his or her photo-sharing sites' long-term credential with
>>> the printing site.
>>>=20
>>> The OAuth protocol suite encompasses
>>> * a procedure for allowing a client to discover a resource server,
>>> * a protocol for obtaining authorization tokens from an authorization
>>> server with the resource owner's consent,
>>> * protocols for presenting these authorization tokens to protected
>>> resources for access to a resource, and
>>> * consequently for sharing data in a security and privacy respective wa=
y.
>>>=20
>>> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
>>> was published as an informational document (RFC 5849). With the
>>> completion of OAuth 1.0 the working group started their work on OAuth
>>> 2.0 to incorporate implementation experience with version 1.0,
>>> additional use cases, and various other security, readability, and
>>> interoperability improvements. An extensive security analysis was
>>> conducted and the result is available as a stand-alone document
>>> offering guidance for audiences beyond the community of protocol
>> implementers.
>>>=20
>>> The working group also developed security schemes for presenting
>>> authorization tokens to access a protected resource. This led to the
>>> publication of the bearer token as well as the message authentication
>>> code (MAC) access authentication specification.
>>>=20
>>> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH
>>> token with the SAML 2.0 bearer assertion profile.  This offers
>>> interworking with existing identity management solutions, in particular
>> SAML based deployments.
>>>=20
>>> OAuth has enjoyed widespread adoption by the Internet application
>>> service provider community. To build on this success we aim for
>>> nothing more than to make OAuth the authorization framework of choice
>>> for any Internet protocol. Consequently, the ongoing standardization
>>> effort within the OAuth working group is focused on enhancing
>>> interoperability of OAuth deployments. While the core OAuth
>>> specification truly is an important building block it relies on other
>>> specifications in order to claim completeness. Luckily, these
>>> components already exist and have been deployed on the Internet.
>> Through the IETF standards process they will be improved in quality and =
will
>> undergo a rigorous review process.
>>>=20
>>> Goals and Milestones
>>>=20
>>> [Editor's Note: Here are the completed items.]
>>>=20
>>> Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations'
>> as a working group item
>>> Done 	Submit 'HTTP Authentication: MAC Authentication' as a
>> working group item
>>> Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG
>> for consideration as a Proposed Standard
>>> Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for
>> consideration as a Proposed Standard
>>>=20
>>> [Editor's Note: Finishing existing work. Double-check the proposed
>>> dates - are they realistic?]
>>>=20
>>> Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the
>> IESG for consideration as a Proposed Standard
>>> Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to
>> the IESG for consideration as a Proposed Standard
>>> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for
>>> consideration as a Proposed Standard Apr. 2012  Submit 'An IETF URN Sub=
-
>> Namespace for OAuth' to the IESG for consideration as a Proposed Standar=
d
>>> May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations'=
 to
>> the IESG for consideration as an Informational RFC
>>>=20
>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>>=20
>>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as=
 a
>> Proposed Standard
>>>=20
>>> [Starting point for the work will be
>>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
>>>=20
>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideratio=
n
>> as a Proposed Standard
>>>=20
>>> [Starting point for the work will be
>>> http://tools.ietf.org/html/draft-jones-json-web-token]
>>>=20
>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
>> OAuth 2.0' to the IESG for consideration as a Proposed Standard
>>>=20
>>> [Starting point for the work will be
>>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
>>>=20
>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the=
 IESG
>> for consideration as a Proposed Standard
>>>=20
>>> [Starting point for the work will be
>>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
>>>=20
>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as =
an
>> Informational RFC
>>>=20
>>> [Starting point for the work will be
>>> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


From eran@hueniverse.com  Wed Mar 14 22:19:15 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449E121F84E1 for ; Wed, 14 Mar 2012 22:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzBOhPH0ttDB for ; Wed, 14 Mar 2012 22:19:14 -0700 (PDT)
Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1C83421F84D8 for ; Wed, 14 Mar 2012 22:19:13 -0700 (PDT)
Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id lhKD1i00110TkE001hKDoW; Wed, 14 Mar 2012 22:19:13 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 14 Mar 2012 22:19:13 -0700
From: Eran Hammer 
To: "Richer, Justin P." 
Date: Wed, 14 Mar 2012 22:19:05 -0700
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAMLrJnb2MYa0aucATvktxjjJZqmKGA//+/NsCAAJP1gP//4DNw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF089B0@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org> <90C41DD21FB7C64BB94121FBBC2E723453AFF08993@P3PW5EX1MB01.EX1.SECURESERVER.NET> <39E4BAA2-4DAC-4052-A716-025E298BDCCF@mitre.org>
In-Reply-To: <39E4BAA2-4DAC-4052-A716-025E298BDCCF@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 05:19:15 -0000

> -----Original Message-----
> From: Richer, Justin P. [mailto:jricher@mitre.org]
> Sent: Wednesday, March 14, 2012 7:51 PM

> [...] the AS-PR connection is a real and present known
> gap introduced in OAuth2 (since OAuth1 didn't even think of them as
> separate entities) and *somebody* should be trying to codify the best way=
s
> to fill that gap and I think this is a good place to do it.

I'm not sure this is an issue for more existing implementations given that =
it is just an internal implementation detail. It becomes more of a use case=
 when you have different entities managing the different roles. I'm not obj=
ecting to this line of work, but I we do need a proposal and it should be b=
ased on something more than just ideas (e.g. some deployment experience). O=
ne of the benefit of starting off a draft and not just ideas is that it sho=
ws real interest and traction.
=20
> Along those lines, I don't think that SWD really belongs in the OAuth gro=
up
> either *except* for the fact that there's a Discovery mandate below that
> nobody's contesting. It's arguable that this simply covers the WWW-
> Authenticate header and its value in different contexts, but we all know =
this
> is incomplete discovery at best.

Discovery is a very wide topic. The only discovery item proposed I the dyna=
mic client registration proposal. It is fine to discuss potential discovery=
 tools in this context, but we should not be the primary source of innovati=
on in the space. So we're in agreement that SWD doesn't belong here. Nor do=
es WebFinger which is working on similar problems.

The ideal scenario would be to get traction on these general purpose discov=
ery mechanisms elsewhere, and revisit this when the working group is discus=
sing the dynamic client registration proposal. IOW, we may end up discussin=
g and contributing to an APPS area discovery work to ensure our needs are s=
upported, but not publish such documents in the WG.

> JWT also doesn't feel like it really belongs
> here, but since JOSE won't have it, it's a fairly important orphan that's=
 already
> seeing deployment experience.

I don't have strong opinions on this, mostly because I understand it to be =
fairly finished. If the WG will need to spend a few months discussing it, I=
 will have to reconsider.

> Add to all of this that I have two other drafts that I'd like to see dust=
ed off
> and moved forward through some process -- alternate encoding (XML and
> Form parameters) from the token endpoint, and the UX/dynreg related
> "instance information" draft. I'll have versions of both of these uploade=
d
> once the IETF tracker takes the locks off at the end of the month.=20

I think the XML draft is simple enough to include. I've supported it in the=
 last round. I think the UX work is actually really important if someone is=
 willing to take the lead on that and do the work.

> Neither of
> these saw much WG feedback or support before, though, so I'm open to
> suggestions of what a better home for them might be, if there is one. Or
> maybe we should make a new group for all the orphaned open web specs?

I think many people here don't fully understand the ways the IETF works. Wh=
ile working groups are the main venue for collaboration, there is a lot of =
work done on an Individual Submission basis (more than half?). This means a=
 specification is created and finalized outside an official WG and without =
a charter.

The general mechanism (at least as used pretty effectively by me for a hand=
ful of published RFCs) is to find the right mailing list (e.g. HTTP for Lin=
k relations, Apps Discuss for host-meta and well-known, OAuth for OAuth 1.0=
) and support from an Area Director. You also need to fine a document sheph=
erd  to help review and help with the "paperwork".

The way this works is that you can write a specification, discuss it on the=
 WG list, and when you feel it is ready, ask the sponsoring AD for IETF Las=
t Call. The AD might decide this is better suited to go through the full WG=
 process, or feel that the document is simple and narrow enough to skip it.=
 It is also possible that some of this work will be discussed on this list,=
 but sponsored by an APPS area AD (e.g. the XML extension is a perfect exam=
ple for something that is really not a security protocol component). So you=
 have options.

IOW, getting your draft onto the charter is actually not always the best op=
tion for a straight-forward but low priority/interest work. The individual =
submission track might be better for you and the WG. You might want to reac=
h out to one of the ADs or Chairs and discuss these options.

EH




From guang.g.yang@oracle.com  Wed Mar 14 22:41:31 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A7321F8703 for ; Wed, 14 Mar 2012 22:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrnJzQmTqtbR for ; Wed, 14 Mar 2012 22:41:30 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 048FF21F8702 for ; Wed, 14 Mar 2012 22:41:29 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2F5fPYg031015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Mar 2012 05:41:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2F5fPh1015896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Mar 2012 05:41:25 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2F5fPt2009531 for ; Thu, 15 Mar 2012 00:41:25 -0500
Reply-By: 
X-Message-Flag: 
MIME-Version: 1.0
Message-ID: <1db661c5-2e54-470e-8104-ee8e7ae10e86@default>
Date: Wed, 14 Mar 2012 22:41:23 -0700 (PDT)
From: Grant Yang 
Sender: Grant Yang 
To: oauth@ietf.org
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL 12.0.6607.1000 (x86)]
Content-Type: multipart/alternative; boundary="__1331790084807133949abhmt117.oracle.com"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F618106.0086,ss=1,re=0.000,fgs=0
Subject: [OAUTH-WG] Using Oauth2 token to SOAP web services
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 05:41:31 -0000

--__1331790084807133949abhmt117.oracle.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,=20

=C2=A0

We were discussing the possibility to use Oauth2 token on SOAP in our produ=
ct.=20

=C2=A0

The preferred way in mentioned in RFC is of course to put it to HTTP Author=
ization header, but in this case it will beyond the scope of SOAP stack and=
 I am not sure it shall be the correct way to go. It is also recognized tha=
t there is some implementation (such as salesforce) is using some SOAP head=
er (=E2=80=9CsessionId=E2=80=9D) to put this token, but it looks like a pri=
vate implementation and I did not find any specification supporting it.=20

=C2=A0

Could any experts here illustrate any organization or forum is working on u=
sing Oauth2 token for SOAP request? As there are quite some legacy SOAP bas=
ed web services, hopefully it is a question makes sense for you as well.

=C2=A0

Thoughts?

=C2=A0

Grant Yang

Architect, SDP of ORACLE Communications

=C2=A0

--__1331790084807133949abhmt117.oracle.com
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi all, 
 
We were discussing the possibility to use O=
auth2 token on SOAP in our product. 
 
The preferred way in mentioned in RFC is of course to put i=
t to HTTP Authorization header, but in this case it will beyond the scope o=
f SOAP stack and I am not sure it shall be the correct way to go. It is als=
o recognized that there is some implementation (such as salesforce) is usin=
g some SOAP header (“sessionId”) to put this token, but it look=
s like a private implementation and I did not find any specification suppor=
ting it. 
 
Could any e=
xperts here illustrate any organization or forum is working on using Oauth2=
 token for SOAP request? As there are quite some legacy SOAP based web serv=
ices, hopefully it is a question makes sense for you as well.
 
Thoughts?
 
Grant Yang
Architect, SDP of ORACLE Communications
 

--__1331790084807133949abhmt117.oracle.com--

From sakimura@gmail.com  Thu Mar 15 01:46:43 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF7421F8683 for ; Thu, 15 Mar 2012 01:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.164
X-Spam-Level: 
X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=0.434,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS2t8nJS7m7d for ; Thu, 15 Mar 2012 01:46:41 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33D2821F867C for ; Thu, 15 Mar 2012 01:46:41 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so2249300bku.31 for ; Thu, 15 Mar 2012 01:46:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HDWkOAXHHu0GCAqy/AOcMotd5SRpjJ3Zp/qhI2AuWKE=; b=PcIRA7iJRFNDYg6UBLg3YkDYBw+Kv3Pvwp2N5mD8RKxckIRacCO++smaF5ikSk7DFD tDZuVUiX4FSqRwPZCQHkIaldlkkvtRXSrlCGyycX+/8S1wMKAPPamU1Tem0GZGfCoZYk y8DLrgObCQ4jYCe/gwqg2anLXEb2tRX178Go0Eji5iwGz4MZk72Ri4zNQQvANvg9zMwt liqlThcU44NA96YwdlKOgX+bgbb7Qz9JQiDKOyP+s6P02PDVaTb+4/CW5qCuekfI+9UK jfoVrsm/qz3QVGYeN98dh05B41d7YDzH370r9Jk4WYqABAiqTBiKouoMhisKOHJboJ4k SdFA==
MIME-Version: 1.0
Received: by 10.204.130.81 with SMTP id r17mr2167733bks.118.1331801200179; Thu, 15 Mar 2012 01:46:40 -0700 (PDT)
Received: by 10.204.232.203 with HTTP; Thu, 15 Mar 2012 01:46:40 -0700 (PDT)
In-Reply-To: 
References:  <4F60FEDF.1030600@alcatel-lucent.com> 
Date: Thu, 15 Mar 2012 17:46:40 +0900
Message-ID: 
From: Nat Sakimura 
To: Anthony Nadalin 
Content-Type: multipart/alternative; boundary=00151747805c72b92604bb44210a
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 08:46:43 -0000

--00151747805c72b92604bb44210a
Content-Type: text/plain; charset=ISO-8859-1

Looks good but I would like the group to consider the capability of signing
the request to be added.

See  http://tools.ietf.org/html/draft-sakimura-oauth-requrl-01

It basically adds capability of signing the request in the form of JWS.


=nat

On Thu, Mar 15, 2012 at 7:51 AM, Anthony Nadalin wrote:

>   Agree contents looks good
>
> Sent from my Windows Phone
>  ------------------------------
> From: Igor Faynberg
> Sent: 3/14/2012 4:26 PM
> To: oauth@ietf.org
>
> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>
>  Looks good and comprehensive to me.
>
> Igor
>
> On 3/14/2012 4:21 PM, Hannes Tschofenig wrote:
> > So, here is a proposal:
> >
> > -------
> >
> > Web Authorization Protocol (oauth)
> >
> > Description of Working Group
> >
> > The Web Authorization (OAuth) protocol allows a user to grant
> > a third-party Web site or application access to the user's protected
> > resources, without necessarily revealing their long-term credentials,
> > or even their identity. For example, a photo-sharing site that supports
> > OAuth could allow its users to use a third-party printing Web site to
> > print their private pictures, without allowing the printing site to
> > gain full control of the user's account and without having the user
> > sharing his or her photo-sharing sites' long-term credential with the
> > printing site.
> >
> > The OAuth protocol suite encompasses
> > * a procedure for allowing a client to discover a resource server,
> > * a protocol for obtaining authorization tokens from an authorization
> > server with the resource owner's consent,
> > * protocols for presenting these authorization tokens to protected
> > resources for access to a resource, and
> > * consequently for sharing data in a security and privacy respective way.
> >
> > In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
> > was published as an informational document (RFC 5849). With the
> > completion of OAuth 1.0 the working group started their work on OAuth 2.0
> > to incorporate implementation experience with version 1.0, additional
> > use cases, and various other security, readability, and interoperability
> > improvements. An extensive security analysis was conducted and the result
> > is available as a stand-alone document offering guidance for audiences
> > beyond the community of protocol implementers.
> >
> > The working group also developed security schemes for presenting
> authorization
> > tokens to access a protected resource. This led to the publication of
> > the bearer token as well as the message authentication code (MAC) access
> > authentication specification.
> >
> > OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH
> token with
> > the SAML 2.0 bearer assertion profile.  This offers interworking with
> existing
> > identity management solutions, in particular SAML based deployments.
> >
> > OAuth has enjoyed widespread adoption by the Internet application
> service provider
> > community. To build on this success we aim for nothing more than to make
> OAuth the
> > authorization framework of choice for any Internet protocol.
> Consequently, the
> > ongoing standardization effort within the OAuth working group is focused
> on
> > enhancing interoperability of OAuth deployments. While the core OAuth
> specification
> > truly is an important building block it relies on other specifications
> in order to
> > claim completeness. Luckily, these components already exist and have
> been deployed
> > on the Internet. Through the IETF standards process they will be
> improved in
> > quality and will undergo a rigorous review process.
> >
> > Goals and Milestones
> >
> > [Editor's Note: Here are the completed items.]
> >
> > Done   Submit 'OAuth 2.0 Threat Model and Security Considerations' as a
> working group item
> > Done   Submit 'HTTP Authentication: MAC Authentication' as a working
> group item
> > Done   Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for
> consideration as a Proposed Standard
> > Done   Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for
> consideration as a Proposed Standard
> >
> > [Editor's Note: Finishing existing work. Double-check the proposed dates
> - are they realistic?]
> >
> > Jun. 2012      Submit 'HTTP Authentication: MAC Authentication' to the
> IESG for consideration as a Proposed Standard
> > Apr. 2012      Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0'
> to the IESG for consideration as a Proposed Standard
> > Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for
> consideration as a Proposed Standard
> > Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for
> consideration as a Proposed Standard
> > May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations'
> to the IESG for consideration as an Informational RFC
> >
> > [Editor's Note: New work for the group. 5 items maximum! ]
> >
> > Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as
> a Proposed Standard
> >
> > [Starting point for the work will be
> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
> >
> > Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration
> as a Proposed Standard
> >
> > [Starting point for the work will be
> http://tools.ietf.org/html/draft-jones-json-web-token]
> >
> > Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
> OAuth 2.0' to the IESG for consideration as a Proposed Standard
> >
> > [Starting point for the work will be
> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
> >
> > Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the
> IESG for consideration as a Proposed Standard
> >
> > [Starting point for the work will be
> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
> >
> > Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as
> an Informational RFC
> >
> > [Starting point for the work will be
> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
> >
> >
> >
> > _______________________________________________
> > 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
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--00151747805c72b92604bb44210a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Looks good but I would like the group to consider the capability of signing=
 the request to be added.=A0


<=
/div>
It basically adds capability of signing the request in the form o=
f JWS.=A0




=3Dnat

On Thu, Mar 15, 2012 at 7:51 AM, Anthony Nadalin <tonynad@microsoft.com> =
wrote:















Agree contents=
 looks good



Sent from my Windows Phone







From:
Igor Fa=
ynberg

Sent:
3/14/20=
12 4:26 PM

To:
oauth@ietf.org


Subject:
Re: [OA=
UTH-WG] OAuth WG Re-Chartering







Looks good and comprehensive to me.



Igor



On 3/14/2012 4:21 PM, Hannes Tschofenig wrote:

> So, here is a proposal:

>

> -------

>

> Web Authorization Protocol (oauth)

>

> Description of Working Group

>

> The Web Authorization (OAuth) protocol allows a user to grant

> a third-party Web site or application access to the user's protect=
ed

> resources, without necessarily revealing their long-term credentials,<=
br>
> or even their identity. For example, a photo-sharing site that support=
s

> OAuth could allow its users to use a third-party printing Web site to<=
br>
> print their private pictures, without allowing the printing site to
> gain full control of the user's account and without having the use=
r

> sharing his or her photo-sharing sites' long-term credential with =
the

> printing site.

>

> The OAuth protocol suite encompasses

> * a procedure for allowing a client to discover a resource server,

> * a protocol for obtaining authorization tokens from an authorization<=
br>
> server with the resource owner's consent,

> * protocols for presenting these authorization tokens to protected

> resources for access to a resource, and

> * consequently for sharing data in a security and privacy respective w=
ay.

>

> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,<=
br>
> was published as an informational document (RFC 5849). With the

> completion of OAuth 1.0 the working group started their work on OAuth =
2.0

> to incorporate implementation experience with version 1.0, additional<=
br>
> use cases, and various other security, readability, and interoperabili=
ty

> improvements. An extensive security analysis was conducted and the res=
ult

> is available as a stand-alone document offering guidance for audiences=


> beyond the community of protocol implementers.

>

> The working group also developed security schemes for presenting autho=
rization

> tokens to access a protected resource. This led to the publication of<=
br>
> the bearer token as well as the message authentication code (MAC) acce=
ss

> authentication specification.

>

> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH=
 token with

> the SAML 2.0 bearer assertion profile.=A0 This offers interworking wit=
h existing

> identity management solutions, in particular SAML based deployments.
>

> OAuth has enjoyed widespread adoption by the Internet application serv=
ice provider

> community. To build on this success we aim for nothing more than to ma=
ke OAuth the

> authorization framework of choice for any Internet protocol. Consequen=
tly, the

> ongoing standardization effort within the OAuth working group is focus=
ed on

> enhancing interoperability of OAuth deployments. While the core OAuth =
specification

> truly is an important building block it relies on other specifications=
 in order to

> claim completeness. Luckily, these components already exist and have b=
een deployed

> on the Internet. Through the IETF standards process they will be impro=
ved in

> quality and will undergo a rigorous review process.

>

> Goals and Milestones

>

> [Editor's Note: Here are the completed items.]

>

> Done=A0=A0 Submit 'OAuth 2.0 Threat Model and Security Considerati=
ons' as a working group item

> Done=A0=A0 Submit 'HTTP Authentication: MAC Authentication' as=
 a working group item

> Done=A0=A0 Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to t=
he IESG for consideration as a Proposed Standard

> Done=A0=A0 Submit 'The OAuth 2.0 Authorization Protocol' to th=
e IESG for consideration as a Proposed Standard

>

> [Editor's Note: Finishing existing work. Double-check the proposed=
 dates - are they realistic?]

>

> Jun. 2012=A0=A0=A0=A0=A0 Submit 'HTTP Authentication: MAC Authenti=
cation' to the IESG for consideration as a Proposed Standard

> Apr. 2012=A0=A0=A0=A0=A0 Submit 'SAML 2.0 Bearer Assertion Profile=
s for OAuth 2.0' to the IESG for consideration as a Proposed Standard
> Apr. 2012=A0 Submit 'OAuth 2.0 Assertion Profile' to the IESG =
for consideration as a Proposed Standard

> Apr. 2012=A0 Submit 'An IETF URN Sub-Namespace for OAuth' to t=
he IESG for consideration as a Proposed Standard

> May 2012=A0=A0=A0 Submit 'OAuth 2.0 Threat Model and Security Cons=
iderations' to the IESG for consideration as an Informational RFC

>

> [Editor's Note: New work for the group. 5 items maximum! ]

>

> Aug. 2012=A0=A0=A0 Submit 'Token Revocation' to the IESG for c=
onsideration as a Proposed Standard

>

> [Starting point for the work will be 
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
>

> Nov. 2012=A0=A0=A0 Submit 'JSON Web Token (JWT)' to the IESG f=
or consideration as a Proposed Standard

>

> [Starting point for the work will be 
http://tools.ietf.org/html/draft-jones-json-web-token]

>

> Nov. 2012=A0=A0=A0 Submit 'JSON Web Token (JWT) Bearer Token Profi=
les for OAuth 2.0' to the IESG for consideration as a Proposed Standard=


>

> [Starting point for the work will be 
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

>

> Jan. 2013=A0=A0=A0 Submit 'OAuth Dynamic Client Registration Proto=
col' to the IESG for consideration as a Proposed Standard

>

> [Starting point for the work will be 
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]

>

> Sep. 2012=A0=A0=A0 Submit 'OAuth Use Cases' to the IESG for co=
nsideration as an Informational RFC

>

> [Starting point for the work will be 
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]

>

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth














_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





-- 
Nat Saki=
mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=






--00151747805c72b92604bb44210a--

From sakimura@gmail.com  Thu Mar 15 02:03:32 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BDC21F86D4 for ; Thu, 15 Mar 2012 02:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.226
X-Spam-Level: 
X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.372,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA1lpa2qRvI0 for ; Thu, 15 Mar 2012 02:03:31 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4207421F86CB for ; Thu, 15 Mar 2012 02:03:31 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so2262009bku.31 for ; Thu, 15 Mar 2012 02:03:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qgIAfmoj0beuRNP92ZF8h9ZWNbwoVh/+tpCiWa9ANj0=; b=eSxXjbhyzed2VyaSnflYVasuH8tPQu2VPj6Bgae0oxjQWAhw/43uNU9xwhQjkC06NE ioF7ywucm1jKIckgAllmqL3y5cB216o8Y7pC9EwXMGmzIa2c4nsvVEQ4m4OVp3haDMFZ kR6noKtmLYWinZUKSr5RvCX0NRUxp604DV9J9nFcyuEGUzXnSwqiwj62Xt9oPGMigu4t fiqXlpPBeXR70ai0ZlKPJL+oCE8gwHo6wrwIqmDXA+Sq0MqwzmEJSnxxaJwwgyRJk7zr 5Wgha/VVzY4/7yJTLxIjB1LexaZVPMqK13ExEE0To0dQRS8xlF6nn5EqQB3B6LCyt5AN Ying==
MIME-Version: 1.0
Received: by 10.204.149.218 with SMTP id u26mr2210820bkv.82.1331802210353; Thu, 15 Mar 2012 02:03:30 -0700 (PDT)
Received: by 10.204.232.203 with HTTP; Thu, 15 Mar 2012 02:03:30 -0700 (PDT)
In-Reply-To: 
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF0896E@P3PW5EX1MB01.EX1.SECURESERVER.NET>  
Date: Thu, 15 Mar 2012 18:03:30 +0900
Message-ID: 
From: Nat Sakimura 
To: Breno de Medeiros , OAuth WG 
Content-Type: multipart/alternative; boundary=0015175cd0a2a8c13904bb445d40
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 09:03:32 -0000

--0015175cd0a2a8c13904bb445d40
Content-Type: text/plain; charset=ISO-8859-1

So, Eran's first proposal:

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex
clients.

kind of meets my concern. There seems to be another issue around the
usefulness of return_type in such case raised by Breno, and if I understand
it correctly, Eran's answer was that these separate components may have the
same client_id so that return_type is a valid parameter to be sent at the
request.

So, to clarify these, perhaps changing the above text slightly to the
following solves the problem?

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex
clients.
  Each component MAY have the same client_id, in which case the server
  judges the client type and the associated security context  based on
  the response_type parameter in the request.

Would it solve your problem, Breno?

Best,

=nat

--0015175cd0a2a8c13904bb445d40
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




So, Eran's first proposal:=A0

=A0 A client application consisting of multiple components, e=
ach with its
=A0 own client type (e.g. a distributed client with both a =
confidential

=A0 server-based component and a public browser-based component), MUST
=
=A0 register each component separately as a different client to ensure
<=
/div>=A0 proper handling by the authorization server, unless th=
e authorization

=A0 server provides other registration options to specify such =
complex clients.=A0

kind of meets my co=
ncern. There seems to be another issue around the usefulness of return_type=
 in such case raised by Breno, and if I understand it correctly, Eran's=
 answer was that these separate components may have the same client_id so t=
hat return_type is a valid parameter to be sent at the request.=A0



So, to clarify these, perhaps changing the above text s=
lightly to the following solves the problem?=A0

=A0 A client application consisting of multiple compo=
nents, each with its

=A0 own client type (e.g. a distributed client with both a confidential
=
=A0 server-based component and a public browser-based component), MUST
=
=A0 register each component separately as a different client to ensure
<=
/div>
=A0 proper handling by the authorization server, unless the aut=
horization
=A0 server provides other registrati=
on options to specify such complex clients.=A0=A0
=A0<=
font color=3D"#ff0000"> Each component MAY have the same client_id, in whic=
h case the server=A0


=A0 judges the client type and the associated =
security context =A0based on 
=A0 the response_type parameter in the req=
uest.=A0

Would it solve your problem, Breno=
?=A0



Best,=A0

=3Dnat

=



--0015175cd0a2a8c13904bb445d40--

From hannes.tschofenig@nsn.com  Thu Mar 15 02:03:35 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71CA21F86DB for ; Thu, 15 Mar 2012 02:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.405
X-Spam-Level: 
X-Spam-Status: No, score=-106.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5WLUk3zCs9L for ; Thu, 15 Mar 2012 02:03:35 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DE42C21F86DA for ; Thu, 15 Mar 2012 02:03:34 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2F93UDi030074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 10:03:31 +0100
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2F93RG9016535; Thu, 15 Mar 2012 10:03:30 +0100
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 15 Mar 2012 10:03:16 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 15 Mar 2012 11:03:14 +0200
Message-ID: <999913AB42CC9341B05A99BBF358718D0138296E@FIESEXC035.nsn-intra.net>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OAUTH-WG] Agenda Proposal
Thread-Index: Ac0CIIIc3nFnnki4T12JMlgUcSK2mAAadluQ
References: <30401997-7A6A-4306-B909-2EEAE80AA90D@gmx.net> 
From: "Tschofenig, Hannes (NSN - FI/Espoo)" 
To: "ext Barry Leiba" , "Hannes Tschofenig" 
X-OriginalArrivalTime: 15 Mar 2012 09:03:16.0385 (UTC) FILETIME=[7582A110:01CD028A]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 834
X-purgate-ID: 151667::1331802211-000033AC-9D1ABF42/0-0/0-0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 09:03:35 -0000

Thanks for the info, Barry.=20

I would, however, like to find an additional co-author from the group to
ensure accelerated process

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of ext Barry Leiba
> Sent: Wednesday, March 14, 2012 10:25 PM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Agenda Proposal
>=20
> Oh, and...
>=20
> > 4. MAC Token (TBD)
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/
>=20
> I believe that in Eran's last communication about this he said that he
> does, after all, have the time and inclination to finish it, and would
> like to.
>=20
> b
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From hannes.tschofenig@nsn.com  Thu Mar 15 02:08:10 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958E421F86B3 for ; Thu, 15 Mar 2012 02:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.408
X-Spam-Level: 
X-Spam-Status: No, score=-106.408 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6PySp1M8kmP for ; Thu, 15 Mar 2012 02:08:08 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 33BC821F860F for ; Thu, 15 Mar 2012 02:08:07 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2F985rx011578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 10:08:05 +0100
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2F983hE020551; Thu, 15 Mar 2012 10:08:04 +0100
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 15 Mar 2012 10:08:03 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD028B.1FF89CB7"
Date: Thu, 15 Mar 2012 11:08:01 +0200
Message-ID: <999913AB42CC9341B05A99BBF358718D0138297D@FIESEXC035.nsn-intra.net>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: Ac0CiGhNzxZc/mxIRfikRq37d7nFewAAoGeA
References: <4F60FEDF.1030600@alcatel-lucent.com> 
From: "Tschofenig, Hannes (NSN - FI/Espoo)" 
To: "ext Nat Sakimura" , "Anthony Nadalin" 
X-OriginalArrivalTime: 15 Mar 2012 09:08:03.0496 (UTC) FILETIME=[20A44A80:01CD028B]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 22611
X-purgate-ID: 151667::1331802485-000033AC-6E48C113/0-0/0-0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 09:08:10 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD028B.1FF89CB7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Nat,=20

=20

We currently have 5 new items proposed for the new charter. That's quite
a lot and I expect resistance from the IESG (given our previous history
of being somewhat slow with our work).=20

=20

If you want a new item something else has to be dropped instead.
Anything you do not find as important as the draft you mention below?

=20

Ciao
Hannes

=20

=20

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of ext Nat Sakimura
Sent: Thursday, March 15, 2012 10:47 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

=20

Looks good but I would like the group to consider the capability of
signing the request to be added.=20

=20

See  http://tools.ietf.org/html/draft-sakimura-oauth-requrl-01=20

=20

It basically adds capability of signing the request in the form of JWS.=20

=20

=20

=3Dnat

On Thu, Mar 15, 2012 at 7:51 AM, Anthony Nadalin 
wrote:

Agree contents looks good

Sent from my Windows Phone

________________________________

From: Igor Faynberg
Sent: 3/14/2012 4:26 PM
To: oauth@ietf.org


Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Looks good and comprehensive to me.

Igor

On 3/14/2012 4:21 PM, Hannes Tschofenig wrote:
> So, here is a proposal:
>
> -------
>
> Web Authorization Protocol (oauth)
>
> Description of Working Group
>
> The Web Authorization (OAuth) protocol allows a user to grant
> a third-party Web site or application access to the user's protected
> resources, without necessarily revealing their long-term credentials,
> or even their identity. For example, a photo-sharing site that
supports
> OAuth could allow its users to use a third-party printing Web site to
> print their private pictures, without allowing the printing site to
> gain full control of the user's account and without having the user
> sharing his or her photo-sharing sites' long-term credential with the
> printing site.
>
> The OAuth protocol suite encompasses
> * a procedure for allowing a client to discover a resource server,
> * a protocol for obtaining authorization tokens from an authorization
> server with the resource owner's consent,
> * protocols for presenting these authorization tokens to protected
> resources for access to a resource, and
> * consequently for sharing data in a security and privacy respective
way.
>
> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
> was published as an informational document (RFC 5849). With the
> completion of OAuth 1.0 the working group started their work on OAuth
2.0
> to incorporate implementation experience with version 1.0, additional
> use cases, and various other security, readability, and
interoperability
> improvements. An extensive security analysis was conducted and the
result
> is available as a stand-alone document offering guidance for audiences
> beyond the community of protocol implementers.
>
> The working group also developed security schemes for presenting
authorization
> tokens to access a protected resource. This led to the publication of
> the bearer token as well as the message authentication code (MAC)
access
> authentication specification.
>
> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH
token with
> the SAML 2.0 bearer assertion profile.  This offers interworking with
existing
> identity management solutions, in particular SAML based deployments.
>
> OAuth has enjoyed widespread adoption by the Internet application
service provider
> community. To build on this success we aim for nothing more than to
make OAuth the
> authorization framework of choice for any Internet protocol.
Consequently, the
> ongoing standardization effort within the OAuth working group is
focused on
> enhancing interoperability of OAuth deployments. While the core OAuth
specification
> truly is an important building block it relies on other specifications
in order to
> claim completeness. Luckily, these components already exist and have
been deployed
> on the Internet. Through the IETF standards process they will be
improved in
> quality and will undergo a rigorous review process.
>
> Goals and Milestones
>
> [Editor's Note: Here are the completed items.]
>
> Done   Submit 'OAuth 2.0 Threat Model and Security Considerations' as
a working group item
> Done   Submit 'HTTP Authentication: MAC Authentication' as a working
group item
> Done   Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for
consideration as a Proposed Standard
> Done   Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for
consideration as a Proposed Standard
>
> [Editor's Note: Finishing existing work. Double-check the proposed
dates - are they realistic?]
>
> Jun. 2012      Submit 'HTTP Authentication: MAC Authentication' to the
IESG for consideration as a Proposed Standard
> Apr. 2012      Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth
2.0' to the IESG for consideration as a Proposed Standard
> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for
consideration as a Proposed Standard
> Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG
for consideration as a Proposed Standard
> May 2012    Submit 'OAuth 2.0 Threat Model and Security
Considerations' to the IESG for consideration as an Informational RFC
>
> [Editor's Note: New work for the group. 5 items maximum! ]
>
> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration
as a Proposed Standard
>
> [Starting point for the work will be
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
>
> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
consideration as a Proposed Standard
>
> [Starting point for the work will be
http://tools.ietf.org/html/draft-jones-json-web-token]
>
> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
OAuth 2.0' to the IESG for consideration as a Proposed Standard
>
> [Starting point for the work will be
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
>
> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to
the IESG for consideration as a Proposed Standard
>
> [Starting point for the work will be
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
>
> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as
an Informational RFC
>
> [Starting point for the work will be
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





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





=20

--=20
Nat Sakimura (=3Dnat)

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

=20


------_=_NextPart_001_01CD028B.1FF89CB7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Nat, 
 
We currently have 5 new items proposed for the new charter. =
That’s quite a lot and I expect resistance from the IESG (given =
our previous history of being somewhat slow with our work). =

 
If you want a new item something else has to be dropped instead. =
Anything you do not find as important as the draft you mention =
below?
 
Ciao
Hannes
 
 
From:=
 =
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of =
ext Nat Sakimura
Sent: Thursday, March 15, 2012 10:47 =
AM
To: Anthony Nadalin
Cc: =
oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG =
Re-Chartering
 
Looks good =
but I would like the group to consider the capability of signing the =
request to be added. 
 
 
It basically adds capability of signing the request in =
the form of JWS. 
 
 
=3Dnat
On Thu, Mar 15, 2012 at 7:51 AM, Anthony Nadalin =
<tonynad@microsoft.com> =
wrote:
Agree =
contents looks good

Sent from my Windows =
Phone
From: =
Igor =
Faynberg
Sent: =
3/14/2012 =
4:26 PM
To: =
oauth@ietf.org

Subject: =
Re: =
[OAUTH-WG] OAuth WG =
Re-Chartering
Looks good and comprehensive to =
me.

Igor

On 3/14/2012 4:21 PM, Hannes Tschofenig =
wrote:
> So, here is a proposal:
>
> =
-------
>
> Web Authorization Protocol =
(oauth)
>
> Description of Working Group
>
> The =
Web Authorization (OAuth) protocol allows a user to grant
> a =
third-party Web site or application access to the user's =
protected
> resources, without necessarily revealing their =
long-term credentials,
> or even their identity. For example, a =
photo-sharing site that supports
> OAuth could allow its users to =
use a third-party printing Web site to
> print their private =
pictures, without allowing the printing site to
> gain full =
control of the user's account and without having the user
> =
sharing his or her photo-sharing sites' long-term credential with =
the
> printing site.
>
> The OAuth protocol suite =
encompasses
> * a procedure for allowing a client to discover a =
resource server,
> * a protocol for obtaining authorization tokens =
from an authorization
> server with the resource owner's =
consent,
> * protocols for presenting these authorization tokens =
to protected
> resources for access to a resource, and
> * =
consequently for sharing data in a security and privacy respective =
way.
>
> In April 2010 the OAuth 1.0 specification, =
documenting pre-IETF work,
> was published as an informational =
document (RFC 5849). With the
> completion of OAuth 1.0 the =
working group started their work on OAuth 2.0
> to incorporate =
implementation experience with version 1.0, additional
> use =
cases, and various other security, readability, and =
interoperability
> improvements. An extensive security analysis =
was conducted and the result
> is available as a stand-alone =
document offering guidance for audiences
> beyond the community of =
protocol implementers.
>
> The working group also developed =
security schemes for presenting authorization
> tokens to access a =
protected resource. This led to the publication of
> the bearer =
token as well as the message authentication code (MAC) access
> =
authentication specification.
>
> OAuth 2.0 added the =
ability to trade a SAML assertion against an OAUTH token with
> =
the SAML 2.0 bearer assertion profile.  This offers interworking =
with existing
> identity management solutions, in particular SAML =
based deployments.
>
> OAuth has enjoyed widespread adoption =
by the Internet application service provider
> community. To build =
on this success we aim for nothing more than to make OAuth the
> =
authorization framework of choice for any Internet protocol. =
Consequently, the
> ongoing standardization effort within the =
OAuth working group is focused on
> enhancing interoperability of =
OAuth deployments. While the core OAuth specification
> truly is =
an important building block it relies on other specifications in order =
to
> claim completeness. Luckily, these components already exist =
and have been deployed
> on the Internet. Through the IETF =
standards process they will be improved in
> quality and will =
undergo a rigorous review process.
>
> Goals and =
Milestones
>
> [Editor's Note: Here are the completed =
items.]
>
> Done   Submit 'OAuth 2.0 Threat Model =
and Security Considerations' as a working group item
> =
Done   Submit 'HTTP Authentication: MAC Authentication' as a =
working group item
> Done   Submit 'The OAuth 2.0 =
Protocol: Bearer Tokens' to the IESG for consideration as a Proposed =
Standard
> Done   Submit 'The OAuth 2.0 Authorization =
Protocol' to the IESG for consideration as a Proposed =
Standard
>
> [Editor's Note: Finishing existing work. =
Double-check the proposed dates - are they realistic?]
>
> =
Jun. 2012      Submit 'HTTP Authentication: MAC =
Authentication' to the IESG for consideration as a Proposed =
Standard
> Apr. 2012      Submit 'SAML =
2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for =
consideration as a Proposed Standard
> Apr. 2012  Submit =
'OAuth 2.0 Assertion Profile' to the IESG for consideration as a =
Proposed Standard
> Apr. 2012  Submit 'An IETF URN =
Sub-Namespace for OAuth' to the IESG for consideration as a Proposed =
Standard
> May 2012    Submit 'OAuth 2.0 Threat =
Model and Security Considerations' to the IESG for consideration as an =
Informational RFC
>
> [Editor's Note: New work for the =
group. 5 items maximum! ]
>
> Aug. 2012    =
Submit 'Token Revocation' to the IESG for consideration as a Proposed =
Standard
>
> [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth=
-revocation/]
>
> Nov. 2012    Submit =
'JSON Web Token (JWT)' to the IESG for consideration as a Proposed =
Standard
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]
>
> Nov. 2012    Submit 'JSON Web Token =
(JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration =
as a Proposed Standard
>
> [Starting point for the work will =
be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer=
]
>
> Jan. 2013    Submit 'OAuth Dynamic =
Client Registration Protocol' to the IESG for consideration as a =
Proposed Standard
>
> [Starting point for the work will be =
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg<=
/a>]
>
> Sep. 2012    Submit 'OAuth Use =
Cases' to the IESG for consideration as an Informational =
RFC
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-case=
s]
>
>
>
> =
_______________________________________________
> 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


 
-- =

Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=

 

------_=_NextPart_001_01CD028B.1FF89CB7--

From hannes.tschofenig@nsn.com  Thu Mar 15 02:10:41 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E3B21F84E7 for ; Thu, 15 Mar 2012 02:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.412
X-Spam-Level: 
X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMgzNXZx2BTo for ; Thu, 15 Mar 2012 02:10:37 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA1121F84B9 for ; Thu, 15 Mar 2012 02:10:36 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2F9AYDD019393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 10:10:34 +0100
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2F9ALPf029263; Thu, 15 Mar 2012 10:10:34 +0100
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 15 Mar 2012 10:10:31 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD028B.77AA6497"
Date: Thu, 15 Mar 2012 11:10:28 +0200
Message-ID: <999913AB42CC9341B05A99BBF358718D01382982@FIESEXC035.nsn-intra.net>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAMCRIf4APwgUm5DSot8V56SZZqRR3KgADM87A=
References:  <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" 
To: "ext Mike Jones" , "Hannes Tschofenig" , 
X-OriginalArrivalTime: 15 Mar 2012 09:10:31.0153 (UTC) FILETIME=[78A6F610:01CD028B]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 22305
X-purgate-ID: 151667::1331802634-000044A2-045412D3/0-0/0-0
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 09:10:41 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD028B.77AA6497
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Mike,=20

=20

The comment I sent to Nat applies here too. Something else has to be
dropped if we add another items.=20

=20

To respond to Eran's remark I will talk to the APPs ADs to figure out
whether OAuth is the right place to do this work. There are various
considerations that matter, including=20

*        In which group is the interested audience?=20

*        Where is the expertise?

*        Is there a natural place the work belongs to?=20

=20

Ciao
Hannes

=20

=20

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of ext Mike Jones
Sent: Wednesday, March 14, 2012 10:55 PM
To: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

=20

This is missing Simple Web Discovery, which there was substantial
support for including during the rechartering discussion in Taipei.
Considering OpenID Connect as a motivating use case for OAuth, SWD is
the one spec that would then be missing for this OAuth use case.

Please add it to the list.

Thanks,
-- Mike

________________________________

From: Hannes Tschofenig
Sent: 3/14/2012 1:21 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] OAuth WG Re-Chartering

So, here is a proposal:

-------

Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user=20
sharing his or her photo-sharing sites' long-term credential with the=20
printing site.=20

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server,=20
* a protocol for obtaining authorization tokens from an authorization=20
server with the resource owner's consent,=20
* protocols for presenting these authorization tokens to protected=20
resources for access to a resource, and=20
* consequently for sharing data in a security and privacy respective
way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the=20
completion of OAuth 1.0 the working group started their work on OAuth
2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the
result=20
is available as a stand-alone document offering guidance for audiences=20
beyond the community of protocol implementers.

The working group also developed security schemes for presenting
authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access

authentication specification.=20

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH
token with=20
the SAML 2.0 bearer assertion profile.  This offers interworking with
existing=20
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application
service provider=20
community. To build on this success we aim for nothing more than to make
OAuth the=20
authorization framework of choice for any Internet protocol.
Consequently, the=20
ongoing standardization effort within the OAuth working group is focused
on=20
enhancing interoperability of OAuth deployments. While the core OAuth
specification=20
truly is an important building block it relies on other specifications
in order to=20
claim completeness. Luckily, these components already exist and have
been deployed=20
on the Internet. Through the IETF standards process they will be
improved in=20
quality and will undergo a rigorous review process.=20

Goals and Milestones

[Editor's Note: Here are the completed items.]=20

Done     Submit 'OAuth 2.0 Threat Model and Security Considerations' as
a working group item
Done     Submit 'HTTP Authentication: MAC Authentication' as a working
group item
Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for
consideration as a Proposed Standard
Done     Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for
consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates
- are they realistic?]=20

Jun. 2012        Submit 'HTTP Authentication: MAC Authentication' to the
IESG for consideration as a Proposed Standard
Apr. 2012        Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth
2.0' to the IESG for consideration as a Proposed Standard
Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for
consideration as a Proposed Standard=20
Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for
consideration as a Proposed Standard=20
May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations'
to the IESG for consideration as an Informational RFC

[Editor's Note: New work for the group. 5 items maximum! ]

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as
a Proposed Standard

[Starting point for the work will be
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration
as a Proposed Standard

[Starting point for the work will be
http://tools.ietf.org/html/draft-jones-json-web-token]

Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
OAuth 2.0' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the
IESG for consideration as a Proposed Standard

[Starting point for the work will be
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]=20

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as
an Informational RFC

[Starting point for the work will be
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]=20



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


------_=_NextPart_001_01CD028B.77AA6497
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Mike, 
 
The comment I sent to Nat applies here too. Something else has to be =
dropped if we add another items. 
 
To respond to Eran’s remark I will talk to the APPs ADs to =
figure out whether OAuth is the right place to do this work. There are =
various considerations that matter, including 
·        =
In which group is the interested audience? 
·        =
Where is the expertise?
·        =
Is there a natural place the work belongs to? =

 
Ciao
Hannes
 
 
 
From:=
 =
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of =
ext Mike Jones
Sent: Wednesday, March 14, 2012 10:55 =
PM
To: Hannes Tschofenig; oauth@ietf.org WG
Subject: =
Re: [OAUTH-WG] OAuth WG =
Re-Chartering
 
This is =
missing Simple Web Discovery, which there was substantial support for =
including during the rechartering discussion in Taipei.  =
Considering OpenID Connect as a motivating use case for OAuth, SWD is =
the one spec that would then be missing for this OAuth use =
case.

Please add it to the list.

Thanks,
-- =
Mike
From: =
Hannes =
Tschofenig
Sent: =
3/14/2012 =
1:21 PM
To: =
oauth@ietf.org WG
Subject: =
[OAUTH-WG] =
OAuth WG Re-Chartering
So, here is a =
proposal:

-------

Web Authorization Protocol =
(oauth)

Description of Working Group

The Web Authorization =
(OAuth) protocol allows a user to grant
a third-party Web site or =
application access to the user's protected
resources, without =
necessarily revealing their long-term credentials,
or even their =
identity. For example, a photo-sharing site that supports
OAuth could =
allow its users to use a third-party printing Web site to
print their =
private pictures, without allowing the printing site to
gain full =
control of the user's account and without having the user 
sharing =
his or her photo-sharing sites' long-term credential with the =

printing site. 

The OAuth protocol suite encompasses
* a =
procedure for allowing a client to discover a resource server, 
* a =
protocol for obtaining authorization tokens from an authorization =

server with the resource owner's consent, 
* protocols for =
presenting these authorization tokens to protected 
resources for =
access to a resource, and 
* consequently for sharing data in a =
security and privacy respective way.

In April 2010 the OAuth 1.0 =
specification, documenting pre-IETF work,
was published as an =
informational document (RFC 5849). With the 
completion of OAuth 1.0 =
the working group started their work on OAuth 2.0
to incorporate =
implementation experience with version 1.0, additional
use cases, and =
various other security, readability, and =
interoperability
improvements. An extensive security analysis was =
conducted and the result 
is available as a stand-alone document =
offering guidance for audiences 
beyond the community of protocol =
implementers.

The working group also developed security schemes =
for presenting authorization
tokens to access a protected resource. =
This led to the publication of
the bearer token as well as the =
message authentication code (MAC) access 
authentication =
specification. 

OAuth 2.0 added the ability to trade a SAML =
assertion against an OAUTH token with 
the SAML 2.0 bearer assertion =
profile.  This offers interworking with existing 
identity =
management solutions, in particular SAML based deployments.

OAuth =
has enjoyed widespread adoption by the Internet application service =
provider 
community. To build on this success we aim for nothing more =
than to make OAuth the 
authorization framework of choice for any =
Internet protocol. Consequently, the 
ongoing standardization effort =
within the OAuth working group is focused on 
enhancing =
interoperability of OAuth deployments. While the core OAuth =
specification 
truly is an important building block it relies on =
other specifications in order to 
claim completeness. Luckily, these =
components already exist and have been deployed 
on the Internet. =
Through the IETF standards process they will be improved in 
quality =
and will undergo a rigorous review process. 

Goals and =
Milestones

[Editor's Note: Here are the completed items.] =


Done     Submit 'OAuth 2.0 Threat Model and =
Security Considerations' as a working group =
item
Done     Submit 'HTTP Authentication: MAC =
Authentication' as a working group item
Done     =
Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for =
consideration as a Proposed Standard
Done     =
Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for =
consideration as a Proposed Standard

[Editor's Note: Finishing =
existing work. Double-check the proposed dates - are they realistic?] =


Jun. 2012        Submit 'HTTP =
Authentication: MAC Authentication' to the IESG for consideration as a =
Proposed Standard
Apr. 2012        =
Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG =
for consideration as a Proposed Standard
Apr. 2012  Submit =
'OAuth 2.0 Assertion Profile' to the IESG for consideration as a =
Proposed Standard 
Apr. 2012  Submit 'An IETF URN Sub-Namespace =
for OAuth' to the IESG for consideration as a Proposed Standard 
May =
2012    Submit 'OAuth 2.0 Threat Model and Security =
Considerations' to the IESG for consideration as an Informational =
RFC

[Editor's Note: New work for the group. 5 items maximum! =
]

Aug. 2012    Submit 'Token Revocation' to the =
IESG for consideration as a Proposed Standard

[Starting point for =
the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Nov. 2012    Submit 'JSON Web Token (JWT)' to =
the IESG for consideration as a Proposed Standard

[Starting point =
for the work will be http://too=
ls.ietf.org/html/draft-jones-json-web-token]

Nov. =
2012    Submit 'JSON Web Token (JWT) Bearer Token =
Profiles for OAuth 2.0' to the IESG for consideration as a Proposed =
Standard

[Starting point for the work will be http://t=
ools.ietf.org/html/draft-jones-oauth-jwt-bearer]

Jan. =
2013    Submit 'OAuth Dynamic Client Registration =
Protocol' to the IESG for consideration as a Proposed =
Standard

[Starting point for the work will be http://to=
ols.ietf.org/html/draft-hardjono-oauth-dynreg] 

Sep. =
2012    Submit 'OAuth Use Cases' to the IESG for =
consideration as an Informational RFC

[Starting point for the =
work will be http://=
tools.ietf.org/html/draft-zeltsan-oauth-use-cases] =




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

------_=_NextPart_001_01CD028B.77AA6497--

From paul.madsen@gmail.com  Thu Mar 15 03:35:07 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A1121F8686 for ; Thu, 15 Mar 2012 03:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3plmTVr169P for ; Thu, 15 Mar 2012 03:35:06 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C362E21F8674 for ; Thu, 15 Mar 2012 03:35:05 -0700 (PDT)
Received: by iazz13 with SMTP id z13so4302528iaz.31 for ; Thu, 15 Mar 2012 03:35:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Djedg3UZh/Ffm913vGU8x8Ky5kp5C+qSe7zZRoAgjI8=; b=pXB68MZJQDrNpC9R0XfZ2d51jPeNUxFyhiXw3j+aeakcdqlU5czzK76R0gEFOP19V4 mZ4n2kunsQlPE4eHsjLlAutytURYIOIzYQmgvTYzT3pKWvaJZKWN+kdhOiHEaokS4mXM mAzPy5M2Gl0fYsjgD1I3V3nE+KcmKmHA1MVLzwTBXGvBmTCvN2IuzZvfHp+pWsSYjR0l ggNfLF2ghJA2/u16kZcg+nOd6qilP6xjOznBggP3L66eqSKlBtlCXMRl8l1myaUZQjo/ 9F7U2cU41tAsG5XNDR2almX0NFsXSkZKY7em1rGVdcED2ywJRn+sWs26NNyrbBpU3O57 2dQA==
Received: by 10.50.76.163 with SMTP id l3mr16174975igw.10.1331807705264; Thu, 15 Mar 2012 03:35:05 -0700 (PDT)
Received: from [192.168.2.22] (bas1-northbay04-2925117588.dsl.bell.ca. [174.89.192.148]) by mx.google.com with ESMTPS id uz5sm1164255igc.10.2012.03.15.03.35.03 (version=SSLv3 cipher=OTHER); Thu, 15 Mar 2012 03:35:04 -0700 (PDT)
Message-ID: <4F61C5D6.40106@gmail.com>
Date: Thu, 15 Mar 2012 06:35:02 -0400
From: Paul Madsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Richer, Justin P." 
References:  <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org>
In-Reply-To: <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org>
Content-Type: multipart/mixed; boundary="------------040103080902030206030208"
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 10:35:08 -0000

This is a multi-part message in MIME format.
--------------040103080902030206030208
Content-Type: multipart/alternative;
 boundary="------------080404030401070608000005"


--------------080404030401070608000005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

+1 to defining RS-AS interactions. We've implemented such a 'token 
introspection' endpoint in our AS and I'm be happy to no longer need to 
explain to customers/partners why it's not part of the standard.

As input, an (incomplete) spec for our endpoint enclosed. (we modeled 
the verification as a new grant type, leveraging as much as possible the 
existing token endpoint API)

Wrt the 5 item limit

1) is this an arbitrary #? if people sign up to work on more items, 
could it be extended?
2) the use cases document seems already well progressed (and 
informational). Need it count against the 5?

paul

On 3/14/12 5:53 PM, Richer, Justin P. wrote:
> Methods of connecting the PR to the AS are something that several groups have invented outside of the OAuth WG, and I think we should try to pull some of this work together. OAuth2 gives us a logical separation of the concerns but not a way to knit them back together.
>
> Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID, and several "token introspection" endpoints in various implementations.
>
>   -- Justin
>
> On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:
>
>> So, here is a proposal:
>>
>> -------
>>
>> Web Authorization Protocol (oauth)
>>
>> Description of Working Group
>>
>> The Web Authorization (OAuth) protocol allows a user to grant
>> a third-party Web site or application access to the user's protected
>> resources, without necessarily revealing their long-term credentials,
>> or even their identity. For example, a photo-sharing site that supports
>> OAuth could allow its users to use a third-party printing Web site to
>> print their private pictures, without allowing the printing site to
>> gain full control of the user's account and without having the user
>> sharing his or her photo-sharing sites' long-term credential with the
>> printing site.
>>
>> The OAuth protocol suite encompasses
>> * a procedure for allowing a client to discover a resource server,
>> * a protocol for obtaining authorization tokens from an authorization
>> server with the resource owner's consent,
>> * protocols for presenting these authorization tokens to protected
>> resources for access to a resource, and
>> * consequently for sharing data in a security and privacy respective way.
>>
>> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
>> was published as an informational document (RFC 5849). With the
>> completion of OAuth 1.0 the working group started their work on OAuth 2.0
>> to incorporate implementation experience with version 1.0, additional
>> use cases, and various other security, readability, and interoperability
>> improvements. An extensive security analysis was conducted and the result
>> is available as a stand-alone document offering guidance for audiences
>> beyond the community of protocol implementers.
>>
>> The working group also developed security schemes for presenting authorization
>> tokens to access a protected resource. This led to the publication of
>> the bearer token as well as the message authentication code (MAC) access
>> authentication specification.
>>
>> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with
>> the SAML 2.0 bearer assertion profile.  This offers interworking with existing
>> identity management solutions, in particular SAML based deployments.
>>
>> OAuth has enjoyed widespread adoption by the Internet application service provider
>> community. To build on this success we aim for nothing more than to make OAuth the
>> authorization framework of choice for any Internet protocol. Consequently, the
>> ongoing standardization effort within the OAuth working group is focused on
>> enhancing interoperability of OAuth deployments. While the core OAuth specification
>> truly is an important building block it relies on other specifications in order to
>> claim completeness. Luckily, these components already exist and have been deployed
>> on the Internet. Through the IETF standards process they will be improved in
>> quality and will undergo a rigorous review process.
>>
>> Goals and Milestones
>>
>> [Editor's Note: Here are the completed items.]
>>
>> Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item
>> Done 	Submit 'HTTP Authentication: MAC Authentication' as a working group item
>> Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard
>> Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard
>>
>> [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?]
>>
>> Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard
>> Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
>> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard
>> Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard
>> May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC
>>
>> [Editor's Note: New work for the group. 5 items maximum! ]
>>
>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard
>>
>> [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
>>
>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard
>>
>> [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]
>>
>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
>>
>> [Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
>>
>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
>>
>> [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
>>
>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC
>>
>> [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
>>
>>
>>
>> _______________________________________________
>> 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

--------------080404030401070608000005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1 to defining RS-AS interactions. We've
      implemented such a 'token introspection' endpoint in our AS and
      I'm be happy to no longer need to explain to customers/partners
      why it's not part of the standard.

      

      As input, an (incomplete) spec for our endpoint enclosed. (we
      modeled the verification as a new grant type, leveraging as much
      as possible the existing token endpoint API)

      

      Wrt the 5 item limit

      

      1) is this an arbitrary #? if people sign up to work on more
      items, could it be extended?

      2) the use cases document seems already well progressed (and
      informational). Need it count against the 5?

      

      paul

    

    On 3/14/12 5:53 PM, Richer, Justin P. wrote:
    

      
Methods of connecting the PR to the AS are something that several groups have invented outside of the OAuth WG, and I think we should try to pull some of this work together. OAuth2 gives us a logical separation of the concerns but not a way to knit them back together. 

Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID, and several "token introspection" endpoints in various implementations.

 -- Justin

On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:



      

        
So, here is a proposal:

-------

Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user 
sharing his or her photo-sharing sites' long-term credential with the 
printing site. 

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server, 
* a protocol for obtaining authorization tokens from an authorization 
server with the resource owner's consent, 
* protocols for presenting these authorization tokens to protected 
resources for access to a resource, and 
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the 
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result 
is available as a stand-alone document offering guidance for audiences 
beyond the community of protocol implementers.

The working group also developed security schemes for presenting authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access 
authentication specification. 

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with 
the SAML 2.0 bearer assertion profile.  This offers interworking with existing 
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application service provider 
community. To build on this success we aim for nothing more than to make OAuth the 
authorization framework of choice for any Internet protocol. Consequently, the 
ongoing standardization effort within the OAuth working group is focused on 
enhancing interoperability of OAuth deployments. While the core OAuth specification 
truly is an important building block it relies on other specifications in order to 
claim completeness. Luckily, these components already exist and have been deployed 
on the Internet. Through the IETF standards process they will be improved in 
quality and will undergo a rigorous review process. 

Goals and Milestones

[Editor's Note: Here are the completed items.] 

Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item
Done 	Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard
Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] 

Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard
Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard 
Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard 
May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC

[Editor's Note: New work for the group. 5 items maximum! ]

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]

Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] 

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC

[Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] 



_______________________________________________
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


    

  


--------------080404030401070608000005--

--------------040103080902030206030208
Content-Type: text/plain;
 name="ping-oauth-verification-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="ping-oauth-verification-01.txt"




                                                               P. Madsen
Internet-Draft                                       Ping Identity Corp.
Intended status: Informational                                 June 2011
Expires: December 3, 2011


           OAuth Authorization Server Verification Interface
                            verification.xml

Abstract

   This specification defines an interface by which a Resource Server,
   upon receiving an access token on a call from a Client, can verify
   with the issuing Authorization Server that the token is valid, and
   optionally, retrieve identity attributes associated with the
   corresponding Client and/or Resource Owner.

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 3, 2011.














Madsen                  Expires December 3, 2011                [Page 1]

Internet-Draft         Ping Identity Verification              June 2011


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . . . 3
   2.  Access Token Validation Request/Response  . . . . . . . . . . . 3
     2.1.  RS sends Validation Request . . . . . . . . . . . . . . . . 4
     2.2.  Validation Server sends Response  . . . . . . . . . . . . . 4
     2.3.  Example (non-normative) . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . . . 6
   Appendix B.  Document History . . . . . . . . . . . . . . . . . . . 6
   3.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7






































Madsen                  Expires December 3, 2011                [Page 2]

Internet-Draft         Ping Identity Verification              June 2011


1.  Introduction

   The OAuth 2.0 Authorization Protocol [I-D.ietf.oauth-v2] provides a
   method for making authenticated HTTP requests to a resource hosted by
   some Resource Server using an access token.  Access tokens are issued
   to third-party clients by an Authorization Server with the (sometimes
   implicit) approval of the resource owner.

   Depending on the nature of the access token, a Resource Server may
   not be able to directly verify/validate the access token and may need
   to interact with an Authorization Server in order to verify the
   token.

   This specification defines an interface by which a Resource Server,
   upon receiving an access token on a call from a Client, can verify
   with the issuing Authorization Server that the token is valid, and
   optionally, retrieve identity attributes associated with the
   corresponding Client and/or Resource Owner

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Unless otherwise noted, all the protocol parameter names and values
   are case sensitive.


2.  Access Token Validation Request/Response

   A Resource Server validates an access token by sending the token to
   an Authorization Server - as shown below.

   The validation endpoint interface profiles and extends that of the
   OAuth [I-D.ietf.oauth-v2] token endpoint, by defining a unique grant
   type and a format for the returned token.



        +--------+                                  +---------------+
        |        |                                  |               |
        |Resource|>--(A)----- access token    ----->| Authorization |
        | Server |                                  |     Server    |
        |        |<--(B)---- y/n + attributes  ----<|               |
        |        |                                  |               |
        +--------+                                  +---------------+




Madsen                  Expires December 3, 2011                [Page 3]

Internet-Draft         Ping Identity Verification              June 2011


            Figure 1: Access Token Validation Request/Response

   The request/response flow illustrated in Figure 1 includes the
   following steps:

   (A)  The RS sends an access token validation request to the
        Authorization Server that includes an access token and a
        grant_type of
        "urn:pingidentity.com:oauth2:grant_type:validate_bearer".

   (B)  The Authorization Server validates the access token and returns
        a list of attributes associated with the access token, formatted
        as JSON.

2.1.  RS sends Validation Request

   The client calls the Authorization Server with an access token
   request, the core details of which are defined in OAuth
   [I-D.ietf.oauth-v2] and by adding the following parameters:

   grant_type
         REQUIRED.  A value of
         "urn:pingidentity.com:oauth2:grant_type:validate_bearer"

   token
         REQUIRED.  The value of the access token for which validation
         is sought.

2.2.  Validation Server sends Response

   If validation was successful, the Authorization Server responds with
   a JSON formatted data structure with the following parameters at the
   top-level.

   token_type
         REQUIRED.  A value of 'ping_validated_token' indicates the
         access token was successfully validated.

   expires_in
         OPTIONAL.  The duration in seconds of the returned attributes.

   client_id
         OPTIONAL.  The client identifier of the client to whom the
         grant was originally issued.







Madsen                  Expires December 3, 2011                [Page 4]

Internet-Draft         Ping Identity Verification              June 2011


   access_token
         OPTIONAL.  A set of attributes.

   If validation was not successful, the Authorization Server responds
   with an OAuth error response with an error code of 'invalid grant'.

2.3.  Example (non-normative)

   The following examples illustrate access token validation request and
   responses.


GET /as/token.oauth2?client_id=a&client_secret=pwd&grant_type=urn:pingidentity.com:oauth2:grant_type:validate_bearer&token=5mZkmAoN6JjHREneyC7EuY8WdzGm1aRJaXT HTTP/1.1
Host: authz.example.net


                       Figure 2: Example GET Request



   HTTP/1.1 200 OK
   Content-Type: application/json; charset=UTF-8

   {"token_type":"ping_validated_token",
    "expires_in":"3600",
    "client_id":"a",
    "access_token":
       {"uid":"john",
        "fake-email":"john@example.cloud"}}


                   Figure 3: Example Successful Response



   HTTP/1.1 400 Bad Request
   Content-Type: application/json; charset=UTF-8

   {"error":"invalid_grant",
    "error_description":"token not found, expired or invalid"}


                  Figure 4: Example Unsuccessful Response








Madsen                  Expires December 3, 2011                [Page 5]

Internet-Draft         Ping Identity Verification              June 2011


Appendix A.  Contributors

   folks


Appendix B.  Document History

   [[ to be removed by RFC editor before publication as an RFC ]]


3.  Normative References

   [I-D.ietf.oauth-v2]
              Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "The
              OAuth 2.0 Authorization Protocol",
              ID draft-ietf-oauth-v2-16 (work in progress), July 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


Author's Address

   Paul Madsen
   Ping Identity Corp.

   Email: pmadsen@pingidentity.com
























Madsen                  Expires December 3, 2011                [Page 6]

Internet-Draft         Ping Identity Verification              June 2011


Full Copyright Statement

   Copyright (C) The IETF Trust (2011).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Madsen                  Expires December 3, 2011                [Page 7]


--------------040103080902030206030208--

From ve7jtb@ve7jtb.com  Thu Mar 15 03:38:55 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D6821F8523 for ; Thu, 15 Mar 2012 03:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4nD-XY-9Tt2 for ; Thu, 15 Mar 2012 03:38:55 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFB921F8532 for ; Thu, 15 Mar 2012 03:38:54 -0700 (PDT)
Received: by yenm5 with SMTP id m5so3264223yen.31 for ; Thu, 15 Mar 2012 03:38:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=dfKC+dTx7adxJfwP0o/XoD8yNPg37pLKFfO1faZZVHI=; b=I98aypHwgxnXNyvlMlWsJ5NzHrx//zYFJ83acHQpneUZg2m5TkbPUtwVY1j8hFrOa1 fekzRlI8siFw5nmoVzFdZDquyiF5uOoz3WU92tlBMZv+YSu7T4WDyillp/6/VLdhyMSz FlTS6kbhSk2XSQiPvmNNfjow3IaSIBBWRErYXWmpTDlCs3m3luiSDoOyKqKKICylrWBd zPJKwAme8dLIu6VvTjVofuXtmsAeNSMeChxbwSv97tbKBKGk6SISrxrCsuc3dthKsJgq 0Xr7fd5ReEV4gl5Jj/m+qzYhqwg6hD29Be9KNkeebjoQPFRES9Sh8N70DW0/fV1+Kqrf k+kQ==
Received: by 10.224.33.212 with SMTP id i20mr6882485qad.56.1331807934533; Thu, 15 Mar 2012 03:38:54 -0700 (PDT)
Received: from [10.71.4.224] ([67.201.77.8]) by mx.google.com with ESMTPS id hr2sm558468qab.8.2012.03.15.03.38.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 03:38:43 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_BCC24B9E-D70C-4CE3-A369-D8F31B72B790"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: 
Date: Thu, 15 Mar 2012 06:38:42 -0400
Message-Id: <261EEABF-6E72-4D7F-96F2-04C2C0FB5B93@ve7jtb.com>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF0896E@P3PW5EX1MB01.EX1.SECURESERVER.NET>   
To: Nat Sakimura 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnzTGdg2v5sXoSPfNQ98tdAI8kWNkcZt++LUAE3qjgnPZua3jWZN6gmxaJ55kNEDT3qS+Vw
Cc: Breno de Medeiros , OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 10:38:56 -0000

--Apple-Mail=_BCC24B9E-D70C-4CE3-A369-D8F31B72B790
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9175498C-BE24-4451-9A4C-391F9A047C5A"


--Apple-Mail=_9175498C-BE24-4451-9A4C-391F9A047C5A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

That seems to cover it.

My problem is that client registration has been treated largely as being =
out of scope other than some general principals.  We are now adding =
normative text, but still not specifying mechanisms.

Nat's text allows existing practice with complex clients like Facebook =
with 'token signed_request'  response_type.  =20

What exact mechanism one uses to register a confidential vs complex =
client is still out of scope and a bit of handwaving with a MUST.

John B.
On 2012-03-15, at 5:03 AM, Nat Sakimura wrote:

>=20
> So, Eran's first proposal:=20
>=20
>   A client application consisting of multiple components, each with =
its
>   own client type (e.g. a distributed client with both a confidential
>   server-based component and a public browser-based component), MUST
>   register each component separately as a different client to ensure
>   proper handling by the authorization server, unless the =
authorization
>   server provides other registration options to specify such complex =
clients.=20
>=20
> kind of meets my concern. There seems to be another issue around the =
usefulness of return_type in such case raised by Breno, and if I =
understand it correctly, Eran's answer was that these separate =
components may have the same client_id so that return_type is a valid =
parameter to be sent at the request.=20
>=20
> So, to clarify these, perhaps changing the above text slightly to the =
following solves the problem?=20
>=20
>   A client application consisting of multiple components, each with =
its
>   own client type (e.g. a distributed client with both a confidential
>   server-based component and a public browser-based component), MUST
>   register each component separately as a different client to ensure
>   proper handling by the authorization server, unless the =
authorization
>   server provides other registration options to specify such complex =
clients. =20
>   Each component MAY have the same client_id, in which case the server=20=

>   judges the client type and the associated security context  based on=20=

>   the response_type parameter in the request.=20
>=20
> Would it solve your problem, Breno?=20
>=20
> Best,=20
>=20
> =3Dnat
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_9175498C-BE24-4451-9A4C-391F9A047C5A
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

That seems to cover it.

My problem is that client registration has been treated largely as being out of scope other than some general principals.  We are now adding normative text, but still not specifying mechanisms.

Nat's text allows existing practice with complex clients like Facebook with 'token signed_request'  response_type.   

What exact mechanism one uses to register a confidential vs complex client is still out of scope and a bit of handwaving with a MUST.

John B.
On 2012-03-15, at 5:03 AM, Nat Sakimura wrote:




So, Eran's first proposal: 

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential

  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization

  server provides other registration options to specify such complex clients. 

kind of meets my concern. There seems to be another issue around the usefulness of return_type in such case raised by Breno, and if I understand it correctly, Eran's answer was that these separate components may have the same client_id so that return_type is a valid parameter to be sent at the request. 



So, to clarify these, perhaps changing the above text slightly to the following solves the problem? 

  A client application consisting of multiple components, each with its

  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure

  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex clients.  
  Each component MAY have the same client_id, in which case the server 


  judges the client type and the associated security context  based on 
  the response_type parameter in the request. 

Would it solve your problem, Breno? 



Best, 

=nat


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


--Apple-Mail=_9175498C-BE24-4451-9A4C-391F9A047C5A--

--Apple-Mail=_BCC24B9E-D70C-4CE3-A369-D8F31B72B790
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw
ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU
T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp
YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm
aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk
bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9
Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8
k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd
NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB
+rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK
7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV
HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B
MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h
Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt
ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD
b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p
dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh
dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa
MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw
Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG
AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI
KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50
LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF
BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3
Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz
lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy
Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3
toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG
SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt
YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ
A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ
gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1
13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU
euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/
MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB
nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp
MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9
BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh
LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js
LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB
VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv
aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh
cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM
ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5
IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw
EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF
AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p
ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4
ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB
9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT
e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW
0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+
BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw
vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ
x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW
yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr
DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz
MTUxMDM4NDJaMCMGCSqGSIb3DQEJBDEWBBQiE+Xn0Eyx2SEAYe0jqwL9bR/tWTCBpAYJKwYBBAGC
NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC
AQCdWVQjy4ExsMHu9m2qsYxeQBcmBhbBH3LN7bhFgBXZdcjAaZLV4+HSeAZaHXQjc5qmJTrQuJOk
NuhSsebC9+sMmseCki64pmHIa79v2Lu4vsn1yU1F/5s2ngRIMiNKUMQ4hgHfVza1HkykEtVYEt+7
V+uWG5ypAHjKy3a8X+AP3pKpKkI8ox5y7wKSzsUtRxs1PDklBhZkUk7+M9+YtceLaBY4cADWsBmw
IJffSW0kTKmqRHs1kmpZVR55qiB7O85n8QPjnlfTB8LE4bjoiZAL2gtN7/aF1gfzTCOhYnWs9eQC
seHYbPCYJrlzYktIeKfkb1MWeK240Rg4sPLMHFRmAAAAAAAA

--Apple-Mail=_BCC24B9E-D70C-4CE3-A369-D8F31B72B790--

From ve7jtb@ve7jtb.com  Thu Mar 15 03:49:17 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6203721F84EA for ; Thu, 15 Mar 2012 03:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CO5+x8lekWOA for ; Thu, 15 Mar 2012 03:49:16 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B89D021F8534 for ; Thu, 15 Mar 2012 03:49:15 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so237020yhk.31 for ; Thu, 15 Mar 2012 03:49:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=7MhhjoextuHBzhYc/axhIV3lKU3ugYJQKi0XFOtr4MU=; b=osZNrf+8X+pY7V0jV4w8YDILr6cZuHwYXuQRR4yzbNybQlFG2lMBB5MvyTHC9Q+qOg YADEAU4pg8w03piuiOeFTCcLHRGgDpWxPXpaVssCSENsQbebUyqI1ZzLuznVW31YGd6R quqvtnVE1SsKE6EOnaVna1PEy8YS1qTje1t8HT8NxKYiPNMCm4S2mOnIdMZOwMwpBD4x bJ73bIdxa3HCwHerbhqLy36wJpngEYPE9FMhMh7sLu8Tzob0sxA5srikvF0spqxtI1fv Z7xmT56IujLCUB5J0YKF6INS7Dtk6NNLlQTshNgNSfEQ7tUFGBXtpPBP0TrIvw8YyQ+N 1OUw==
Received: by 10.224.185.16 with SMTP id cm16mr7074478qab.0.1331808555279; Thu, 15 Mar 2012 03:49:15 -0700 (PDT)
Received: from [10.71.4.224] ([67.201.77.8]) by mx.google.com with ESMTPS id ef6sm3525275qab.7.2012.03.15.03.49.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 03:49:13 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_48127983-58C8-410E-B634-978547B0FB34"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <4F61C5D6.40106@gmail.com>
Date: Thu, 15 Mar 2012 06:49:12 -0400
Message-Id: 
References:  <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org> <4F61C5D6.40106@gmail.com>
To: Paul Madsen 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQk0cCPBGsdChZkyyYLzOdEB3RxUlWwkoVEROtDzYxWCpU/hsk5eV2XHHtEYvW1BwNyZR1MN
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 10:49:17 -0000

--Apple-Mail=_48127983-58C8-410E-B634-978547B0FB34
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CAA1580A-7E67-4709-A856-45D9BA8C0B31"


--Apple-Mail=_CAA1580A-7E67-4709-A856-45D9BA8C0B31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

+1 to RS-AS  OpenID Connect takes a slightly different approach to =
Paul's.  The fact that people are reinventing the same wheel,  indicates =
it has standardization potential.

John B.
On 2012-03-15, at 6:35 AM, Paul Madsen wrote:

> +1 to defining RS-AS interactions. We've implemented such a 'token =
introspection' endpoint in our AS and I'm be happy to no longer need to =
explain to customers/partners why it's not part of the standard.
>=20
> As input, an (incomplete) spec for our endpoint enclosed. (we modeled =
the verification as a new grant type, leveraging as much as possible the =
existing token endpoint API)
>=20
> Wrt the 5 item limit
>=20
> 1) is this an arbitrary #? if people sign up to work on more items, =
could it be extended?
> 2) the use cases document seems already well progressed (and =
informational). Need it count against the 5?
>=20
> paul
>=20
> On 3/14/12 5:53 PM, Richer, Justin P. wrote:
>>=20
>> Methods of connecting the PR to the AS are something that several =
groups have invented outside of the OAuth WG, and I think we should try =
to pull some of this work together. OAuth2 gives us a logical separation =
of the concerns but not a way to knit them back together.=20
>>=20
>> Proposals for inclusion in the discussion include UMA's Step 3, =
OpenID Connect's CheckID, and several "token introspection" endpoints in =
various implementations.
>>=20
>>  -- Justin
>>=20
>> On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:
>>=20
>>> So, here is a proposal:
>>>=20
>>> -------
>>>=20
>>> Web Authorization Protocol (oauth)
>>>=20
>>> Description of Working Group
>>>=20
>>> The Web Authorization (OAuth) protocol allows a user to grant
>>> a third-party Web site or application access to the user's protected
>>> resources, without necessarily revealing their long-term =
credentials,
>>> or even their identity. For example, a photo-sharing site that =
supports
>>> OAuth could allow its users to use a third-party printing Web site =
to
>>> print their private pictures, without allowing the printing site to
>>> gain full control of the user's account and without having the user=20=

>>> sharing his or her photo-sharing sites' long-term credential with =
the=20
>>> printing site.=20
>>>=20
>>> The OAuth protocol suite encompasses
>>> * a procedure for allowing a client to discover a resource server,=20=

>>> * a protocol for obtaining authorization tokens from an =
authorization=20
>>> server with the resource owner's consent,=20
>>> * protocols for presenting these authorization tokens to protected=20=

>>> resources for access to a resource, and=20
>>> * consequently for sharing data in a security and privacy respective =
way.
>>>=20
>>> In April 2010 the OAuth 1.0 specification, documenting pre-IETF =
work,
>>> was published as an informational document (RFC 5849). With the=20
>>> completion of OAuth 1.0 the working group started their work on =
OAuth 2.0
>>> to incorporate implementation experience with version 1.0, =
additional
>>> use cases, and various other security, readability, and =
interoperability
>>> improvements. An extensive security analysis was conducted and the =
result=20
>>> is available as a stand-alone document offering guidance for =
audiences=20
>>> beyond the community of protocol implementers.
>>>=20
>>> The working group also developed security schemes for presenting =
authorization
>>> tokens to access a protected resource. This led to the publication =
of
>>> the bearer token as well as the message authentication code (MAC) =
access=20
>>> authentication specification.=20
>>>=20
>>> OAuth 2.0 added the ability to trade a SAML assertion against an =
OAUTH token with=20
>>> the SAML 2.0 bearer assertion profile.  This offers interworking =
with existing=20
>>> identity management solutions, in particular SAML based deployments.
>>>=20
>>> OAuth has enjoyed widespread adoption by the Internet application =
service provider=20
>>> community. To build on this success we aim for nothing more than to =
make OAuth the=20
>>> authorization framework of choice for any Internet protocol. =
Consequently, the=20
>>> ongoing standardization effort within the OAuth working group is =
focused on=20
>>> enhancing interoperability of OAuth deployments. While the core =
OAuth specification=20
>>> truly is an important building block it relies on other =
specifications in order to=20
>>> claim completeness. Luckily, these components already exist and have =
been deployed=20
>>> on the Internet. Through the IETF standards process they will be =
improved in=20
>>> quality and will undergo a rigorous review process.=20
>>>=20
>>> Goals and Milestones
>>>=20
>>> [Editor's Note: Here are the completed items.]=20
>>>=20
>>> Done 	Submit 'OAuth 2.0 Threat Model and Security =
Considerations' as a working group item
>>> Done 	Submit 'HTTP Authentication: MAC Authentication' as a =
working group item
>>> Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the =
IESG for consideration as a Proposed Standard
>>> Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the =
IESG for consideration as a Proposed Standard
>>>=20
>>> [Editor's Note: Finishing existing work. Double-check the proposed =
dates - are they realistic?]=20
>>>=20
>>> Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the =
IESG for consideration as a Proposed Standard
>>> Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth =
2.0' to the IESG for consideration as a Proposed Standard
>>> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for =
consideration as a Proposed Standard=20
>>> Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG =
for consideration as a Proposed Standard=20
>>> May 2012    Submit 'OAuth 2.0 Threat Model and Security =
Considerations' to the IESG for consideration as an Informational RFC
>>>=20
>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>>=20
>>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration =
as a Proposed Standard
>>>=20
>>> [Starting point for the work will be =
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
>>>=20
>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for =
consideration as a Proposed Standard
>>>=20
>>> [Starting point for the work will be =
http://tools.ietf.org/html/draft-jones-json-web-token]
>>>=20
>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for =
OAuth 2.0' to the IESG for consideration as a Proposed Standard
>>>=20
>>> [Starting point for the work will be =
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
>>>=20
>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to =
the IESG for consideration as a Proposed Standard
>>>=20
>>> [Starting point for the work will be =
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]=20
>>>=20
>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration =
as an Informational RFC
>>>=20
>>> [Starting point for the work will be =
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]=20
>>>=20
>>>=20
>>>=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


--Apple-Mail=_CAA1580A-7E67-4709-A856-45D9BA8C0B31
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

+1 to RS-AS  OpenID Connect takes a slightly different approach to Paul's.  The fact that people are reinventing the same wheel,  indicates it has standardization potential.

John B.
On 2012-03-15, at 6:35 AM, Paul Madsen wrote:


  
    
  
  

    +1 to defining RS-AS interactions. We've
      implemented such a 'token introspection' endpoint in our AS and
      I'm be happy to no longer need to explain to customers/partners
      why it's not part of the standard.

      

      As input, an (incomplete) spec for our endpoint enclosed. (we
      modeled the verification as a new grant type, leveraging as much
      as possible the existing token endpoint API)

      

      Wrt the 5 item limit

      

      1) is this an arbitrary #? if people sign up to work on more
      items, could it be extended?

      2) the use cases document seems already well progressed (and
      informational). Need it count against the 5?

      

      paul

    

    On 3/14/12 5:53 PM, Richer, Justin P. wrote:
    

      
Methods of connecting the PR to the AS are something that several groups have invented outside of the OAuth WG, and I think we should try to pull some of this work together. OAuth2 gives us a logical separation of the concerns but not a way to knit them back together. 

Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID, and several "token introspection" endpoints in various implementations.

 -- Justin

On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:



      

        
So, here is a proposal:

-------

Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user 
sharing his or her photo-sharing sites' long-term credential with the 
printing site. 

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server, 
* a protocol for obtaining authorization tokens from an authorization 
server with the resource owner's consent, 
* protocols for presenting these authorization tokens to protected 
resources for access to a resource, and 
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the 
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result 
is available as a stand-alone document offering guidance for audiences 
beyond the community of protocol implementers.

The working group also developed security schemes for presenting authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access 
authentication specification. 

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with 
the SAML 2.0 bearer assertion profile.  This offers interworking with existing 
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application service provider 
community. To build on this success we aim for nothing more than to make OAuth the 
authorization framework of choice for any Internet protocol. Consequently, the 
ongoing standardization effort within the OAuth working group is focused on 
enhancing interoperability of OAuth deployments. While the core OAuth specification 
truly is an important building block it relies on other specifications in order to 
claim completeness. Luckily, these components already exist and have been deployed 
on the Internet. Through the IETF standards process they will be improved in 
quality and will undergo a rigorous review process. 

Goals and Milestones

[Editor's Note: Here are the completed items.] 

Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item
Done 	Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard
Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] 

Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard
Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard 
Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard 
May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC

[Editor's Note: New work for the group. 5 items maximum! ]

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]

Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] 

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC

[Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] 



_______________________________________________
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


    

  


<ping-oauth-verification-01.txt>_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_CAA1580A-7E67-4709-A856-45D9BA8C0B31--

--Apple-Mail=_48127983-58C8-410E-B634-978547B0FB34
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw
ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU
T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp
YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm
aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk
bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9
Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8
k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd
NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB
+rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK
7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV
HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B
MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h
Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt
ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD
b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p
dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh
dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa
MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw
Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG
AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI
KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50
LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF
BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3
Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz
lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy
Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3
toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG
SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt
YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ
A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ
gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1
13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU
euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/
MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB
nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp
MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9
BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh
LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js
LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB
VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv
aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh
cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM
ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5
IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw
EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF
AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p
ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4
ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB
9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT
e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW
0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+
BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw
vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ
x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW
yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr
DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz
MTUxMDQ5MTJaMCMGCSqGSIb3DQEJBDEWBBR4Fi8kyK9qTnW51nmM12EJPVnNvjCBpAYJKwYBBAGC
NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC
AQCUW4q1cS49aQ+ng73Kif3XF0O8cg7bq9v4qp8MI2AZfpnTUZAY7XXuvFMhY5DDYQAE+rsNFtz1
iGao2YTgPqYDcf+eKNq91JS5kQlV8Uwdd+m0COO4W87ee+CeSkCojuuNGzr2XMpHA8Lzlvu3U7K5
fVAL7RufT9X44YDepD38NoQAw+KKaWbiNyiD3TcDCJZm3TVegs0bTo55Rd/0Ocy4WPNmOx8a/POc
rJixWAea+8sjjk1ccUulkF1fa7E49xmC9nHthoR5JZ8vuYF2IlAtpFBqDR0gDtpoRrbFPl0LiKxS
qDqm9QQ1efYtZ8dcgyhmi4Z2gFavra8dPDzGvU8JAAAAAAAA

--Apple-Mail=_48127983-58C8-410E-B634-978547B0FB34--

From paul.madsen@gmail.com  Thu Mar 15 04:04:04 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180F021F84B8 for ; Thu, 15 Mar 2012 04:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uX+2p3II2jCp for ; Thu, 15 Mar 2012 04:04:02 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C97CE21F8496 for ; Thu, 15 Mar 2012 04:04:02 -0700 (PDT)
Received: by iazz13 with SMTP id z13so4345085iaz.31 for ; Thu, 15 Mar 2012 04:04:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Qynr3GWDnURW0pkO4orT5IWZrmtxWKESyv/2cr5UZok=; b=sxiCeVxc3Ss0WgP+DrTpF4RhOUgpCb/E2mC3NitmxFGelBgOFK7SB05olLN2mHCbu1 YSH5zOwDBxNV9lMHvPXX6iKkuSmCI+1xBe1n0bSYWWRox6p4v23Sybx9sWEWgu/yZJzd 4yqQstp9pLMZTCWaPSqQAtq3BpAA1oWNOq9SzYTfKJXTjMhKSP0qyxrS+rMvaVxyXnrO thWWFwmEYiZfLY50zq+k3+m/ZVaDy/ONV1AXuNme85Jihv3FH+rTM6feJFolZlh0hXGj 5F7QNGltZW/3H3orxeR/OE4mhx3Ws7xxBXfMqZDW5XA1+AMTrhrWF3ETucwaWC2HVwKT z8MQ==
Received: by 10.43.51.10 with SMTP id vg10mr6996241icb.11.1331809442175; Thu, 15 Mar 2012 04:04:02 -0700 (PDT)
Received: from [192.168.2.22] (bas1-northbay04-2925117588.dsl.bell.ca. [174.89.192.148]) by mx.google.com with ESMTPS id pr8sm1627295igb.6.2012.03.15.04.04.00 (version=SSLv3 cipher=OTHER); Thu, 15 Mar 2012 04:04:01 -0700 (PDT)
Message-ID: <4F61CCA0.7060006@gmail.com>
Date: Thu, 15 Mar 2012 07:04:00 -0400
From: Paul Madsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Eran Hammer 
References:  <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org> <90C41DD21FB7C64BB94121FBBC2E723453AFF08993@P3PW5EX1MB01.EX1.SECURESERVER.NET> <39E4BAA2-4DAC-4052-A716-025E298BDCCF@mitre.org> <90C41DD21FB7C64BB94121FBBC2E723453AFF089B0@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF089B0@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: multipart/alternative; boundary="------------020506030609050608080505"
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 11:04:04 -0000

This is a multi-part message in MIME format.
--------------020506030609050608080505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

To Eran's point about the relevance of RS-AS standardization in internal 
vs external deployments, many of our customers are using our AS to issue 
tokens to their API clients, but an API management solution (from 
different vendor) to front their APIs.

The API management soln becomes the RS and must validate the tokens it 
sees against our AS.

Until OAuth standardizes this piece, we have to convince such partners 
to use our (necessarily proprietary) endpoint (or support whatever 
mechanism they expect).

paul

On 3/15/12 1:19 AM, Eran Hammer wrote:
>
>> -----Original Message-----
>> From: Richer, Justin P. [mailto:jricher@mitre.org]
>> Sent: Wednesday, March 14, 2012 7:51 PM
>> [...] the AS-PR connection is a real and present known
>> gap introduced in OAuth2 (since OAuth1 didn't even think of them as
>> separate entities) and *somebody* should be trying to codify the best ways
>> to fill that gap and I think this is a good place to do it.
> I'm not sure this is an issue for more existing implementations given that it is just an internal implementation detail. It becomes more of a use case when you have different entities managing the different roles. I'm not objecting to this line of work, but I we do need a proposal and it should be based on something more than just ideas (e.g. some deployment experience). One of the benefit of starting off a draft and not just ideas is that it shows real interest and traction.
>
>> Along those lines, I don't think that SWD really belongs in the OAuth group
>> either *except* for the fact that there's a Discovery mandate below that
>> nobody's contesting. It's arguable that this simply covers the WWW-
>> Authenticate header and its value in different contexts, but we all know this
>> is incomplete discovery at best.
> Discovery is a very wide topic. The only discovery item proposed I the dynamic client registration proposal. It is fine to discuss potential discovery tools in this context, but we should not be the primary source of innovation in the space. So we're in agreement that SWD doesn't belong here. Nor does WebFinger which is working on similar problems.
>
> The ideal scenario would be to get traction on these general purpose discovery mechanisms elsewhere, and revisit this when the working group is discussing the dynamic client registration proposal. IOW, we may end up discussing and contributing to an APPS area discovery work to ensure our needs are supported, but not publish such documents in the WG.
>
>> JWT also doesn't feel like it really belongs
>> here, but since JOSE won't have it, it's a fairly important orphan that's already
>> seeing deployment experience.
> I don't have strong opinions on this, mostly because I understand it to be fairly finished. If the WG will need to spend a few months discussing it, I will have to reconsider.
>
>> Add to all of this that I have two other drafts that I'd like to see dusted off
>> and moved forward through some process -- alternate encoding (XML and
>> Form parameters) from the token endpoint, and the UX/dynreg related
>> "instance information" draft. I'll have versions of both of these uploaded
>> once the IETF tracker takes the locks off at the end of the month.
> I think the XML draft is simple enough to include. I've supported it in the last round. I think the UX work is actually really important if someone is willing to take the lead on that and do the work.
>
>> Neither of
>> these saw much WG feedback or support before, though, so I'm open to
>> suggestions of what a better home for them might be, if there is one. Or
>> maybe we should make a new group for all the orphaned open web specs?
> I think many people here don't fully understand the ways the IETF works. While working groups are the main venue for collaboration, there is a lot of work done on an Individual Submission basis (more than half?). This means a specification is created and finalized outside an official WG and without a charter.
>
> The general mechanism (at least as used pretty effectively by me for a handful of published RFCs) is to find the right mailing list (e.g. HTTP for Link relations, Apps Discuss for host-meta and well-known, OAuth for OAuth 1.0) and support from an Area Director. You also need to fine a document shepherd  to help review and help with the "paperwork".
>
> The way this works is that you can write a specification, discuss it on the WG list, and when you feel it is ready, ask the sponsoring AD for IETF Last Call. The AD might decide this is better suited to go through the full WG process, or feel that the document is simple and narrow enough to skip it. It is also possible that some of this work will be discussed on this list, but sponsored by an APPS area AD (e.g. the XML extension is a perfect example for something that is really not a security protocol component). So you have options.
>
> IOW, getting your draft onto the charter is actually not always the best option for a straight-forward but low priority/interest work. The individual submission track might be better for you and the WG. You might want to reach out to one of the ADs or Chairs and discuss these options.
>
> EH
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------020506030609050608080505
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    To Eran's point about the relevance of RS-AS
      standardization in internal vs external deployments, many of our
      customers are using our AS to issue tokens to their API clients,
      but an API management solution (from different vendor) to
    front their APIs. 

    

    The API management soln becomes the RS and must validate the tokens
    it sees against our AS. 

    

    Until OAuth standardizes this piece, we have to convince such
    partners to use our (necessarily proprietary) endpoint (or support
    whatever mechanism they expect).

    

    paul

    

    On 3/15/12 1:19 AM, Eran Hammer wrote:
    

      



      

        
-----Original Message-----
From: Richer, Justin P. [mailto:jricher@mitre.org]
Sent: Wednesday, March 14, 2012 7:51 PM


      

      

      

        
[...] the AS-PR connection is a real and present known
gap introduced in OAuth2 (since OAuth1 didn't even think of them as
separate entities) and *somebody* should be trying to codify the best ways
to fill that gap and I think this is a good place to do it.


      

      
I'm not sure this is an issue for more existing implementations given that it is just an internal implementation detail. It becomes more of a use case when you have different entities managing the different roles. I'm not objecting to this line of work, but I we do need a proposal and it should be based on something more than just ideas (e.g. some deployment experience). One of the benefit of starting off a draft and not just ideas is that it shows real interest and traction.
 


      

        
Along those lines, I don't think that SWD really belongs in the OAuth group
either *except* for the fact that there's a Discovery mandate below that
nobody's contesting. It's arguable that this simply covers the WWW-
Authenticate header and its value in different contexts, but we all know this
is incomplete discovery at best.


      

      
Discovery is a very wide topic. The only discovery item proposed I the dynamic client registration proposal. It is fine to discuss potential discovery tools in this context, but we should not be the primary source of innovation in the space. So we're in agreement that SWD doesn't belong here. Nor does WebFinger which is working on similar problems.

The ideal scenario would be to get traction on these general purpose discovery mechanisms elsewhere, and revisit this when the working group is discussing the dynamic client registration proposal. IOW, we may end up discussing and contributing to an APPS area discovery work to ensure our needs are supported, but not publish such documents in the WG.



      

        
JWT also doesn't feel like it really belongs
here, but since JOSE won't have it, it's a fairly important orphan that's already
seeing deployment experience.


      

      
I don't have strong opinions on this, mostly because I understand it to be fairly finished. If the WG will need to spend a few months discussing it, I will have to reconsider.



      

        
Add to all of this that I have two other drafts that I'd like to see dusted off
and moved forward through some process -- alternate encoding (XML and
Form parameters) from the token endpoint, and the UX/dynreg related
"instance information" draft. I'll have versions of both of these uploaded
once the IETF tracker takes the locks off at the end of the month. 


      

      
I think the XML draft is simple enough to include. I've supported it in the last round. I think the UX work is actually really important if someone is willing to take the lead on that and do the work.



      

        
Neither of
these saw much WG feedback or support before, though, so I'm open to
suggestions of what a better home for them might be, if there is one. Or
maybe we should make a new group for all the orphaned open web specs?


      

      
I think many people here don't fully understand the ways the IETF works. While working groups are the main venue for collaboration, there is a lot of work done on an Individual Submission basis (more than half?). This means a specification is created and finalized outside an official WG and without a charter.

The general mechanism (at least as used pretty effectively by me for a handful of published RFCs) is to find the right mailing list (e.g. HTTP for Link relations, Apps Discuss for host-meta and well-known, OAuth for OAuth 1.0) and support from an Area Director. You also need to fine a document shepherd  to help review and help with the "paperwork".

The way this works is that you can write a specification, discuss it on the WG list, and when you feel it is ready, ask the sponsoring AD for IETF Last Call. The AD might decide this is better suited to go through the full WG process, or feel that the document is simple and narrow enough to skip it. It is also possible that some of this work will be discussed on this list, but sponsored by an APPS area AD (e.g. the XML extension is a perfect example for something that is really not a security protocol component). So you have options.

IOW, getting your draft onto the charter is actually not always the best option for a straight-forward but low priority/interest work. The individual submission track might be better for you and the WG. You might want to reach out to one of the ADs or Chairs and discuss these options.

EH



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


    

  


--------------020506030609050608080505--

From hannes.tschofenig@nsn.com  Thu Mar 15 04:13:04 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9FE21F86D8 for ; Thu, 15 Mar 2012 04:13:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.415
X-Spam-Level: 
X-Spam-Status: No, score=-106.415 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmZx9YDDcDNJ for ; Thu, 15 Mar 2012 04:13:03 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2AD21F8621 for ; Thu, 15 Mar 2012 04:13:02 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2FBCxN6026286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 12:13:00 +0100
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2FBCpm5015935; Thu, 15 Mar 2012 12:12:59 +0100
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 15 Mar 2012 12:12:58 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD029C.935BF447"
Date: Thu, 15 Mar 2012 13:12:56 +0200
Message-ID: <999913AB42CC9341B05A99BBF358718D01382A8C@FIESEXC035.nsn-intra.net>
In-Reply-To: <4F61C5D6.40106@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: Ac0Cl04soRjDFLVvT4mopliBOcaT+wABQATw
References: <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org> <4F61C5D6.40106@gmail.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" 
To: "ext Paul Madsen" , "Richer, Justin P." 
X-OriginalArrivalTime: 15 Mar 2012 11:12:58.0882 (UTC) FILETIME=[943D6E20:01CD029C]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 23179
X-purgate-ID: 151667::1331809980-000044A2-9155E13F/0-0/0-0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 11:13:04 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD029C.935BF447
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Paul,=20

=20

Interesting stuff. Thanks for sharing your draft writeup with us.=20

=20

Could you submit the document as Internet Draft when the submission
gates open again?=20

The I-D submission tool will be reopened at 00h UTC, 2012-03-26.

=20

>From the current list of items what do you consider less important?

=20

Ciao

Hannes

=20

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of ext Paul Madsen
Sent: Thursday, March 15, 2012 12:35 PM
To: Richer, Justin P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

=20

+1 to defining RS-AS interactions. We've implemented such a 'token
introspection' endpoint in our AS and I'm be happy to no longer need to
explain to customers/partners why it's not part of the standard.

As input, an (incomplete) spec for our endpoint enclosed. (we modeled
the verification as a new grant type, leveraging as much as possible the
existing token endpoint API)

Wrt the 5 item limit

1) is this an arbitrary #? if people sign up to work on more items,
could it be extended?
2) the use cases document seems already well progressed (and
informational). Need it count against the 5?

paul

On 3/14/12 5:53 PM, Richer, Justin P. wrote:=20

Methods of connecting the PR to the AS are something that several groups
have invented outside of the OAuth WG, and I think we should try to pull
some of this work together. OAuth2 gives us a logical separation of the
concerns but not a way to knit them back together.=20
=20
Proposals for inclusion in the discussion include UMA's Step 3, OpenID
Connect's CheckID, and several "token introspection" endpoints in
various implementations.
=20
 -- Justin
=20
On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:
=20

	So, here is a proposal:
	=20
	-------
	=20
	Web Authorization Protocol (oauth)
	=20
	Description of Working Group
	=20
	The Web Authorization (OAuth) protocol allows a user to grant
	a third-party Web site or application access to the user's
protected
	resources, without necessarily revealing their long-term
credentials,
	or even their identity. For example, a photo-sharing site that
supports
	OAuth could allow its users to use a third-party printing Web
site to
	print their private pictures, without allowing the printing site
to
	gain full control of the user's account and without having the
user=20
	sharing his or her photo-sharing sites' long-term credential
with the=20
	printing site.=20
	=20
	The OAuth protocol suite encompasses
	* a procedure for allowing a client to discover a resource
server,=20
	* a protocol for obtaining authorization tokens from an
authorization=20
	server with the resource owner's consent,=20
	* protocols for presenting these authorization tokens to
protected=20
	resources for access to a resource, and=20
	* consequently for sharing data in a security and privacy
respective way.
	=20
	In April 2010 the OAuth 1.0 specification, documenting pre-IETF
work,
	was published as an informational document (RFC 5849). With the=20
	completion of OAuth 1.0 the working group started their work on
OAuth 2.0
	to incorporate implementation experience with version 1.0,
additional
	use cases, and various other security, readability, and
interoperability
	improvements. An extensive security analysis was conducted and
the result=20
	is available as a stand-alone document offering guidance for
audiences=20
	beyond the community of protocol implementers.
	=20
	The working group also developed security schemes for presenting
authorization
	tokens to access a protected resource. This led to the
publication of
	the bearer token as well as the message authentication code
(MAC) access=20
	authentication specification.=20
	=20
	OAuth 2.0 added the ability to trade a SAML assertion against an
OAUTH token with=20
	the SAML 2.0 bearer assertion profile.  This offers interworking
with existing=20
	identity management solutions, in particular SAML based
deployments.
	=20
	OAuth has enjoyed widespread adoption by the Internet
application service provider=20
	community. To build on this success we aim for nothing more than
to make OAuth the=20
	authorization framework of choice for any Internet protocol.
Consequently, the=20
	ongoing standardization effort within the OAuth working group is
focused on=20
	enhancing interoperability of OAuth deployments. While the core
OAuth specification=20
	truly is an important building block it relies on other
specifications in order to=20
	claim completeness. Luckily, these components already exist and
have been deployed=20
	on the Internet. Through the IETF standards process they will be
improved in=20
	quality and will undergo a rigorous review process.=20
	=20
	Goals and Milestones
	=20
	[Editor's Note: Here are the completed items.]=20
	=20
	Done     Submit 'OAuth 2.0 Threat Model and Security
Considerations' as a working group item
	Done     Submit 'HTTP Authentication: MAC Authentication' as a
working group item
	Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the
IESG for consideration as a Proposed Standard
	Done     Submit 'The OAuth 2.0 Authorization Protocol' to the
IESG for consideration as a Proposed Standard
	=20
	[Editor's Note: Finishing existing work. Double-check the
proposed dates - are they realistic?]=20
	=20
	Jun. 2012       Submit 'HTTP Authentication: MAC Authentication'
to the IESG for consideration as a Proposed Standard
	Apr. 2012       Submit 'SAML 2.0 Bearer Assertion Profiles for
OAuth 2.0' to the IESG for consideration as a Proposed Standard
	Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for
consideration as a Proposed Standard=20
	Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the
IESG for consideration as a Proposed Standard=20
	May 2012    Submit 'OAuth 2.0 Threat Model and Security
Considerations' to the IESG for consideration as an Informational RFC
	=20
	[Editor's Note: New work for the group. 5 items maximum! ]
	=20
	Aug. 2012    Submit 'Token Revocation' to the IESG for
consideration as a Proposed Standard
	=20
	[Starting point for the work will be
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
	=20
	Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
consideration as a Proposed Standard
	=20
	[Starting point for the work will be
http://tools.ietf.org/html/draft-jones-json-web-token]
	=20
	Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles
for OAuth 2.0' to the IESG for consideration as a Proposed Standard
	=20
	[Starting point for the work will be
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
	=20
	Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol'
to the IESG for consideration as a Proposed Standard
	=20
	[Starting point for the work will be
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]=20
	=20
	Sep. 2012    Submit 'OAuth Use Cases' to the IESG for
consideration as an Informational RFC
	=20
	[Starting point for the work will be
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]=20
	=20
	=20
	=20
	_______________________________________________
	OAuth mailing list
	OAuth@ietf.org
	https://www.ietf.org/mailman/listinfo/oauth

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

------_=_NextPart_001_01CD029C.935BF447
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Paul, 
 
Interesting stuff. Thanks for sharing your draft writeup with us. =

 
Could you submit the document as Internet Draft when the submission =
gates open again? 
The I-D submission tool will be reopened at 00h UTC, =
2012-03-26.
 
From the current list of items what do you consider less =
important?
 
Ciao
Hannes
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of ext Paul Madsen
Sent: Thursday, March 15, 2012 =
12:35 PM
To: Richer, Justin P.
Cc: oauth@ietf.org =
WG
Subject: Re: [OAUTH-WG] OAuth WG =
Re-Chartering
 
+1 to defining RS-AS =
interactions. We've implemented such a 'token introspection' endpoint in =
our AS and I'm be happy to no longer need to explain to =
customers/partners why it's not part of the standard.

As input, =
an (incomplete) spec for our endpoint enclosed. (we modeled the =
verification as a new grant type, leveraging as much as possible the =
existing token endpoint API)

Wrt the 5 item limit

1) is =
this an arbitrary #? if people sign up to work on more items, could it =
be extended?
2) the use cases document seems already well progressed =
(and informational). Need it count against the =
5?

paul

On 3/14/12 5:53 PM, Richer, Justin P. =
wrote: 
Methods of connecting the PR to the AS are =
something that several groups have invented outside of the OAuth WG, and =
I think we should try to pull some of this work together. OAuth2 gives =
us a logical separation of the concerns but not a way to knit them back =
together. 
 
Proposals =
for inclusion in the discussion include UMA's Step 3, OpenID Connect's =
CheckID, and several "token introspection" endpoints in =
various =
implementations.
 
 -- =
Justin
 
On Mar 14, 2012, =
at 4:21 PM, Hannes Tschofenig =
wrote:
 
So, here is a =
proposal:
 
-------
 
Web Authorization Protocol =
(oauth)
 
Description of =
Working Group
 
The Web =
Authorization (OAuth) protocol allows a user to =
grant
a third-party Web site or application access =
to the user's protected
resources, without =
necessarily revealing their long-term =
credentials,
or even their identity. For example, a =
photo-sharing site that supports
OAuth could allow =
its users to use a third-party printing Web site =
to
print their private pictures, without allowing =
the printing site to
gain full control of the =
user's account and without having the user 
sharing =
his or her photo-sharing sites' long-term credential with the =

printing site. =

 
The OAuth protocol =
suite encompasses
* a procedure for allowing a =
client to discover a resource server, 
* a protocol =
for obtaining authorization tokens from an authorization =

server with the resource owner's consent, =

* protocols for presenting these authorization =
tokens to protected 
resources for access to a =
resource, and 
* consequently for sharing data in a =
security and privacy respective =
way.
 
In April 2010 the =
OAuth 1.0 specification, documenting pre-IETF =
work,
was published as an informational document =
(RFC 5849). With the 
completion of OAuth 1.0 the =
working group started their work on OAuth 2.0
to =
incorporate implementation experience with version 1.0, =
additional
use cases, and various other security, =
readability, and interoperability
improvements. An =
extensive security analysis was conducted and the result =

is available as a stand-alone document offering =
guidance for audiences 
beyond the community of =
protocol =
implementers.
 
The =
working group also developed security schemes for presenting =
authorization
tokens to access a protected =
resource. This led to the publication of
the bearer =
token as well as the message authentication code (MAC) access =

authentication specification. =

 
OAuth 2.0 added the =
ability to trade a SAML assertion against an OAUTH token with =

the SAML 2.0 bearer assertion profile.  This =
offers interworking with existing 
identity =
management solutions, in particular SAML based =
deployments.
 
OAuth has =
enjoyed widespread adoption by the Internet application service provider =

community. To build on this success we aim for =
nothing more than to make OAuth the 
authorization =
framework of choice for any Internet protocol. Consequently, the =

ongoing standardization effort within the OAuth =
working group is focused on 
enhancing =
interoperability of OAuth deployments. While the core OAuth =
specification 
truly is an important building block =
it relies on other specifications in order to =

claim completeness. Luckily, these components =
already exist and have been deployed 
on the =
Internet. Through the IETF standards process they will be improved in =

quality and will undergo a rigorous review =
process. 
 
Goals and =
Milestones
 
[Editor's =
Note: Here are the completed items.] =

 
Done =
    Submit 'OAuth 2.0 Threat Model and Security =
Considerations' as a working group item
Done =
    Submit 'HTTP Authentication: MAC Authentication' as a =
working group item
Done     Submit =
'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as =
a Proposed Standard
Done     Submit =
'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as =
a Proposed =
Standard
 
[Editor's =
Note: Finishing existing work. Double-check the proposed dates - are =
they realistic?] 
 
Jun. =
2012       Submit 'HTTP Authentication: MAC =
Authentication' to the IESG for consideration as a Proposed =
Standard
Apr. 2012       =
Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG =
for consideration as a Proposed Standard
Apr. =
2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for =
consideration as a Proposed Standard 
Apr. =
2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for =
consideration as a Proposed Standard 
May =
2012    Submit 'OAuth 2.0 Threat Model and Security =
Considerations' to the IESG for consideration as an Informational =
RFC
 
[Editor's Note: New =
work for the group. 5 items maximum! =
]
 
Aug. =
2012    Submit 'Token Revocation' to the IESG for =
consideration as a Proposed =
Standard
 
[Starting =
point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
 
Nov. =
2012    Submit 'JSON Web Token (JWT)' to the IESG for =
consideration as a Proposed =
Standard
 
[Starting =
point for the work will be http://too=
ls.ietf.org/html/draft-jones-json-web-token]
 
Nov. 2012    Submit 'JSON Web =
Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for =
consideration as a Proposed =
Standard
 
[Starting =
point for the work will be http://t=
ools.ietf.org/html/draft-jones-oauth-jwt-bearer]
 
Jan. 2013    Submit 'OAuth =
Dynamic Client Registration Protocol' to the IESG for consideration as a =
Proposed =
Standard
 
[Starting =
point for the work will be http://to=
ols.ietf.org/html/draft-hardjono-oauth-dynreg] =

 
Sep. =
2012    Submit 'OAuth Use Cases' to the IESG for =
consideration as an Informational =
RFC
 
[Starting point for =
the work will be http://=
tools.ietf.org/html/draft-zeltsan-oauth-use-cases] =

 
 
=

 
________________________________________=
_______
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_001_01CD029C.935BF447--

From ve7jtb@ve7jtb.com  Thu Mar 15 04:26:13 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62D321F8630 for ; Thu, 15 Mar 2012 04:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL4lquWePc1N for ; Thu, 15 Mar 2012 04:26:12 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5478621F861D for ; Thu, 15 Mar 2012 04:26:12 -0700 (PDT)
Received: by yenm5 with SMTP id m5so3315514yen.31 for ; Thu, 15 Mar 2012 04:26:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=4AiPi/BoiDo4lLh28zpnif2L5ysrV3jt925N4GUN5GM=; b=EO6PQGzi98T36X5AKgZjNevuZ4Pw4SMZen+XS0JtlU5BHhU0euJeBb+14Tf/BZgpTT mTg48OS7s+RahdraqS4bqPqtvOCPe8IV7wKURpq0TI34aEo4UP0pg5F89uR/xF+r1QKk 9vvgm9xlhOHVZkVd8slaauo1yD8DRtz4xRGRCMsTkRrcpqM2bolOHpKTU6YOrsP/1E2S ZlJ2tMQ48xlUlYhH1L/N8A2ZEOkSO+nRofUYgJXq8XgEjs9KKbTYRgCvR1rmcwkAw08v /iH2wW4Wm10VfwtJV76Wo5gbA//xTEn6R/+YWIdEtGmjEK1DPqpLj8JN8zNOaeKzG1a4 3N+w==
Received: by 10.224.18.143 with SMTP id w15mr7012273qaa.90.1331810771683; Thu, 15 Mar 2012 04:26:11 -0700 (PDT)
Received: from [10.71.4.224] ([67.201.77.8]) by mx.google.com with ESMTPS id g16sm3665189qah.6.2012.03.15.04.26.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 04:26:10 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_10872BAC-EC0C-4225-B1C4-3F2109B71344"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <4F61CCA0.7060006@gmail.com>
Date: Thu, 15 Mar 2012 07:26:09 -0400
Message-Id: <11B228BD-3A18-4EDA-A1C9-511D4DB85FFE@ve7jtb.com>
References:  <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org> <90C41DD21FB7C64BB94121FBBC2E723453AFF08993@P3PW5EX1MB01.EX1.SECURESERVER.NET> <39E4BAA2-4DAC-4052-A716-025E298BDCCF@mitre.org> <90C41DD21FB7C64BB94121FBBC2E723453AFF089B0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F61CCA0.7060006@gmail.com>
To: Paul Madsen 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQleq1++eI4134ATh4tC8oMJZpPSg4XazRF9voglhyk65iB8+yuiI/jPOxDYVnINTMNHimDt
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 11:26:13 -0000

--Apple-Mail=_10872BAC-EC0C-4225-B1C4-3F2109B71344
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E96ACF91-1D29-4A18-AA6F-DCCBA300D866"


--Apple-Mail=_E96ACF91-1D29-4A18-AA6F-DCCBA300D866
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

In Connect it is mostly the client that introspects the token, though we =
do use JWT to keep things stateless.

As we move to more complex environments where clients are getting =
multiple tokens from a AS for RS and those RS are decoupled from the AS, =
 we need to talk about JWT and introspection.

They will become blocking issues for interoperability at larger scale.

John B.
On 2012-03-15, at 7:04 AM, Paul Madsen wrote:

> To Eran's point about the relevance of RS-AS standardization in =
internal vs external deployments, many of our customers are using our AS =
to issue tokens to their API clients, but an API management solution =
(from different vendor) to front their APIs.=20
>=20
> The API management soln becomes the RS and must validate the tokens it =
sees against our AS.=20
>=20
> Until OAuth standardizes this piece, we have to convince such partners =
to use our (necessarily proprietary) endpoint (or support whatever =
mechanism they expect).
>=20
> paul
>=20
> On 3/15/12 1:19 AM, Eran Hammer wrote:
>>=20
>>=20
>>> -----Original Message-----
>>> From: Richer, Justin P. [mailto:jricher@mitre.org]
>>> Sent: Wednesday, March 14, 2012 7:51 PM
>>> [...] the AS-PR connection is a real and present known
>>> gap introduced in OAuth2 (since OAuth1 didn't even think of them as
>>> separate entities) and *somebody* should be trying to codify the =
best ways
>>> to fill that gap and I think this is a good place to do it.
>> I'm not sure this is an issue for more existing implementations given =
that it is just an internal implementation detail. It becomes more of a =
use case when you have different entities managing the different roles. =
I'm not objecting to this line of work, but I we do need a proposal and =
it should be based on something more than just ideas (e.g. some =
deployment experience). One of the benefit of starting off a draft and =
not just ideas is that it shows real interest and traction.
>> =20
>>> Along those lines, I don't think that SWD really belongs in the =
OAuth group
>>> either *except* for the fact that there's a Discovery mandate below =
that
>>> nobody's contesting. It's arguable that this simply covers the WWW-
>>> Authenticate header and its value in different contexts, but we all =
know this
>>> is incomplete discovery at best.
>> Discovery is a very wide topic. The only discovery item proposed I =
the dynamic client registration proposal. It is fine to discuss =
potential discovery tools in this context, but we should not be the =
primary source of innovation in the space. So we're in agreement that =
SWD doesn't belong here. Nor does WebFinger which is working on similar =
problems.
>>=20
>> The ideal scenario would be to get traction on these general purpose =
discovery mechanisms elsewhere, and revisit this when the working group =
is discussing the dynamic client registration proposal. IOW, we may end =
up discussing and contributing to an APPS area discovery work to ensure =
our needs are supported, but not publish such documents in the WG.
>>=20
>>> JWT also doesn't feel like it really belongs
>>> here, but since JOSE won't have it, it's a fairly important orphan =
that's already
>>> seeing deployment experience.
>> I don't have strong opinions on this, mostly because I understand it =
to be fairly finished. If the WG will need to spend a few months =
discussing it, I will have to reconsider.
>>=20
>>> Add to all of this that I have two other drafts that I'd like to see =
dusted off
>>> and moved forward through some process -- alternate encoding (XML =
and
>>> Form parameters) from the token endpoint, and the UX/dynreg related
>>> "instance information" draft. I'll have versions of both of these =
uploaded
>>> once the IETF tracker takes the locks off at the end of the month.=20=

>> I think the XML draft is simple enough to include. I've supported it =
in the last round. I think the UX work is actually really important if =
someone is willing to take the lead on that and do the work.
>>=20
>>> Neither of
>>> these saw much WG feedback or support before, though, so I'm open to
>>> suggestions of what a better home for them might be, if there is =
one. Or
>>> maybe we should make a new group for all the orphaned open web =
specs?
>> I think many people here don't fully understand the ways the IETF =
works. While working groups are the main venue for collaboration, there =
is a lot of work done on an Individual Submission basis (more than =
half?). This means a specification is created and finalized outside an =
official WG and without a charter.
>>=20
>> The general mechanism (at least as used pretty effectively by me for =
a handful of published RFCs) is to find the right mailing list (e.g. =
HTTP for Link relations, Apps Discuss for host-meta and well-known, =
OAuth for OAuth 1.0) and support from an Area Director. You also need to =
fine a document shepherd  to help review and help with the "paperwork".
>>=20
>> The way this works is that you can write a specification, discuss it =
on the WG list, and when you feel it is ready, ask the sponsoring AD for =
IETF Last Call. The AD might decide this is better suited to go through =
the full WG process, or feel that the document is simple and narrow =
enough to skip it. It is also possible that some of this work will be =
discussed on this list, but sponsored by an APPS area AD (e.g. the XML =
extension is a perfect example for something that is really not a =
security protocol component). So you have options.
>>=20
>> IOW, getting your draft onto the charter is actually not always the =
best option for a straight-forward but low priority/interest work. The =
individual submission track might be better for you and the WG. You =
might want to reach out to one of the ADs or Chairs and discuss these =
options.
>>=20
>> EH
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_E96ACF91-1D29-4A18-AA6F-DCCBA300D866
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

In Connect it is mostly the client that introspects the token, though we do use JWT to keep things stateless.

As we move to more complex environments where clients are getting multiple tokens from a AS for RS and those RS are decoupled from the AS,  we need to talk about JWT and introspection.

They will become blocking issues for interoperability at larger scale.

John B.
On 2012-03-15, at 7:04 AM, Paul Madsen wrote:


  
    
  
  

    To Eran's point about the relevance of RS-AS
      standardization in internal vs external deployments, many of our
      customers are using our AS to issue tokens to their API clients,
      but an API management solution (from different vendor) to
    front their APIs. 

    

    The API management soln becomes the RS and must validate the tokens
    it sees against our AS. 

    

    Until OAuth standardizes this piece, we have to convince such
    partners to use our (necessarily proprietary) endpoint (or support
    whatever mechanism they expect).

    

    paul

    

    On 3/15/12 1:19 AM, Eran Hammer wrote:
    

      

      

        
-----Original Message-----
From: Richer, Justin P. [mailto:jricher@mitre.org]
Sent: Wednesday, March 14, 2012 7:51 PM


      

      

      

        
[...] the AS-PR connection is a real and present known
gap introduced in OAuth2 (since OAuth1 didn't even think of them as
separate entities) and *somebody* should be trying to codify the best ways
to fill that gap and I think this is a good place to do it.


      

      
I'm not sure this is an issue for more existing implementations given that it is just an internal implementation detail. It becomes more of a use case when you have different entities managing the different roles. I'm not objecting to this line of work, but I we do need a proposal and it should be based on something more than just ideas (e.g. some deployment experience). One of the benefit of starting off a draft and not just ideas is that it shows real interest and traction.
 


      

        
Along those lines, I don't think that SWD really belongs in the OAuth group
either *except* for the fact that there's a Discovery mandate below that
nobody's contesting. It's arguable that this simply covers the WWW-
Authenticate header and its value in different contexts, but we all know this
is incomplete discovery at best.


      

      
Discovery is a very wide topic. The only discovery item proposed I the dynamic client registration proposal. It is fine to discuss potential discovery tools in this context, but we should not be the primary source of innovation in the space. So we're in agreement that SWD doesn't belong here. Nor does WebFinger which is working on similar problems.

The ideal scenario would be to get traction on these general purpose discovery mechanisms elsewhere, and revisit this when the working group is discussing the dynamic client registration proposal. IOW, we may end up discussing and contributing to an APPS area discovery work to ensure our needs are supported, but not publish such documents in the WG.



      

        
JWT also doesn't feel like it really belongs
here, but since JOSE won't have it, it's a fairly important orphan that's already
seeing deployment experience.


      

      
I don't have strong opinions on this, mostly because I understand it to be fairly finished. If the WG will need to spend a few months discussing it, I will have to reconsider.



      

        
Add to all of this that I have two other drafts that I'd like to see dusted off
and moved forward through some process -- alternate encoding (XML and
Form parameters) from the token endpoint, and the UX/dynreg related
"instance information" draft. I'll have versions of both of these uploaded
once the IETF tracker takes the locks off at the end of the month. 


      

      
I think the XML draft is simple enough to include. I've supported it in the last round. I think the UX work is actually really important if someone is willing to take the lead on that and do the work.



      

        
Neither of
these saw much WG feedback or support before, though, so I'm open to
suggestions of what a better home for them might be, if there is one. Or
maybe we should make a new group for all the orphaned open web specs?


      

      
I think many people here don't fully understand the ways the IETF works. While working groups are the main venue for collaboration, there is a lot of work done on an Individual Submission basis (more than half?). This means a specification is created and finalized outside an official WG and without a charter.

The general mechanism (at least as used pretty effectively by me for a handful of published RFCs) is to find the right mailing list (e.g. HTTP for Link relations, Apps Discuss for host-meta and well-known, OAuth for OAuth 1.0) and support from an Area Director. You also need to fine a document shepherd  to help review and help with the "paperwork".

The way this works is that you can write a specification, discuss it on the WG list, and when you feel it is ready, ask the sponsoring AD for IETF Last Call. The AD might decide this is better suited to go through the full WG process, or feel that the document is simple and narrow enough to skip it. It is also possible that some of this work will be discussed on this list, but sponsored by an APPS area AD (e.g. the XML extension is a perfect example for something that is really not a security protocol component). So you have options.

IOW, getting your draft onto the charter is actually not always the best option for a straight-forward but low priority/interest work. The individual submission track might be better for you and the WG. You might want to reach out to one of the ADs or Chairs and discuss these options.

EH



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


    

  


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


--Apple-Mail=_E96ACF91-1D29-4A18-AA6F-DCCBA300D866--

--Apple-Mail=_10872BAC-EC0C-4225-B1C4-3F2109B71344
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw
ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU
T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp
YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm
aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk
bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9
Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8
k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd
NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB
+rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK
7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV
HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B
MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h
Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt
ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD
b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p
dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh
dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa
MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw
Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG
AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI
KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50
LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF
BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3
Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz
lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy
Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3
toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG
SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt
YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ
A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ
gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1
13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU
euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/
MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB
nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp
MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9
BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh
LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js
LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB
VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv
aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh
cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM
ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5
IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw
EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF
AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p
ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4
ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB
9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT
e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW
0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+
BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw
vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ
x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW
yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr
DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz
MTUxMTI2MTBaMCMGCSqGSIb3DQEJBDEWBBRl9X0KL5VCwpMTOghBEsfDJkxxlDCBpAYJKwYBBAGC
NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC
AQBeHx+Z2zeCDCkyfC5ik2uKqvCdWd/M84jTn7Yvtzkf7N7ODGSWPE2c9eVC1zc6lG3n8AoAuqhg
4cN6nQTXwlHwM0a5jkTcTVjKaSbOh6UgXM/YJKXnu4LmrriCE0OCKkG8gcHQXgAFe8MY+mxJGKEs
Fs2rW/xlZu0pTMDs47e7xlJsqsSHsmIL4z4UmEAQw78cIME4rPEMhsxP/XLTO3+xXPt3N6xO2tW2
re2idSofP9s04hM9+9t4VuVmrPpO4LDTye2qK1scz+6MUHB82W3LN3nyuCQBinUL4UVMDjimBUnt
k+86oOzVuPXLfbSpjNqSCsAtBJC0KjhjVAcAeONSAAAAAAAA

--Apple-Mail=_10872BAC-EC0C-4225-B1C4-3F2109B71344--

From romeda@gmail.com  Thu Mar 15 04:31:38 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FF821F85F0 for ; Thu, 15 Mar 2012 04:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCRgwIOGYpm0 for ; Thu, 15 Mar 2012 04:31:38 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3275421F85EF for ; Thu, 15 Mar 2012 04:31:38 -0700 (PDT)
Received: by lagj5 with SMTP id j5so2706038lag.31 for ; Thu, 15 Mar 2012 04:31:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=u0me3I2pw2SrZlAkQsbjF+cInaQZriMQR14D/illKVs=; b=bSXj+K7Hz44nvXn5Tjae+GI9RZsusb+/KwJzEHnRlxtA8OO9NOjq+NkYAzjYJlVDRq YJtEUX5NMVzE/eE0IJ5DBbw9WqOrTi8vcZKcquwEill5uAlGdMM81Fo2MvmhKHWuGgWy HcQ9ZGbzGmjUwzTCntGdWFvnaiC3rfudFOJQAk8jueCR9oW+nGLBGlX7Vdoe6vFxu/6c qrsIvjALjkA4bbxdpznLPQGtECXAu/VhILZqAOyEKVII5LIjxTOuq1eLo+2iCE1V3oky 0P97FynHHOxqEBGCGRdD4Vpym4ByxQOY2ZsGMb7TZFq7zdjfeYzxElWqLL8B1M8JxKWQ bCDw==
Received: by 10.112.25.40 with SMTP id z8mr2296116lbf.11.1331811097097; Thu, 15 Mar 2012 04:31:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.19.2 with HTTP; Thu, 15 Mar 2012 04:31:17 -0700 (PDT)
In-Reply-To: 
References: 
From: Blaine Cook 
Date: Thu, 15 Mar 2012 11:31:17 +0000
Message-ID: 
To: Hannes Tschofenig 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 11:31:39 -0000

On 14 March 2012 20:21, Hannes Tschofenig  wrote=
:
> So, here is a proposal:
>
> [Editor's Note: New work for the group. 5 items maximum! ]
>
> Aug. 2012 =C2=A0 =C2=A0Submit 'Token Revocation' to the IESG for consider=
ation as a Proposed Standard
> Nov. 2012 =C2=A0 =C2=A0Submit 'JSON Web Token (JWT)' to the IESG for cons=
ideration as a Proposed Standard
> Nov. 2012 =C2=A0 =C2=A0Submit 'JSON Web Token (JWT) Bearer Token Profiles=
 for OAuth 2.0' to the IESG for consideration
> Jan. 2013 =C2=A0 =C2=A0Submit 'OAuth Dynamic Client Registration Protocol=
' to the IESG for consideration as a Proposed Standard
> Sep. 2012 =C2=A0 =C2=A0Submit 'OAuth Use Cases' to the IESG for considera=
tion as an Informational RFC

This looks great to me.

I have serious concerns about feature-creep, and think that the OAuth
WG should strongly limit its purview to these issues. In general, I
think it prudent for this working group in particular to consider
standardisation of work only under the following criteria:

1. Proposals must have a direct relationship to the mechanism of OAuth
(and not, specifically, bound to an application-level protocol).
2. Proposals must have significant adoption in both enterprise and
startup environments.
3. Any proposal must be driven based on a consideration of the
different approaches, as adopted in the wild, and strive to be a
better synthesis of those approaches, not a means to an end.

These are the constraints with which I started the OAuth project, and
they're more relevant than ever. I'd hate to see OAuth fail in the end
because of a WS-*-like death by standards-pile-on.

b.

From hannes.tschofenig@nsn.com  Thu Mar 15 04:46:42 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B736C21F86A8 for ; Thu, 15 Mar 2012 04:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.419
X-Spam-Level: 
X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbkQzCAkSRUE for ; Thu, 15 Mar 2012 04:46:42 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E27C721F867F for ; Thu, 15 Mar 2012 04:46:41 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2FBkcKU018726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 12:46:38 +0100
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2FBkXRd014566; Thu, 15 Mar 2012 12:46:38 +0100
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 15 Mar 2012 12:46:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Thu, 15 Mar 2012 13:46:34 +0200
Message-ID: <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: Ac0CnzJzNsQfN7a4RL6KgAEUAk1PowAAfdrQ
References:  
From: "Tschofenig, Hannes (NSN - FI/Espoo)" 
To: "ext Blaine Cook" , "Hannes Tschofenig" 
X-OriginalArrivalTime: 15 Mar 2012 11:46:36.0864 (UTC) FILETIME=[470D0C00:01CD02A1]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3158
X-purgate-ID: 151667::1331811998-000033AC-8D5E4CB7/0-0/0-0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 11:46:42 -0000

SGkgQmxhaW5lLCANCg0KVGhlc2UgYXJlIGluZGVlZCBnb29kIHJlcXVpcmVtZW50cyB5b3Ugc3Rh
dGVkIGJlbG93LiANCg0KV2hlbiB5b3UgbG9vayBhdCB0aGUgbGlzdCBvZiB0b3BpY3MgZG8geW91
IHRoaW5rIHRoYXQgdGhlIHByb3Bvc2VkIGl0ZW1zIGluZGVlZCBmdWxmaWxsIHRoZW0/IA0KDQpD
aWFvDQpIYW5uZXMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYNCj4gT2YgZXh0IEJsYWluZSBDb29rDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNSwg
MjAxMiAxOjMxIFBNDQo+IFRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KPiBDYzogb2F1dGhAaWV0Zi5v
cmcgV0cNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggV0cgUmUtQ2hhcnRlcmluZw0K
PiANCj4gT24gMTQgTWFyY2ggMjAxMiAyMDoyMSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50
c2Nob2ZlbmlnQGdteC5uZXQ+DQo+IHdyb3RlOg0KPiA+IFNvLCBoZXJlIGlzIGEgcHJvcG9zYWw6
DQo+ID4NCj4gPiBbRWRpdG9yJ3MgTm90ZTogTmV3IHdvcmsgZm9yIHRoZSBncm91cC4gNSBpdGVt
cyBtYXhpbXVtISBdDQo+ID4NCj4gPiBBdWcuIDIwMTIgwqAgwqBTdWJtaXQgJ1Rva2VuIFJldm9j
YXRpb24nIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uDQo+IGFzIGEgUHJvcG9zZWQgU3Rh
bmRhcmQNCj4gPiBOb3YuIDIwMTIgwqAgwqBTdWJtaXQgJ0pTT04gV2ViIFRva2VuIChKV1QpJyB0
byB0aGUgSUVTRyBmb3INCj4gY29uc2lkZXJhdGlvbiBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkDQo+
ID4gTm92LiAyMDEyIMKgIMKgU3VibWl0ICdKU09OIFdlYiBUb2tlbiAoSldUKSBCZWFyZXIgVG9r
ZW4gUHJvZmlsZXMgZm9yDQo+IE9BdXRoIDIuMCcgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRp
b24NCj4gPiBKYW4uIDIwMTMgwqAgwqBTdWJtaXQgJ09BdXRoIER5bmFtaWMgQ2xpZW50IFJlZ2lz
dHJhdGlvbiBQcm90b2NvbCcgdG8NCj4gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgYSBQ
cm9wb3NlZCBTdGFuZGFyZA0KPiA+IFNlcC4gMjAxMiDCoCDCoFN1Ym1pdCAnT0F1dGggVXNlIENh
c2VzJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbg0KPiBhcyBhbiBJbmZvcm1hdGlvbmFs
IFJGQw0KPiANCj4gVGhpcyBsb29rcyBncmVhdCB0byBtZS4NCj4gDQo+IEkgaGF2ZSBzZXJpb3Vz
IGNvbmNlcm5zIGFib3V0IGZlYXR1cmUtY3JlZXAsIGFuZCB0aGluayB0aGF0IHRoZSBPQXV0aA0K
PiBXRyBzaG91bGQgc3Ryb25nbHkgbGltaXQgaXRzIHB1cnZpZXcgdG8gdGhlc2UgaXNzdWVzLiBJ
biBnZW5lcmFsLCBJDQo+IHRoaW5rIGl0IHBydWRlbnQgZm9yIHRoaXMgd29ya2luZyBncm91cCBp
biBwYXJ0aWN1bGFyIHRvIGNvbnNpZGVyDQo+IHN0YW5kYXJkaXNhdGlvbiBvZiB3b3JrIG9ubHkg
dW5kZXIgdGhlIGZvbGxvd2luZyBjcml0ZXJpYToNCj4gDQo+IDEuIFByb3Bvc2FscyBtdXN0IGhh
dmUgYSBkaXJlY3QgcmVsYXRpb25zaGlwIHRvIHRoZSBtZWNoYW5pc20gb2YgT0F1dGgNCj4gKGFu
ZCBub3QsIHNwZWNpZmljYWxseSwgYm91bmQgdG8gYW4gYXBwbGljYXRpb24tbGV2ZWwgcHJvdG9j
b2wpLg0KPiAyLiBQcm9wb3NhbHMgbXVzdCBoYXZlIHNpZ25pZmljYW50IGFkb3B0aW9uIGluIGJv
dGggZW50ZXJwcmlzZSBhbmQNCj4gc3RhcnR1cCBlbnZpcm9ubWVudHMuDQo+IDMuIEFueSBwcm9w
b3NhbCBtdXN0IGJlIGRyaXZlbiBiYXNlZCBvbiBhIGNvbnNpZGVyYXRpb24gb2YgdGhlDQo+IGRp
ZmZlcmVudCBhcHByb2FjaGVzLCBhcyBhZG9wdGVkIGluIHRoZSB3aWxkLCBhbmQgc3RyaXZlIHRv
IGJlIGENCj4gYmV0dGVyIHN5bnRoZXNpcyBvZiB0aG9zZSBhcHByb2FjaGVzLCBub3QgYSBtZWFu
cyB0byBhbiBlbmQuDQo+IA0KPiBUaGVzZSBhcmUgdGhlIGNvbnN0cmFpbnRzIHdpdGggd2hpY2gg
SSBzdGFydGVkIHRoZSBPQXV0aCBwcm9qZWN0LCBhbmQNCj4gdGhleSdyZSBtb3JlIHJlbGV2YW50
IHRoYW4gZXZlci4gSSdkIGhhdGUgdG8gc2VlIE9BdXRoIGZhaWwgaW4gdGhlIGVuZA0KPiBiZWNh
dXNlIG9mIGEgV1MtKi1saWtlIGRlYXRoIGJ5IHN0YW5kYXJkcy1waWxlLW9uLg0KPiANCj4gYi4N
Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1
dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg==

From paul.madsen@gmail.com  Thu Mar 15 05:10:43 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A32F21F8692 for ; Thu, 15 Mar 2012 05:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhWe6Jb+T5ta for ; Thu, 15 Mar 2012 05:10:42 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5841721F8693 for ; Thu, 15 Mar 2012 05:10:41 -0700 (PDT)
Received: by wibhq7 with SMTP id hq7so3396754wib.13 for ; Thu, 15 Mar 2012 05:10:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=GqYJCNZeUmCbMfONxy46nAlmftKFZUj74xJKoxmIG/c=; b=o9IH+d+lskCNK1Mzr7ftddP9sTMEaCtCZ2fJiAqBRR6aNS+HHGdO0oa7oH5BGTuWnK zoHpcpyv/Zdyl5VIZoyrkYPPzk20mIWlZ5SpDW+JIj73YEMhTU/qdUBx4WXfM+/tBWDC k/+W9muYwJOt8h0WnybPJq045n2EYC3rAsQ2rZNVIPeiZX6QVSp5/Vo6czm1BpqMDmLV jDEoMF0IVlrdlSHi80Su1SsMkzNYyzH8hjf8mJhBgPhTB1oUidmhlc2p4U9cO9RGNc2R Ni8mTIoRhlrlF1nsQGwbbyWJmxkDgWoCi/amytsSCc4gr+mm/0TaGHOoZHO/bqKLLRSt 0YEg==
Received: by 10.50.185.201 with SMTP id fe9mr9014339igc.47.1331813434237; Thu, 15 Mar 2012 05:10:34 -0700 (PDT)
Received: from [192.168.2.22] (bas1-northbay04-2925117588.dsl.bell.ca. [174.89.192.148]) by mx.google.com with ESMTPS id mi10sm1760598igc.8.2012.03.15.05.10.32 (version=SSLv3 cipher=OTHER); Thu, 15 Mar 2012 05:10:33 -0700 (PDT)
Message-ID: <4F61DC37.6090508@gmail.com>
Date: Thu, 15 Mar 2012 08:10:31 -0400
From: Paul Madsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Tschofenig, Hannes (NSN - FI/Espoo)" 
References: <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org> <4F61C5D6.40106@gmail.com> <999913AB42CC9341B05A99BBF358718D01382A8C@FIESEXC035.nsn-intra.net>
In-Reply-To: <999913AB42CC9341B05A99BBF358718D01382A8C@FIESEXC035.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060907080000040002050104"
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 12:10:43 -0000

This is a multi-part message in MIME format.
--------------060907080000040002050104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Hannes, happy to submit as ID once possible.

Wrt the current 5, we want them all (and more) :-) but the following are 
data points for our prioritization

0) JWT is a given

1) we have implemented the SAML bearer token profile, somewhat 
deprioritizing for us in the immediate term the equivalent JWT profile 
(but not the long term)

2) customers are demanding programmatic client registration. For one 
customer, the use case is to allow clients to be added to our AS via an 
API management solution. The customer wants client developers to use the 
API management tool as the single touch point into their APIs - adding 
clients, being issued credentials etc

As well, the TV Everywhere driven OATC spec (based on OAuth 2) has 
requirements for the same

3) as valuable as an informational use cases discussion will be, I'd 
hope it doesnt prevent us tackling normative work

4) wrt revocation, we definitely see use cases  (enterprise employee is 
issued long lived refresh token for a mobile SaaS app, then gets fired 
and so enterprise needs to turn off the access) but can probably achieve 
the equivalent with a SCIM 'delete user' message

paul

On 3/15/12 7:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>
> Hi Paul,
>
> Interesting stuff. Thanks for sharing your draft writeup with us.
>
> Could you submit the document as Internet Draft when the submission 
> gates open again?
>
> The I-D submission tool will be reopened at 00h UTC, 2012-03-26.
>
> From the current list of items what do you consider less important?
>
> Ciao
>
> Hannes
>
> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On 
> Behalf Of *ext Paul Madsen
> *Sent:* Thursday, March 15, 2012 12:35 PM
> *To:* Richer, Justin P.
> *Cc:* oauth@ietf.org WG
> *Subject:* Re: [OAUTH-WG] OAuth WG Re-Chartering
>
> +1 to defining RS-AS interactions. We've implemented such a 'token 
> introspection' endpoint in our AS and I'm be happy to no longer need 
> to explain to customers/partners why it's not part of the standard.
>
> As input, an (incomplete) spec for our endpoint enclosed. (we modeled 
> the verification as a new grant type, leveraging as much as possible 
> the existing token endpoint API)
>
> Wrt the 5 item limit
>
> 1) is this an arbitrary #? if people sign up to work on more items, 
> could it be extended?
> 2) the use cases document seems already well progressed (and 
> informational). Need it count against the 5?
>
> paul
>
> On 3/14/12 5:53 PM, Richer, Justin P. wrote:
>
> Methods of connecting the PR to the AS are something that several groups have invented outside of the OAuth WG, and I think we should try to pull some of this work together. OAuth2 gives us a logical separation of the concerns but not a way to knit them back together.
>   
> Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID, and several "token introspection" endpoints in various implementations.
>   
>   -- Justin
>   
> On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:
>   
>
>     So, here is a proposal:
>
>       
>
>     -------
>
>       
>
>     Web Authorization Protocol (oauth)
>
>       
>
>     Description of Working Group
>
>       
>
>     The Web Authorization (OAuth) protocol allows a user to grant
>
>     a third-party Web site or application access to the user's protected
>
>     resources, without necessarily revealing their long-term credentials,
>
>     or even their identity. For example, a photo-sharing site that supports
>
>     OAuth could allow its users to use a third-party printing Web site to
>
>     print their private pictures, without allowing the printing site to
>
>     gain full control of the user's account and without having the user
>
>     sharing his or her photo-sharing sites' long-term credential with the
>
>     printing site.
>
>       
>
>     The OAuth protocol suite encompasses
>
>     * a procedure for allowing a client to discover a resource server,
>
>     * a protocol for obtaining authorization tokens from an authorization
>
>     server with the resource owner's consent,
>
>     * protocols for presenting these authorization tokens to protected
>
>     resources for access to a resource, and
>
>     * consequently for sharing data in a security and privacy respective way.
>
>       
>
>     In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
>
>     was published as an informational document (RFC 5849). With the
>
>     completion of OAuth 1.0 the working group started their work on OAuth 2.0
>
>     to incorporate implementation experience with version 1.0, additional
>
>     use cases, and various other security, readability, and interoperability
>
>     improvements. An extensive security analysis was conducted and the result
>
>     is available as a stand-alone document offering guidance for audiences
>
>     beyond the community of protocol implementers.
>
>       
>
>     The working group also developed security schemes for presenting authorization
>
>     tokens to access a protected resource. This led to the publication of
>
>     the bearer token as well as the message authentication code (MAC) access
>
>     authentication specification.
>
>       
>
>     OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with
>
>     the SAML 2.0 bearer assertion profile.  This offers interworking with existing
>
>     identity management solutions, in particular SAML based deployments.
>
>       
>
>     OAuth has enjoyed widespread adoption by the Internet application service provider
>
>     community. To build on this success we aim for nothing more than to make OAuth the
>
>     authorization framework of choice for any Internet protocol. Consequently, the
>
>     ongoing standardization effort within the OAuth working group is focused on
>
>     enhancing interoperability of OAuth deployments. While the core OAuth specification
>
>     truly is an important building block it relies on other specifications in order to
>
>     claim completeness. Luckily, these components already exist and have been deployed
>
>     on the Internet. Through the IETF standards process they will be improved in
>
>     quality and will undergo a rigorous review process.
>
>       
>
>     Goals and Milestones
>
>       
>
>     [Editor's Note: Here are the completed items.]
>
>       
>
>     Done     Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item
>
>     Done     Submit 'HTTP Authentication: MAC Authentication' as a working group item
>
>     Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard
>
>     Done     Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard
>
>       
>
>     [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?]
>
>       
>
>     Jun. 2012       Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard
>
>     Apr. 2012       Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
>
>     Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard
>
>     Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard
>
>     May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC
>
>       
>
>     [Editor's Note: New work for the group. 5 items maximum! ]
>
>       
>
>     Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard
>
>       
>
>     [Starting point for the work will behttp://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
>
>       
>
>     Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard
>
>       
>
>     [Starting point for the work will behttp://tools.ietf.org/html/draft-jones-json-web-token]
>
>       
>
>     Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
>
>       
>
>     [Starting point for the work will behttp://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
>
>       
>
>     Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
>
>       
>
>     [Starting point for the work will behttp://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
>
>       
>
>     Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC
>
>       
>
>     [Starting point for the work will behttp://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
>
>       
>
>       
>
>       
>
>     _______________________________________________
>
>     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

--------------060907080000040002050104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Hannes, happy to submit as ID once possible.

      

      Wrt the current 5, we want them all (and more) :-) but the
      following are data points for our prioritization

      

      0) JWT is a given

      

      1) we have implemented the SAML bearer token profile, somewhat
      deprioritizing for us in the immediate term the equivalent JWT
      profile (but not the long term)

      

      2) customers are demanding programmatic client registration. For
      one customer, the use case is to allow clients to be added to our
      AS via an API management solution. The customer wants client
      developers to use the API management tool as the single touch
      point into their APIs - adding clients, being issued credentials
      etc

      

      As well, the TV Everywhere driven OATC spec (based on OAuth 2) has
      requirements for the same

      

      3) as valuable as an informational use cases discussion will be,
      I'd hope it doesnt prevent us tackling normative work

      

      4) wrt revocation, we definitely see use cases  (enterprise
      employee is issued long lived refresh token for a mobile SaaS app,
      then gets fired and so enterprise needs to turn off the access)
      but can probably achieve the equivalent with a SCIM 'delete user'
      message

      

      paul

    

    On 3/15/12 7:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
    

      
      
      
      

        
Hi
            Paul, 

        
 

        
Interesting
            stuff. Thanks for sharing your draft writeup with us. 

        
 

        
Could
            you submit the document as Internet Draft when the
            submission gates open again? 

        
The
            I-D submission tool will be reopened at 00h UTC, 2012-03-26.

        
 

        
From
            the current list of items what do you consider less
            important?

        
 

        
Ciao

        
Hannes

        
 

        

          

            

              
From:
                  oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
                  On Behalf Of ext Paul Madsen

                  Sent: Thursday, March 15, 2012 12:35 PM

                  To: Richer, Justin P.

                  Cc: oauth@ietf.org WG

                  Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

            

          

          
 

          
+1
              to defining RS-AS interactions. We've implemented such a
              'token introspection' endpoint in our AS and I'm be happy
              to no longer need to explain to customers/partners why
              it's not part of the standard.

              

              As input, an (incomplete) spec for our endpoint enclosed.
              (we modeled the verification as a new grant type,
              leveraging as much as possible the existing token endpoint
              API)

              

              Wrt the 5 item limit

              

              1) is this an arbitrary #? if people sign up to work on
              more items, could it be extended?

              2) the use cases document seems already well progressed
              (and informational). Need it count against the 5?

              

              paul

            

            On 3/14/12 5:53 PM, Richer, Justin P. wrote: 

          
Methods of connecting the PR to the AS are something that several groups have invented outside of the OAuth WG, and I think we should try to pull some of this work together. OAuth2 gives us a logical separation of the concerns but not a way to knit them back together. 

          
 

          
Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID, and several "token introspection" endpoints in various implementations.

          
 

          
 -- Justin

          
 

          
On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:

          
 

          

            
So, here is a proposal:

            
 

            
-------

            
 

            
Web Authorization Protocol (oauth)

            
 

            
Description of Working Group

            
 

            
The Web Authorization (OAuth) protocol allows a user to grant

            
a third-party Web site or application access to the user's protected

            
resources, without necessarily revealing their long-term credentials,

            
or even their identity. For example, a photo-sharing site that supports

            
OAuth could allow its users to use a third-party printing Web site to

            
print their private pictures, without allowing the printing site to

            
gain full control of the user's account and without having the user 

            
sharing his or her photo-sharing sites' long-term credential with the 

            
printing site. 

            
 

            
The OAuth protocol suite encompasses

            
* a procedure for allowing a client to discover a resource server, 

            
* a protocol for obtaining authorization tokens from an authorization 

            
server with the resource owner's consent, 

            
* protocols for presenting these authorization tokens to protected 

            
resources for access to a resource, and 

            
* consequently for sharing data in a security and privacy respective way.

            
 

            
In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,

            
was published as an informational document (RFC 5849). With the 

            
completion of OAuth 1.0 the working group started their work on OAuth 2.0

            
to incorporate implementation experience with version 1.0, additional

            
use cases, and various other security, readability, and interoperability

            
improvements. An extensive security analysis was conducted and the result 

            
is available as a stand-alone document offering guidance for audiences 

            
beyond the community of protocol implementers.

            
 

            
The working group also developed security schemes for presenting authorization

            
tokens to access a protected resource. This led to the publication of

            
the bearer token as well as the message authentication code (MAC) access 

            
authentication specification. 

            
 

            
OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with 

            
the SAML 2.0 bearer assertion profile.  This offers interworking with existing 

            
identity management solutions, in particular SAML based deployments.

            
 

            
OAuth has enjoyed widespread adoption by the Internet application service provider 

            
community. To build on this success we aim for nothing more than to make OAuth the 

            
authorization framework of choice for any Internet protocol. Consequently, the 

            
ongoing standardization effort within the OAuth working group is focused on 

            
enhancing interoperability of OAuth deployments. While the core OAuth specification 

            
truly is an important building block it relies on other specifications in order to 

            
claim completeness. Luckily, these components already exist and have been deployed 

            
on the Internet. Through the IETF standards process they will be improved in 

            
quality and will undergo a rigorous review process. 

            
 

            
Goals and Milestones

            
 

            
[Editor's Note: Here are the completed items.] 

            
 

            
Done     Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item

            
Done     Submit 'HTTP Authentication: MAC Authentication' as a working group item

            
Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard

            
Done     Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard

            
 

            
[Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] 

            
 

            
Jun. 2012       Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard

            
Apr. 2012       Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard

            
Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard 

            
Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard 

            
May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC

            
 

            
[Editor's Note: New work for the group. 5 items maximum! ]

            
 

            
Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard

            
 

            
[Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

            
 

            
Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard

            
 

            
[Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]

            
 

            
Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard

            
 

            
[Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

            
 

            
Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard

            
 

            
[Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] 

            
 

            
Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC

            
 

            
[Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] 

            
 

            
 

            
 

            
_______________________________________________

            
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

        

      

    

  


--------------060907080000040002050104--

From jricher@mitre.org  Thu Mar 15 06:22:29 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EA321F85AE for ; Thu, 15 Mar 2012 06:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.476
X-Spam-Level: 
X-Spam-Status: No, score=-4.476 tagged_above=-999 required=5 tests=[AWL=-2.078, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+PZQN9DpWHF for ; Thu, 15 Mar 2012 06:22:28 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C3F6321F85EC for ; Thu, 15 Mar 2012 06:22:27 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1ABB221B071D; Thu, 15 Mar 2012 09:22:26 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 02F2521B0709; Thu, 15 Mar 2012 09:22:26 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.126]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Thu, 15 Mar 2012 09:22:25 -0400
From: "Richer, Justin P." 
To: Paul Madsen 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAMLrJnb2MYa0aucATvktxjjJZqmKGAgADUuwCAAAqXAIAAEBaAgAAUFYA=
Date: Thu, 15 Mar 2012 13:22:24 +0000
Message-ID: <013F1E47-FCA8-41DD-B0D8-0D4650ABB5F6@mitre.org>
References: <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org> <4F61C5D6.40106@gmail.com> <999913AB42CC9341B05A99BBF358718D01382A8C@FIESEXC035.nsn-intra.net> <4F61DC37.6090508@gmail.com>
In-Reply-To: <4F61DC37.6090508@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.35.218]
Content-Type: multipart/alternative; boundary="_000_013F1E47FCA841DDB0D80D4650ABB5F6mitreorg_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 13:22:29 -0000

--_000_013F1E47FCA841DDB0D80D4650ABB5F6mitreorg_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

4) wrt revocation, we definitely see use cases  (enterprise employee is iss=
ued long lived refresh token for a mobile SaaS app, then gets fired and so =
enterprise needs to turn off the access) but can probably achieve the equiv=
alent with a SCIM 'delete user' message

Token revocation and user deletion are completely separate issues -- there'=
s no real overlap here. It's about closing the session management gap (for =
both access and refresh tokens) and it has nothing to do with deprovisionin=
g a user in a system. In many cases, there might not even be a "user" that =
the token directly represents, or the client wouldn't know enough about the=
m to make a delete user message. And that's a very good thing -- Would you =
really want to give every delegated client the ability to delete your accou=
nt when it felt like it? Absolutely not - that level of power is completely=
 counter to the whole point of delegated access.

Plus, for what it's worth, it's pretty much finished already and we've impl=
emented the endpoint already, too.


To answer Hannes's original question, I think the WG's priorities from the =
list ought to be, in rough order:

1) Revocation (for reasons above)
2) Dynamic Registration (big need for this and several drafts already out t=
here to start from)
3) JWT Bearer (it matches the profile for saml bearer and fits in the OAuth=
 world well)
4) JWT, if no one else will take it (and it is basically done, and well dep=
loyed already)
5) Use cases (since it's informational and bound to cause some level of con=
troversy, I wouldn't want to see this really detract from the real normativ=
e standards work, and don't think it should be counted against the total)

For other documents discussed, like XML encoding, SWD, UX, and things like =
that, other avenues *may* be a better fit and I'm happy with pursuing some =
of these myself. But with so much of the work on these and other documents =
already done, many of the same arguments for inclusion of the above five ap=
ply.

 -- Justin

On 3/15/12 7:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
Hi Paul,

Interesting stuff. Thanks for sharing your draft writeup with us.

Could you submit the document as Internet Draft when the submission gates o=
pen again?
The I-D submission tool will be reopened at 00h UTC, 2012-03-26.

>From the current list of items what do you consider less important?

Ciao
Hannes

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of ext Paul Madsen
Sent: Thursday, March 15, 2012 12:35 PM
To: Richer, Justin P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

+1 to defining RS-AS interactions. We've implemented such a 'token introspe=
ction' endpoint in our AS and I'm be happy to no longer need to explain to =
customers/partners why it's not part of the standard.

As input, an (incomplete) spec for our endpoint enclosed. (we modeled the v=
erification as a new grant type, leveraging as much as possible the existin=
g token endpoint API)

Wrt the 5 item limit

1) is this an arbitrary #? if people sign up to work on more items, could i=
t be extended?
2) the use cases document seems already well progressed (and informational)=
. Need it count against the 5?

paul

On 3/14/12 5:53 PM, Richer, Justin P. wrote:

Methods of connecting the PR to the AS are something that several groups ha=
ve invented outside of the OAuth WG, and I think we should try to pull some=
 of this work together. OAuth2 gives us a logical separation of the concern=
s but not a way to knit them back together.



Proposals for inclusion in the discussion include UMA's Step 3, OpenID Conn=
ect's CheckID, and several "token introspection" endpoints in various imple=
mentations.



 -- Justin



On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:



So, here is a proposal:



-------



Web Authorization Protocol (oauth)



Description of Working Group



The Web Authorization (OAuth) protocol allows a user to grant

a third-party Web site or application access to the user's protected

resources, without necessarily revealing their long-term credentials,

or even their identity. For example, a photo-sharing site that supports

OAuth could allow its users to use a third-party printing Web site to

print their private pictures, without allowing the printing site to

gain full control of the user's account and without having the user

sharing his or her photo-sharing sites' long-term credential with the

printing site.



The OAuth protocol suite encompasses

* a procedure for allowing a client to discover a resource server,

* a protocol for obtaining authorization tokens from an authorization

server with the resource owner's consent,

* protocols for presenting these authorization tokens to protected

resources for access to a resource, and

* consequently for sharing data in a security and privacy respective way.



In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,

was published as an informational document (RFC 5849). With the

completion of OAuth 1.0 the working group started their work on OAuth 2.0

to incorporate implementation experience with version 1.0, additional

use cases, and various other security, readability, and interoperability

improvements. An extensive security analysis was conducted and the result

is available as a stand-alone document offering guidance for audiences

beyond the community of protocol implementers.



The working group also developed security schemes for presenting authorizat=
ion

tokens to access a protected resource. This led to the publication of

the bearer token as well as the message authentication code (MAC) access

authentication specification.



OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH toke=
n with

the SAML 2.0 bearer assertion profile.  This offers interworking with exist=
ing

identity management solutions, in particular SAML based deployments.



OAuth has enjoyed widespread adoption by the Internet application service p=
rovider

community. To build on this success we aim for nothing more than to make OA=
uth the

authorization framework of choice for any Internet protocol. Consequently, =
the

ongoing standardization effort within the OAuth working group is focused on

enhancing interoperability of OAuth deployments. While the core OAuth speci=
fication

truly is an important building block it relies on other specifications in o=
rder to

claim completeness. Luckily, these components already exist and have been d=
eployed

on the Internet. Through the IETF standards process they will be improved i=
n

quality and will undergo a rigorous review process.



Goals and Milestones



[Editor's Note: Here are the completed items.]



Done     Submit 'OAuth 2.0 Threat Model and Security Considerations' as a w=
orking group item

Done     Submit 'HTTP Authentication: MAC Authentication' as a working grou=
p item

Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for con=
sideration as a Proposed Standard

Done     Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for cons=
ideration as a Proposed Standard



[Editor's Note: Finishing existing work. Double-check the proposed dates - =
are they realistic?]



Jun. 2012       Submit 'HTTP Authentication: MAC Authentication' to the IES=
G for consideration as a Proposed Standard

Apr. 2012       Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' t=
o the IESG for consideration as a Proposed Standard

Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for considerati=
on as a Proposed Standard

Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for con=
sideration as a Proposed Standard

May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to =
the IESG for consideration as an Informational RFC



[Editor's Note: New work for the group. 5 items maximum! ]



Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a P=
roposed Standard



[Starting point for the work will be http://datatracker.ietf.org/doc/draft-=
lodderstedt-oauth-revocation/]



Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as=
 a Proposed Standard



[Starting point for the work will be http://tools.ietf.org/html/draft-jones=
-json-web-token]



Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2=
.0' to the IESG for consideration as a Proposed Standard



[Starting point for the work will be http://tools.ietf.org/html/draft-jones=
-oauth-jwt-bearer]



Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IES=
G for consideration as a Proposed Standard



[Starting point for the work will be http://tools.ietf.org/html/draft-hardj=
ono-oauth-dynreg]



Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an I=
nformational RFC



[Starting point for the work will be http://tools.ietf.org/html/draft-zelts=
an-oauth-use-cases]







_______________________________________________

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


--_000_013F1E47FCA841DDB0D80D4650ABB5F6mitreorg_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable











4) wrt revoc=
ation, we definitely see use cases  (enterprise employee is issued lon=
g lived refresh token for a mobile SaaS app, then gets fired and so enterpr=
ise needs to turn off the access) but can probably
 achieve the equivalent with a SCIM 'delete user' message











Token revocation and user deletion are completely separate issues -- t=
here's no real overlap here. It's about closing the session management gap =
(for both access and refresh tokens) and it has nothing to do with deprovis=
ioning a user in a system. In many
 cases, there might not even be a "user" that the token directly =
represents, or the client wouldn't know enough about them to make a delete =
user message. And that's a very good thing -- Would you really want to=
 give every delegated client the ability to delete
 your account when it felt like it? Absolutely not - that level of power is=
 completely counter to the whole point of delegated access. 







Plus, for what it's worth, it's pretty much finished already and we've=
 implemented the endpoint already, too. 












To answer Hannes's original question, I think the WG's priorities from=
 the list ought to be, in rough order:







1) Revocation (for reasons above)


2) Dynamic Registration (big need for this and several drafts already =
out there to start from)


3) JWT Bearer (it matches the profile for saml bearer and fits in the =
OAuth world well)


4) JWT, if no one else will take it (and it is basically done, and wel=
l deployed already)


5) Use cases (since it's informational and bound to cause some level o=
f controversy, I wouldn't want to see this really detract from the real nor=
mative standards work, and don't think it should be counted against the tot=
al)







For other documents discussed, like XML encoding, SWD, UX, and things =
like that, other avenues *may* be a better fit and I'm happy with pursuing =
some of these myself. But with so much of the work on these and other docum=
ents already done, many of the same
 arguments for inclusion of the above five apply.







 -- Justin






On 3/15/12 7:12 AM, Tschofenig, H=
annes (NSN - FI/Espoo) wrote:







Hi Paul,



 <=
/p>

Interesting stuff. Thanks=
 for sharing your draft writeup with us.



 <=
/p>

Could you submit the docu=
ment as Internet Draft when the submission gates open again?



The I-D submission tool w=
ill be reopened at 00h UTC, 2012-03-26.


 <=
/p>

From the current list of =
items what do you consider less important?


 <=
/p>

Ciao

Hannes<=
/p>

 <=
/p>







From:
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of ext Paul Madsen

Sent: Thursday, March 15, 2012 12:35 PM

To: Richer, Justin P.

Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering






 


+1 to defining RS-AS interactions. We've implemented s=
uch a 'token introspection' endpoint in our AS and I'm be happy to no longe=
r need to explain to customers/partners why it's not part of
 the standard.



As input, an (incomplete) spec for our endpoint enclosed. (we modeled the v=
erification as a new grant type, leveraging as much as possible the existin=
g token endpoint API)



Wrt the 5 item limit



1) is this an arbitrary #? if people sign up to work on more items, could i=
t be extended?

2) the use cases document seems already well progressed (and informational)=
. Need it count against the 5?



paul



On 3/14/12 5:53 PM, Richer, Justin P. wrote: 


Methods of connecting the PR to the AS are something that several grou=
ps have invented outside of the OAuth WG, and I think we should try to pull=
 some of this work together. OAuth2 gives us a logical separation of the co=
ncerns but not a way to knit them back together. 


 


Proposals for inclusion in the discussion include UMA's Step 3, OpenID=
 Connect's CheckID, and several "token introspection" endpoints i=
n various implementations.


 


 -- Justin


 


On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:


 




So, here is a proposal:


 


-------


 


Web Authorization Protocol (oauth)


 


Description of Working Group


 


The Web Authorization (OAuth) protocol allows a user to grant


a third-party Web site or application access to the user's protected


resources, without necessarily revealing their long-term credentials,<=
o:p>


or even their identity. For example, a photo-sharing site that support=
s


OAuth could allow its users to use a third-party printing Web site to<=
o:p>


print their private pictures, without allowing the printing site to


gain full control of the user's account and without having the user 


sharing his or her photo-sharing sites' long-term credential with the =



printing site. 


 


The OAuth protocol suite encompasses


* a procedure for allowing a client to discover a resource server, 


* a protocol for obtaining authorization tokens from an authorization =



server with the resource owner's consent, 


* protocols for presenting these authorization tokens to protected 


resources for access to a resource, and 


* consequently for sharing data in a security and privacy respective w=
ay.


 


In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,<=
o:p>


was published as an informational document (RFC 5849). With the <=
/o:p>


completion of OAuth 1.0 the working group started their work on OAuth =
2.0


to incorporate implementation experience with version 1.0, additional<=
o:p>


use cases, and various other security, readability, and interoperabili=
ty


improvements. An extensive security analysis was conducted and the res=
ult 


is available as a stand-alone document offering guidance for audiences=
 


beyond the community of protocol implementers.


 


The working group also developed security schemes for presenting autho=
rization


tokens to access a protected resource. This led to the publication of<=
o:p>


the bearer token as well as the message authentication code (MAC) acce=
ss 


authentication specification. 


 


OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH=
 token with 


the SAML 2.0 bearer assertion profile.  This offers interworking =
with existing 


identity management solutions, in particular SAML based deployments.


 


OAuth has enjoyed widespread adoption by the Internet application serv=
ice provider 


community. To build on this success we aim for nothing more than to ma=
ke OAuth the 


authorization framework of choice for any Internet protocol. Consequen=
tly, the 


ongoing standardization effort within the OAuth working group is focus=
ed on 


enhancing interoperability of OAuth deployments. While the core OAuth =
specification 


truly is an important building block it relies on other specifications=
 in order to 


claim completeness. Luckily, these components already exist and have b=
een deployed 


on the Internet. Through the IETF standards process they will be impro=
ved in 


quality and will undergo a rigorous review process. 


 


Goals and Milestones


 


[Editor's Note: Here are the completed items.] 


 


Done     Submit 'OAuth 2.0 Threat Model and Security Co=
nsiderations' as a working group item


Done     Submit 'HTTP Authentication: MAC Authenticatio=
n' as a working group item


Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens'=
 to the IESG for consideration as a Proposed Standard


Done     Submit 'The OAuth 2.0 Authorization Protocol' =
to the IESG for consideration as a Proposed Standard


 


[Editor's Note: Finishing existing work. Double-check the proposed dat=
es - are they realistic?] 


 


Jun. 2012       Submit 'HTTP Authentication: =
MAC Authentication' to the IESG for consideration as a Proposed Standard


Apr. 2012       Submit 'SAML 2.0 Bearer Asser=
tion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed St=
andard


Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for c=
onsideration as a Proposed Standard 


Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IE=
SG for consideration as a Proposed Standard 


May 2012    Submit 'OAuth 2.0 Threat Model and Security=
 Considerations' to the IESG for consideration as an Informational RFC=



 


[Editor's Note: New work for the group. 5 items maximum! ]<=
/pre>

 


Aug. 2012    Submit 'Token Revocation' to the IESG for =
consideration as a Proposed Standard


 


[Starting point for the work will be ht=
tp://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]=



 


Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG =
for consideration as a Proposed Standard


 


[Starting point for the work will be http://tools.iet=
f.org/html/draft-jones-json-web-token]


 


Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token =
Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standar=
d


 


[Starting point for the work will be http://tools.i=
etf.org/html/draft-jones-oauth-jwt-bearer]


 


Jan. 2013    Submit 'OAuth Dynamic Client Registration =
Protocol' to the IESG for consideration as a Proposed Standard

 


[Starting point for the work will be http://tools.ie=
tf.org/html/draft-hardjono-oauth-dynreg] 


 


Sep. 2012    Submit 'OAuth Use Cases' to the IESG for c=
onsideration as an Informational RFC


 


[Starting point for the work will be http://tools.=
ietf.org/html/draft-zeltsan-oauth-use-cases] 


 


 


 


_______________________________________________


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










--_000_013F1E47FCA841DDB0D80D4650ABB5F6mitreorg_--

From paul.madsen@gmail.com  Thu Mar 15 06:54:58 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB0121F85F2 for ; Thu, 15 Mar 2012 06:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.617
X-Spam-Level: **
X-Spam-Status: No, score=2.617 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5VNt1obkKrK for ; Thu, 15 Mar 2012 06:54:55 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9A5B21F85F0 for ; Thu, 15 Mar 2012 06:54:53 -0700 (PDT)
Received: by eaaq11 with SMTP id q11so1674851eaa.31 for ; Thu, 15 Mar 2012 06:54:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=RKkoJtlwiueAeE2p16YdsnKLkUQsCnwDEfXj60xVpv8=; b=0ZKOcRlQTIfzaNjQw8BSwQThl86kBd1fBUI2nUEwQZpK/CWulGuFFYGRZJNfD/WLii NKt4jTvEuscuUs8M9PJbOGzc/7qNfV/wAhu0lyh21lrZDqVgHDntomm6DQ8MdFm4j6BF ++B+HS0j4lX5A/AniSwFwIM4YzF7MHWT8iQtrdVvoy57Yf2w/vAOsQYyRZFBK1vo9OdF OITlQyH3aQrZ8aG3y7VXdw8hYR2BJkQ9MgoTl1fHdfeHq4MQA2ElGFTfNKJpmdm1tc7q 5LLNekYvKPllQ92kFgpKSPRwNiUW8oovGLRz22NEbC47+BQBZ4Y4kZ2dSFnFmaweUyDX tgCA==
Received: by 10.50.47.232 with SMTP id g8mr9483299ign.18.1331819691844; Thu, 15 Mar 2012 06:54:51 -0700 (PDT)
Received: from [10.207.174.92] ([184.151.63.220]) by mx.google.com with ESMTPS id md6sm2015094igc.0.2012.03.15.06.54.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 06:54:50 -0700 (PDT)
References:  <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org> <4F61C5D6.40106@gmail.com> <999913AB42CC9341B05A99BBF358718D01382A8C@FIESEXC035.nsn-intra.net> <4F61DC37.6090508@gmail.com> <013F1E47-FCA8-41DD-B0D8-0D4650ABB5F6@mitre.org>
In-Reply-To: <013F1E47-FCA8-41DD-B0D8-0D4650ABB5F6@mitre.org>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-DC4C41A9-B4CE-4D72-ABBC-63050B15E0C6
Message-Id: 
X-Mailer: iPhone Mail (9A406)
From: Paul Madsen 
Date: Thu, 15 Mar 2012 09:54:36 -0400
To: "Richer, Justin P." 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 13:54:58 -0000

--Apple-Mail-DC4C41A9-B4CE-4D72-ABBC-63050B15E0C6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Agree that they are separate. For the use case I gave the fundamental requi

Sent from my iPhone

On 2012-03-15, at 9:22 AM, "Richer, Justin P."  wrote:

>> 4) wrt revocation, we definitely see use cases  (enterprise employee is i=
ssued long lived refresh token for a mobile SaaS app, then gets fired and so=
 enterprise needs to turn off the access) but can probably achieve the equiv=
alent with a SCIM 'delete user' message
>=20
> Token revocation and user deletion are completely separate issues -- there=
's no real overlap here. It's about closing the session management gap (for b=
oth access and refresh tokens) and it has nothing to do with deprovisioning a=
 user in a system. In many cases, there might not even be a "user" that the t=
oken directly represents, or the client wouldn't know enough about them to m=
ake a delete user message. And that's a very good thing -- Would you really w=
ant to give every delegated client the ability to delete your account when i=
t felt like it? Absolutely not - that level of power is completely counter t=
o the whole point of delegated access.=20
>=20
> Plus, for what it's worth, it's pretty much finished already and we've imp=
lemented the endpoint already, too.=20
>=20
>=20
> To answer Hannes's original question, I think the WG's priorities from the=
 list ought to be, in rough order:
>=20
> 1) Revocation (for reasons above)
> 2) Dynamic Registration (big need for this and several drafts already out t=
here to start from)
> 3) JWT Bearer (it matches the profile for saml bearer and fits in the OAut=
h world well)
> 4) JWT, if no one else will take it (and it is basically done, and well de=
ployed already)
> 5) Use cases (since it's informational and bound to cause some level of co=
ntroversy, I wouldn't want to see this really detract from the real normativ=
e standards work, and don't think it should be counted against the total)
>=20
> For other documents discussed, like XML encoding, SWD, UX, and things like=
 that, other avenues *may* be a better fit and I'm happy with pursuing some o=
f these myself. But with so much of the work on these and other documents al=
ready done, many of the same arguments for inclusion of the above five apply=
.
>=20
>  -- Justin
>=20
>> On 3/15/12 7:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>>=20
>>> Hi Paul,
>>> =20
>>> Interesting stuff. Thanks for sharing your draft writeup with us.
>>> =20
>>> Could you submit the document as Internet Draft when the submission gate=
s open again?
>>> The I-D submission tool will be reopened at 00h UTC, 2012-03-26.
>>> =20
>>> =46rom the current list of items what do you consider less important?
>>> =20
>>> Ciao
>>> Hannes
>>> =20
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O=
f ext Paul Madsen
>>> Sent: Thursday, March 15, 2012 12:35 PM
>>> To: Richer, Justin P.
>>> Cc: oauth@ietf.org WG
>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>> =20
>>> +1 to defining RS-AS interactions. We've implemented such a 'token intro=
spection' endpoint in our AS and I'm be happy to no longer need to explain t=
o customers/partners why it's not part of the standard.
>>>=20
>>> As input, an (incomplete) spec for our endpoint enclosed. (we modeled th=
e verification as a new grant type, leveraging as much as possible the exist=
ing token endpoint API)
>>>=20
>>> Wrt the 5 item limit
>>>=20
>>> 1) is this an arbitrary #? if people sign up to work on more items, coul=
d it be extended?
>>> 2) the use cases document seems already well progressed (and information=
al). Need it count against the 5?
>>>=20
>>> paul
>>>=20
>>> On 3/14/12 5:53 PM, Richer, Justin P. wrote:
>>> Methods of connecting the PR to the AS are something that several groups=
 have invented outside of the OAuth WG, and I think we should try to pull so=
me of this work together. OAuth2 gives us a logical separation of the concer=
ns but not a way to knit them back together.=20
>>> =20
>>> Proposals for inclusion in the discussion include UMA's Step 3, OpenID C=
onnect's CheckID, and several "token introspection" endpoints in various imp=
lementations.
>>> =20
>>>  -- Justin
>>> =20
>>> On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:
>>> =20
>>> So, here is a proposal:
>>> =20
>>> -------
>>> =20
>>> Web Authorization Protocol (oauth)
>>> =20
>>> Description of Working Group
>>> =20
>>> The Web Authorization (OAuth) protocol allows a user to grant
>>> a third-party Web site or application access to the user's protected
>>> resources, without necessarily revealing their long-term credentials,
>>> or even their identity. For example, a photo-sharing site that supports
>>> OAuth could allow its users to use a third-party printing Web site to
>>> print their private pictures, without allowing the printing site to
>>> gain full control of the user's account and without having the user=20
>>> sharing his or her photo-sharing sites' long-term credential with the=20=

>>> printing site.=20
>>> =20
>>> The OAuth protocol suite encompasses
>>> * a procedure for allowing a client to discover a resource server,=20
>>> * a protocol for obtaining authorization tokens from an authorization=20=

>>> server with the resource owner's consent,=20
>>> * protocols for presenting these authorization tokens to protected=20
>>> resources for access to a resource, and=20
>>> * consequently for sharing data in a security and privacy respective way=
.
>>> =20
>>> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
>>> was published as an informational document (RFC 5849). With the=20
>>> completion of OAuth 1.0 the working group started their work on OAuth 2.=
0
>>> to incorporate implementation experience with version 1.0, additional
>>> use cases, and various other security, readability, and interoperability=

>>> improvements. An extensive security analysis was conducted and the resul=
t=20
>>> is available as a stand-alone document offering guidance for audiences=20=

>>> beyond the community of protocol implementers.
>>> =20
>>> The working group also developed security schemes for presenting authori=
zation
>>> tokens to access a protected resource. This led to the publication of
>>> the bearer token as well as the message authentication code (MAC) access=
=20
>>> authentication specification.=20
>>> =20
>>> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH t=
oken with=20
>>> the SAML 2.0 bearer assertion profile.  This offers interworking with ex=
isting=20
>>> identity management solutions, in particular SAML based deployments.
>>> =20
>>> OAuth has enjoyed widespread adoption by the Internet application servic=
e provider=20
>>> community. To build on this success we aim for nothing more than to make=
 OAuth the=20
>>> authorization framework of choice for any Internet protocol. Consequentl=
y, the=20
>>> ongoing standardization effort within the OAuth working group is focused=
 on=20
>>> enhancing interoperability of OAuth deployments. While the core OAuth sp=
ecification=20
>>> truly is an important building block it relies on other specifications i=
n order to=20
>>> claim completeness. Luckily, these components already exist and have bee=
n deployed=20
>>> on the Internet. Through the IETF standards process they will be improve=
d in=20
>>> quality and will undergo a rigorous review process.=20
>>> =20
>>> Goals and Milestones
>>> =20
>>> [Editor's Note: Here are the completed items.]=20
>>> =20
>>> Done     Submit 'OAuth 2.0 Threat Model and Security Considerations' as a=
 working group item
>>> Done     Submit 'HTTP Authentication: MAC Authentication' as a working g=
roup item
>>> Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for c=
onsideration as a Proposed Standard
>>> Done     Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for c=
onsideration as a Proposed Standard
>>> =20
>>> [Editor's Note: Finishing existing work. Double-check the proposed dates=
 - are they realistic?]=20
>>> =20
>>> Jun. 2012       Submit 'HTTP Authentication: MAC Authentication' to the I=
ESG for consideration as a Proposed Standard
>>> Apr. 2012       Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0=
' to the IESG for consideration as a Proposed Standard
>>> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consider=
ation as a Proposed Standard=20
>>> Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for c=
onsideration as a Proposed Standard=20
>>> May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' t=
o the IESG for consideration as an Informational RFC
>>> =20
>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>> =20
>>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a=
 Proposed Standard
>>> =20
>>> [Starting point for the work will be http://datatracker.ietf.org/doc/dra=
ft-lodderstedt-oauth-revocation/]
>>> =20
>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration=
 as a Proposed Standard
>>> =20
>>> [Starting point for the work will be http://tools.ietf.org/html/draft-jo=
nes-json-web-token]
>>> =20
>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAut=
h 2.0' to the IESG for consideration as a Proposed Standard
>>> =20
>>> [Starting point for the work will be http://tools.ietf.org/html/draft-jo=
nes-oauth-jwt-bearer]
>>> =20
>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the I=
ESG for consideration as a Proposed Standard
>>> =20
>>> [Starting point for the work will be http://tools.ietf.org/html/draft-ha=
rdjono-oauth-dynreg]=20
>>> =20
>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as a=
n Informational RFC
>>> =20
>>> [Starting point for the work will be http://tools.ietf.org/html/draft-ze=
ltsan-oauth-use-cases]=20
>>> =20
>>> =20
>>> =20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> =20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20

--Apple-Mail-DC4C41A9-B4CE-4D72-ABBC-63050B15E0C6
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=utf-8


Agree that they are separate. For the use case I gave the fundamental requi

Sent from my iPhone

On 2012-03-15, at 9:22 AM, "Richer, Justin P." <jricher@mitre.org> wrote:











4) wrt revocation, we definitely see use cases  (enterprise employee is issued long lived refresh token for a mobile SaaS app, then gets fired and so enterprise needs to turn off the access) but can probably
 achieve the equivalent with a SCIM 'delete user' message











Token revocation and user deletion are completely separate issues -- there's no real overlap here. It's about closing the session management gap (for both access and refresh tokens) and it has nothing to do with deprovisioning a user in a system. In many
 cases, there might not even be a "user" that the token directly represents, or the client wouldn't know enough about them to make a delete user message. And that's a very good thing -- Would you really want to give every delegated client the ability to delete
 your account when it felt like it? Absolutely not - that level of power is completely counter to the whole point of delegated access. 







Plus, for what it's worth, it's pretty much finished already and we've implemented the endpoint already, too. 












To answer Hannes's original question, I think the WG's priorities from the list ought to be, in rough order:







1) Revocation (for reasons above)


2) Dynamic Registration (big need for this and several drafts already out there to start from)


3) JWT Bearer (it matches the profile for saml bearer and fits in the OAuth world well)


4) JWT, if no one else will take it (and it is basically done, and well deployed already)


5) Use cases (since it's informational and bound to cause some level of controversy, I wouldn't want to see this really detract from the real normative standards work, and don't think it should be counted against the total)







For other documents discussed, like XML encoding, SWD, UX, and things like that, other avenues *may* be a better fit and I'm happy with pursuing some of these myself. But with so much of the work on these and other documents already done, many of the same
 arguments for inclusion of the above five apply.







 -- Justin






On 3/15/12 7:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:







Hi Paul,



 


Interesting stuff. Thanks for sharing your draft writeup with us.



 


Could you submit the document as Internet Draft when the submission gates open again?



The I-D submission tool will be reopened at 00h UTC, 2012-03-26.


 


From the current list of items what do you consider less important?


 


Ciao


Hannes


 








From:
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of ext Paul Madsen

Sent: Thursday, March 15, 2012 12:35 PM

To: Richer, Justin P.

Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering






 


+1 to defining RS-AS interactions. We've implemented such a 'token introspection' endpoint in our AS and I'm be happy to no longer need to explain to customers/partners why it's not part of
 the standard.



As input, an (incomplete) spec for our endpoint enclosed. (we modeled the verification as a new grant type, leveraging as much as possible the existing token endpoint API)



Wrt the 5 item limit



1) is this an arbitrary #? if people sign up to work on more items, could it be extended?

2) the use cases document seems already well progressed (and informational). Need it count against the 5?



paul



On 3/14/12 5:53 PM, Richer, Justin P. wrote: 


Methods of connecting the PR to the AS are something that several groups have invented outside of the OAuth WG, and I think we should try to pull some of this work together. OAuth2 gives us a logical separation of the concerns but not a way to knit them back together. 


 


Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID, and several "token introspection" endpoints in various implementations.


 


 -- Justin


 


On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:


 




So, here is a proposal:


 


-------


 


Web Authorization Protocol (oauth)


 


Description of Working Group


 


The Web Authorization (OAuth) protocol allows a user to grant


a third-party Web site or application access to the user's protected


resources, without necessarily revealing their long-term credentials,


or even their identity. For example, a photo-sharing site that supports


OAuth could allow its users to use a third-party printing Web site to


print their private pictures, without allowing the printing site to


gain full control of the user's account and without having the user 


sharing his or her photo-sharing sites' long-term credential with the 


printing site. 


 


The OAuth protocol suite encompasses


* a procedure for allowing a client to discover a resource server, 


* a protocol for obtaining authorization tokens from an authorization 


server with the resource owner's consent, 


* protocols for presenting these authorization tokens to protected 


resources for access to a resource, and 


* consequently for sharing data in a security and privacy respective way.


 


In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,


was published as an informational document (RFC 5849). With the 


completion of OAuth 1.0 the working group started their work on OAuth 2.0


to incorporate implementation experience with version 1.0, additional


use cases, and various other security, readability, and interoperability


improvements. An extensive security analysis was conducted and the result 


is available as a stand-alone document offering guidance for audiences 


beyond the community of protocol implementers.


 


The working group also developed security schemes for presenting authorization


tokens to access a protected resource. This led to the publication of


the bearer token as well as the message authentication code (MAC) access 


authentication specification. 


 


OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with 


the SAML 2.0 bearer assertion profile.  This offers interworking with existing 


identity management solutions, in particular SAML based deployments.


 


OAuth has enjoyed widespread adoption by the Internet application service provider 


community. To build on this success we aim for nothing more than to make OAuth the 


authorization framework of choice for any Internet protocol. Consequently, the 


ongoing standardization effort within the OAuth working group is focused on 


enhancing interoperability of OAuth deployments. While the core OAuth specification 


truly is an important building block it relies on other specifications in order to 


claim completeness. Luckily, these components already exist and have been deployed 


on the Internet. Through the IETF standards process they will be improved in 


quality and will undergo a rigorous review process. 


 


Goals and Milestones


 


[Editor's Note: Here are the completed items.] 


 


Done     Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item


Done     Submit 'HTTP Authentication: MAC Authentication' as a working group item


Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard


Done     Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard


 


[Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] 


 


Jun. 2012       Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard


Apr. 2012       Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard


Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard 


Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard 


May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC


 


[Editor's Note: New work for the group. 5 items maximum! ]


 


Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard


 


[Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]


 


Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard


 


[Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]


 


Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard


 


[Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]


 


Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard


 


[Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] 


 


Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC


 


[Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] 


 


 


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ietf.org/mailman/listinfo/oauth




 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ietf.org/mailman/listinfo/oauth









_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth











--Apple-Mail-DC4C41A9-B4CE-4D72-ABBC-63050B15E0C6--

From eran@hueniverse.com  Thu Mar 15 07:45:36 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AA021F863E for ; Thu, 15 Mar 2012 07:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level: 
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW2XQ5Xrs7nu for ; Thu, 15 Mar 2012 07:45:34 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id CFF9121F8648 for ; Thu, 15 Mar 2012 07:45:34 -0700 (PDT)
Received: (qmail 5107 invoked from network); 15 Mar 2012 14:45:33 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Mar 2012 14:45:33 -0000
Received: from P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.47]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id lqlY1i00111lQaG01qlZ1v; Thu, 15 Mar 2012 07:45:33 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 15 Mar 2012 07:45:30 -0700
From: Eran Hammer 
To: Nat Sakimura , Breno de Medeiros , OAuth WG 
Date: Thu, 15 Mar 2012 07:45:20 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0CiojBIiokKrGLS8qyc3KbuKLKkwAL1Wpw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF089F4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF0896E@P3PW5EX1MB01.EX1.SECURESERVER.NET>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AFF089F4P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 14:45:36 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E723453AFF089F4P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This add-on is unnecessary. It already says the authorization server can ha=
ndle it any way it wants. The fact that other registration options are poss=
ible clearly covers the client identifier reuse case. As for the response t=
ype, that's not an issue but more of an optimization for an edge case raise=
d.

EH

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N=
at Sakimura
Sent: Thursday, March 15, 2012 2:04 AM
To: Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23


So, Eran's first proposal:

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex client=
s.

kind of meets my concern. There seems to be another issue around the useful=
ness of return_type in such case raised by Breno, and if I understand it co=
rrectly, Eran's answer was that these separate components may have the same=
 client_id so that return_type is a valid parameter to be sent at the reque=
st.

So, to clarify these, perhaps changing the above text slightly to the follo=
wing solves the problem?

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex client=
s.
  Each component MAY have the same client_id, in which case the server
  judges the client type and the associated security context  based on
  the response_type parameter in the request.

Would it solve your problem, Breno?

Best,

=3Dnat


--_000_90C41DD21FB7C64BB94121FBBC2E723453AFF089F4P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This add-=
on is unnecessary. It already says the authorization server can handle it a=
ny way it wants. The fact that other registration options are possible clea=
rly covers the client identifier reuse case. As for the response type, that=
’s not an issue but more of an optimization for an edge case raised.<=
o:p>
 
EH
=
 
Fro=
m: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O=
f Nat Sakimura
Sent: Thursday, March 15, 2012 2:04 AM
T=
o: Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Br=
eaking change in OAuth 2.0 rev. 23
 
 
So, Eran's first proposal: 
=

 
  A client application consisting of multiple component=
s, each with its
  own client type (e.g. a distributed client with =
both a confidential
  server-based component and a public browser-b=
ased component), MUST
  register each component separately as a dif=
ferent client to ensure
  pro=
per handling by the authorization server, unless the authorization
 =
; server provides other registration options to specify such complex client=
s. 
 
kind of meets my concern. There seems to b=
e another issue around the usefulness of return_type in such case raised by=
 Breno, and if I understand it correctly, Eran's answer was that these sepa=
rate components may have the same client_id so that return_type is a valid =
parameter to be sent at the request. 
 
So, to c=
larify these, perhaps changing the above text slightly to the following sol=
ves the problem? 
&=
nbsp;
  A client applica=
tion consisting of multiple components, each with its
  own client =
type (e.g. a distributed client with both a confidential
  server-b=
ased component and a public browser-based component), MUST
  regist=
er each component separately as a different client to ensure
=

  proper handling by the authorization serv=
er, unless the authorization
  server provides other registration o=
ptions to specify such complex clients.  
  Each component MAY =
have the same client_id, in which case the server 
  judges t=
he client type and the associated security context  based on 
 =
; the response_type parameter in the request. 
 
Would it solve your problem, Breno? 
=

 
B=
est, 
 <=
/p>
=3Dnat
 
=

--_000_90C41DD21FB7C64BB94121FBBC2E723453AFF089F4P3PW5EX1MB01E_--

From eran@hueniverse.com  Thu Mar 15 07:58:08 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F2721F86C3 for ; Thu, 15 Mar 2012 07:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-Jt5KI0-PKh for ; Thu, 15 Mar 2012 07:58:07 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 29C1621F8666 for ; Thu, 15 Mar 2012 07:58:07 -0700 (PDT)
Received: (qmail 25774 invoked from network); 15 Mar 2012 14:58:02 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Mar 2012 14:58:02 -0000
Received: from P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id lqy21i0060SoFT401qy20d; Thu, 15 Mar 2012 07:58:02 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 15 Mar 2012 07:56:16 -0700
From: Eran Hammer 
To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ext Barry Leiba , Hannes Tschofenig 
Date: Thu, 15 Mar 2012 07:56:07 -0700
Thread-Topic: [OAUTH-WG] Agenda Proposal
Thread-Index: Ac0CIIIc3nFnnki4T12JMlgUcSK2mAAadluQAAw/0tA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF089F9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <30401997-7A6A-4306-B909-2EEAE80AA90D@gmx.net>  <999913AB42CC9341B05A99BBF358718D0138296E@FIESEXC035.nsn-intra.net>
In-Reply-To: <999913AB42CC9341B05A99BBF358718D0138296E@FIESEXC035.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 14:58:08 -0000

The only reason it is taking a long time is lack of WG feedback and total l=
ack of attention from the chairs. If you are looking to improve delivery ti=
me, I would start by getting more involved and help drive issues to complet=
ion. Suggesting the problem is with the single author is unfounded and offe=
nsive.

EH



> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Thursday, March 15, 2012 2:03 AM
> To: ext Barry Leiba; Hannes Tschofenig
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Agenda Proposal
>=20
> Thanks for the info, Barry.
>=20
> I would, however, like to find an additional co-author from the group to
> ensure accelerated process
>=20
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of ext Barry Leiba
> > Sent: Wednesday, March 14, 2012 10:25 PM
> > To: Hannes Tschofenig
> > Cc: oauth@ietf.org WG
> > Subject: Re: [OAUTH-WG] Agenda Proposal
> >
> > Oh, and...
> >
> > > 4. MAC Token (TBD)
> > > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/
> >
> > I believe that in Eran's last communication about this he said that he
> > does, after all, have the time and inclination to finish it, and would
> > like to.
> >
> > b
> > _______________________________________________
> > 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 eran@hueniverse.com  Thu Mar 15 08:01:08 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B7E21F8652 for ; Thu, 15 Mar 2012 08:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5Qk6mvVF952 for ; Thu, 15 Mar 2012 08:01:07 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 7027921F8732 for ; Thu, 15 Mar 2012 08:01:07 -0700 (PDT)
Received: (qmail 30974 invoked from network); 15 Mar 2012 15:01:07 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Mar 2012 15:01:07 -0000
Received: from P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id lr161i0040SoFT401r17BU; Thu, 15 Mar 2012 08:01:07 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 15 Mar 2012 08:00:20 -0700
From: Eran Hammer 
To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ext Blaine Cook , Hannes Tschofenig 
Date: Thu, 15 Mar 2012 08:00:11 -0700
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: Ac0CnzJzNsQfN7a4RL6KgAEUAk1PowAAfdrQAAbBvTA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net>
In-Reply-To: <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 15:01:09 -0000

SSBiZWxpZXZlIG1vc3QgZG8sIGV4Y2VwdCBmb3IgdGhlIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJh
dGlvbi4gSSBkb24ndCBoYXZlIHN0cm9uZyBvYmplY3Rpb25zIHRvIGl0LCBidXQgaXQgaXMgdGhl
IGxlYXN0IGltcG9ydGFudCBhbmQgbGVhc3QgZGVmaW5lZCAvIGRlcGxveWVkIHByb3Bvc2FsIG9u
IHRoZSBsaXN0LiBUaGUgQVMtPlJTIHdvcmsgaXMgcHJvYmFibHkgc2ltcGxlciBhbmQgbW9yZSB1
c2VmdWwgYXQgdGhpcyBwb2ludC4NCg0KRUgNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIFRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNw
b28pDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNSwgMjAxMiA0OjQ3IEFNDQo+IFRvOiBleHQg
QmxhaW5lIENvb2s7IEhhbm5lcyBUc2Nob2ZlbmlnDQo+IENjOiBvYXV0aEBpZXRmLm9yZw0KPiBT
dWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCBXRyBSZS1DaGFydGVyaW5nDQo+IA0KPiBIaSBC
bGFpbmUsDQo+IA0KPiBUaGVzZSBhcmUgaW5kZWVkIGdvb2QgcmVxdWlyZW1lbnRzIHlvdSBzdGF0
ZWQgYmVsb3cuDQo+IA0KPiBXaGVuIHlvdSBsb29rIGF0IHRoZSBsaXN0IG9mIHRvcGljcyBkbyB5
b3UgdGhpbmsgdGhhdCB0aGUgcHJvcG9zZWQgaXRlbXMNCj4gaW5kZWVkIGZ1bGZpbGwgdGhlbT8N
Cj4gDQo+IENpYW8NCj4gSGFubmVzDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiA+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiBPZiBleHQgQmxhaW5lIENvb2sNCj4gPiBTZW50
OiBUaHVyc2RheSwgTWFyY2ggMTUsIDIwMTIgMTozMSBQTQ0KPiA+IFRvOiBIYW5uZXMgVHNjaG9m
ZW5pZw0KPiA+IENjOiBvYXV0aEBpZXRmLm9yZyBXRw0KPiA+IFN1YmplY3Q6IFJlOiBbT0FVVEgt
V0ddIE9BdXRoIFdHIFJlLUNoYXJ0ZXJpbmcNCj4gPg0KPiA+IE9uIDE0IE1hcmNoIDIwMTIgMjA6
MjEsIEhhbm5lcyBUc2Nob2ZlbmlnDQo+IDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pg0KPiA+
IHdyb3RlOg0KPiA+ID4gU28sIGhlcmUgaXMgYSBwcm9wb3NhbDoNCj4gPiA+DQo+ID4gPiBbRWRp
dG9yJ3MgTm90ZTogTmV3IHdvcmsgZm9yIHRoZSBncm91cC4gNSBpdGVtcyBtYXhpbXVtISBdDQo+
ID4gPg0KPiA+ID4gQXVnLiAyMDEyIMKgIMKgU3VibWl0ICdUb2tlbiBSZXZvY2F0aW9uJyB0byB0
aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbg0KPiA+IGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQNCj4g
PiA+IE5vdi4gMjAxMiDCoCDCoFN1Ym1pdCAnSlNPTiBXZWIgVG9rZW4gKEpXVCknIHRvIHRoZSBJ
RVNHIGZvcg0KPiA+IGNvbnNpZGVyYXRpb24gYXMgYSBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4g
Tm92LiAyMDEyIMKgIMKgU3VibWl0ICdKU09OIFdlYiBUb2tlbiAoSldUKSBCZWFyZXIgVG9rZW4g
UHJvZmlsZXMgZm9yDQo+ID4gT0F1dGggMi4wJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlv
bg0KPiA+ID4gSmFuLiAyMDEzIMKgIMKgU3VibWl0ICdPQXV0aCBEeW5hbWljIENsaWVudCBSZWdp
c3RyYXRpb24gUHJvdG9jb2wnIHRvDQo+ID4gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMg
YSBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gU2VwLiAyMDEyIMKgIMKgU3VibWl0ICdPQXV0aCBV
c2UgQ2FzZXMnIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uDQo+ID4gYXMgYW4gSW5mb3Jt
YXRpb25hbCBSRkMNCj4gPg0KPiA+IFRoaXMgbG9va3MgZ3JlYXQgdG8gbWUuDQo+ID4NCj4gPiBJ
IGhhdmUgc2VyaW91cyBjb25jZXJucyBhYm91dCBmZWF0dXJlLWNyZWVwLCBhbmQgdGhpbmsgdGhh
dCB0aGUgT0F1dGgNCj4gPiBXRyBzaG91bGQgc3Ryb25nbHkgbGltaXQgaXRzIHB1cnZpZXcgdG8g
dGhlc2UgaXNzdWVzLiBJbiBnZW5lcmFsLCBJDQo+ID4gdGhpbmsgaXQgcHJ1ZGVudCBmb3IgdGhp
cyB3b3JraW5nIGdyb3VwIGluIHBhcnRpY3VsYXIgdG8gY29uc2lkZXINCj4gPiBzdGFuZGFyZGlz
YXRpb24gb2Ygd29yayBvbmx5IHVuZGVyIHRoZSBmb2xsb3dpbmcgY3JpdGVyaWE6DQo+ID4NCj4g
PiAxLiBQcm9wb3NhbHMgbXVzdCBoYXZlIGEgZGlyZWN0IHJlbGF0aW9uc2hpcCB0byB0aGUgbWVj
aGFuaXNtIG9mIE9BdXRoDQo+ID4gKGFuZCBub3QsIHNwZWNpZmljYWxseSwgYm91bmQgdG8gYW4g
YXBwbGljYXRpb24tbGV2ZWwgcHJvdG9jb2wpLg0KPiA+IDIuIFByb3Bvc2FscyBtdXN0IGhhdmUg
c2lnbmlmaWNhbnQgYWRvcHRpb24gaW4gYm90aCBlbnRlcnByaXNlIGFuZA0KPiA+IHN0YXJ0dXAg
ZW52aXJvbm1lbnRzLg0KPiA+IDMuIEFueSBwcm9wb3NhbCBtdXN0IGJlIGRyaXZlbiBiYXNlZCBv
biBhIGNvbnNpZGVyYXRpb24gb2YgdGhlDQo+ID4gZGlmZmVyZW50IGFwcHJvYWNoZXMsIGFzIGFk
b3B0ZWQgaW4gdGhlIHdpbGQsIGFuZCBzdHJpdmUgdG8gYmUgYQ0KPiA+IGJldHRlciBzeW50aGVz
aXMgb2YgdGhvc2UgYXBwcm9hY2hlcywgbm90IGEgbWVhbnMgdG8gYW4gZW5kLg0KPiA+DQo+ID4g
VGhlc2UgYXJlIHRoZSBjb25zdHJhaW50cyB3aXRoIHdoaWNoIEkgc3RhcnRlZCB0aGUgT0F1dGgg
cHJvamVjdCwgYW5kDQo+ID4gdGhleSdyZSBtb3JlIHJlbGV2YW50IHRoYW4gZXZlci4gSSdkIGhh
dGUgdG8gc2VlIE9BdXRoIGZhaWwgaW4gdGhlIGVuZA0KPiA+IGJlY2F1c2Ugb2YgYSBXUy0qLWxp
a2UgZGVhdGggYnkgc3RhbmRhcmRzLXBpbGUtb24uDQo+ID4NCj4gPiBiLg0KPiA+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo=

From breno@google.com  Thu Mar 15 09:56:18 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E68A21F87C1 for ; Thu, 15 Mar 2012 09:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.677
X-Spam-Level: 
X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMLsQ6VuI8Ag for ; Thu, 15 Mar 2012 09:56:17 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A949221F878A for ; Thu, 15 Mar 2012 09:56:15 -0700 (PDT)
Received: by eeke51 with SMTP id e51so1918872eek.31 for ; Thu, 15 Mar 2012 09:56:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=28MZn55QkYCz74ySerPnHhpTrI5+UJXceJrQjitda5I=; b=OjpDVebApjVqC2vpEzyRu5Fe9yLZK0dn2amLlbRBGpzR4h6vt9XgFHYl5e3VE8kGIW NM/JokLbOVYU2x9kHgIcq93z2wc2bfnZ5T9KU9PwuXXJi3z+/r49PmEOGXCwRhQdTOFG HGMqOd0wp8Q/LwxaqFihhFmwHbEQrc/LsZVgSMi+Hq8ihRm/XG5QhkAOuTkF4bK3t6qi y1vmcVdWChNFRT8caRsCA5iu0GvBfkRsIjS/FR+ZK/eJhqmc5KCF/7bt613mO1NW/eGn T8btPgKADaMHXwvaDaym6UdGUE5Uh2rIKhT6IOfRD5FPmU1QXooEMOG3/bcPRiofJRwz Y/AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=28MZn55QkYCz74ySerPnHhpTrI5+UJXceJrQjitda5I=; b=KqYKuZk2JiUOJ1sy+jDhOI60wzjcEoc77SynK/d89AQ2NLmb0vt+sudErQYTZN+XW4 EFOlnHLo4qOoX3SbGzznGmE9OONyRgq+B3HH21Fp4eAwPIkJvdrqBNgDRYnZ0sBIxz8y BJqowwFZYvWXB9KAFGLAl+t15UvZTIXZgWj1/0ZXmX1l7vNUMicsJNbvTVnI1wR1DE+P MADVuclsO8J/Pv0xNaW189NLH1HVMnHnbYt7xKjw+7Bqc4GhHpL9wkeC42Avjh28kIke Pc5tsFk7GJXIlPRORQbTSq1DFehfqiMjErnrZNqDKYSNQA7TnhceSqLSKzmi7QR/f7Ca p2/w==
Received: by 10.50.155.202 with SMTP id vy10mr2524276igb.29.1331830574412; Thu, 15 Mar 2012 09:56:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.155.202 with SMTP id vy10mr2524262igb.29.1331830574319; Thu, 15 Mar 2012 09:56:14 -0700 (PDT)
Received: by 10.231.41.137 with HTTP; Thu, 15 Mar 2012 09:56:13 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF089F4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF0896E@P3PW5EX1MB01.EX1.SECURESERVER.NET>    <90C41DD21FB7C64BB94121FBBC2E723453AFF089F4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 15 Mar 2012 09:56:13 -0700
Message-ID: 
From: Breno de Medeiros 
To: Eran Hammer 
Content-Type: multipart/alternative; boundary=e89a8f23549f488a9b04bb4af8fa
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkMwWC68mzSDW6JUzgLDazyBXxlbaykSvjX/g7gv5VdjvP15Mm9VgmwkY3Zv514BnH7Noq2vw2JF3OwF9TVX+qjMg6gDnEK0YpTeotB5cpgOG6UmNq4q1rqbA8JTvyKDaOo4/MT
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 16:56:18 -0000

--e89a8f23549f488a9b04bb4af8fa
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 15, 2012 at 07:45, Eran Hammer  wrote:

> This add-on is unnecessary. It already says the authorization server can
> handle it any way it wants. The fact that other registration options are
> possible clearly covers the client identifier reuse case. As for the
> response type, that=92s not an issue but more of an optimization for an e=
dge
> case raised.
>

It still feels like a horse by committee to me. "unless the
authorization server
provides other registration options to specify such complex clients." seems
a very round about way to say that the core spec already provides for such
arrangements in the most common scenario. It is a bit of a stretch to say
that the server provides "other registration options" by simply following
strategy already laid out in the spec.

In particular, I feel that this wording will be harmful to register
extended behavior, e.g., alternative response_types by leading to fruitless
conversations about spec compliance in the absence of real security risks.

I do not believe the current text is the best representation of the spirit
in which the spec was written (in particular the effort to specify two
flows in detail to deal with precisely this issue) and possibly lead to
harmful future interpretation.


> ****
>
> ** **
>
> EH****
>
> ** **
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Thursday, March 15, 2012 2:04 AM
> *To:* Breno de Medeiros; OAuth WG
>
> *Subject:* Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23****
>
> ** **
>
> ** **
>
> So, Eran's first proposal: ****
>
> ** **
>
>   A client application consisting of multiple components, each with its
>   own client type (e.g. a distributed client with both a confidential
>   server-based component and a public browser-based component), MUST
>   register each component separately as a different client to ensure****
>
>   proper handling by the authorization server, unless the authorization
>   server provides other registration options to specify such complex
> clients. ****
>
> ** **
>
> kind of meets my concern. There seems to be another issue around the
> usefulness of return_type in such case raised by Breno, and if I understa=
nd
> it correctly, Eran's answer was that these separate components may have t=
he
> same client_id so that return_type is a valid parameter to be sent at the
> request. ****
>
> ** **
>
> So, to clarify these, perhaps changing the above text slightly to the
> following solves the problem? ****
>
> ** **
>
>   A client application consisting of multiple components, each with its
>   own client type (e.g. a distributed client with both a confidential
>   server-based component and a public browser-based component), MUST
>   register each component separately as a different client to ensure****
>
>   proper handling by the authorization server, unless the authorization
>   server provides other registration options to specify such complex
> clients.  ****
>
>   Each component MAY have the same client_id, in which case the server **=
*
> *
>
>   judges the client type and the associated security context  based on
>   the response_type parameter in the request. ****
>
> ** **
>
> Would it solve your problem, Breno? ****
>
> ** **
>
> Best, ****
>
> ** **
>
> =3Dnat****
>
> ** **
>



--=20
--Breno

--e89a8f23549f488a9b04bb4af8fa
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Thu, Mar 15, 2012 at 07:45, Eran Hamm=
er <eran@hueniv=
erse.com> wrote:


This add-on is unnecessary. It already says =
the authorization server can handle it any way it wants. The fact that othe=
r registration options are possible clearly covers the client identifier re=
use case. As for the response type, that=92s not an issue but more of an op=
timization for an edge case raised.



It still feels like a horse by=
 committee to me. "unless=A0the authorization=A0server provides other registration options to specify such complex=
 clients." seems a very round about way to say that the core spec alre=
ady provides for such arrangements in the most common scenario. It is a bit=
 of a stretch to say that the server provides "other registration opti=
ons" by simply following strategy already laid out in the spec.=




In particular, I feel th=
at this wording will be harmful to register extended behavior, e.g., altern=
ative response_types by leading to fruitless conversations about spec compl=
iance in the absence of real security risks.



I do not believe the cur=
rent text is the best representation of the spirit in which the spec was wr=
itten (in particular the effort to specify two flows in detail to deal with=
 precisely this issue) and possibly lead to harmful future interpretation.<=
/span>


=A0


=A0<=
/p>
EH


=A0<=
/p>


From: oauth-bou=
nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 15, 2012 2:04 AM
To: Breno de Medeir=
os; OAuth WG

Subject: Re: [OAUTH-WG]=
 Fw: Breaking change in OAuth 2.0 rev. 23


=A0
=A0
So, Eran's first proposa=
l:=A0
=A0


=A0 A client application consisting =
of multiple components, each with its
=A0 own client type (e.g. a distri=
buted client with both a confidential
=A0 server-based component and a p=
ublic browser-based component), MUST

=A0 register each component separately as a different client to ensure
=A0 proper handling by the author=
ization server, unless the authorization
=A0 server provides other regis=
tration options to specify such complex clients.=A0


=A0
kind of meets my concern. There seems to be another issue ar=
ound the usefulness of return_type in such case raised by Breno, and if I u=
nderstand it correctly, Eran's answer was that these separate component=
s may have the same client_id so that return_type is a valid parameter to b=
e sent at the request.=A0


=A0
So, to clarify these, perhaps changing the above text slight=
ly to the following solves the problem?=A0

=A0
=A0 A client ap=
plication consisting of multiple components, each with its
=A0 own clien=
t type (e.g. a distributed client with both a confidential
=A0 server-ba=
sed component and a public browser-based component), MUST

=A0 register each component separately as a different client to ensure
=A0 proper handling by the author=
ization server, unless the authorization
=A0 server provides other regis=
tration options to specify such complex clients.=A0=A0


=A0 Each compon=
ent MAY have the same client_id, in which case the server=A0<=
u>
=A0 j=
udges the client type and the associated security context =A0based on 

=A0 the response_type parameter in the request.=A0
=

=A0
Would it solve your problem, Breno?=A0

=A0
Best,=A0
=A0
=3Dnat
=A0





-- 
--Breno


--e89a8f23549f488a9b04bb4af8fa--

From Michael.Jones@microsoft.com  Thu Mar 15 10:07:50 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B41821F87B5 for ; Thu, 15 Mar 2012 10:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.847
X-Spam-Level: 
X-Spam-Status: No, score=-3.847 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqePz0vjxc8M for ; Thu, 15 Mar 2012 10:07:48 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 26B0321F842D for ; Thu, 15 Mar 2012 10:07:47 -0700 (PDT)
Received: from mail203-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Thu, 15 Mar 2012 17:07:47 +0000
Received: from mail203-ch1 (localhost [127.0.0.1])	by mail203-ch1-R.bigfish.com (Postfix) with ESMTP id CB92B4203FD; Thu, 15 Mar 2012 17:07:47 +0000 (UTC)
X-SpamScore: -27
X-BigFish: VS-27(zz9371Ic85fh4015I1419Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail203-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail203-ch1 (localhost.localdomain [127.0.0.1]) by mail203-ch1 (MessageSwitch) id 1331831265632366_11472; Thu, 15 Mar 2012 17:07:45 +0000 (UTC)
Received: from CH1EHSMHS023.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225])	by mail203-ch1.bigfish.com (Postfix) with ESMTP id 97BBEE004C;	Thu, 15 Mar 2012 17:07:45 +0000 (UTC)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 15 Mar 2012 17:07:45 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Thu, 15 Mar 2012 17:07:20 +0000
From: Mike Jones 
To: Eran Hammer , Nat Sakimura , Breno de Medeiros , OAuth WG 
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: AQHNAgMKtRI52qb7tE6+kmeeW24qnZZqBiQAgAACNICAAA7JAIAABA0AgAADMYCAAACtcIAABZMAgAAVJQCAAAHFAIAAAp4AgAAE2YCAAAAhgIAAzdQAgABfgQCAACaV8A==
Date: Thu, 15 Mar 2012 17:07:20 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436641F82B@TK5EX14MBXC284.redmond.corp.microsoft.com>
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF0896E@P3PW5EX1MB01.EX1.SECURESERVER.NET>    <90C41DD21FB7C64BB94121FBBC2E723453AFF089F4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF089F4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436641F82BTK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 17:07:50 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436641F82BTK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I disagree.  The add-on is necessary exactly because several OAuth experts =
(Breno, Marius, Nat, John, Nov, and I) all read the new text as a breaking =
change that prohibited exactly what the new text explicitly allows.  Given =
you agree that it doesn't change the meaning, there's no harm in adding the=
 text below, and plenty of good for the clarification it provides.

I agree with Nat.  Please add:
  Each component MAY have the same client_id, in which case the server
  judges the client type and the associated security context  based on
  the response_type parameter in the request.

Or if you dislike that, just add:
  Each component MAY have the same client_id.

                                                            Thanks,
                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E=
ran Hammer
Sent: Thursday, March 15, 2012 7:45 AM
To: Nat Sakimura; Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

This add-on is unnecessary. It already says the authorization server can ha=
ndle it any way it wants. The fact that other registration options are poss=
ible clearly covers the client identifier reuse case. As for the response t=
ype, that's not an issue but more of an optimization for an edge case raise=
d.

EH

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Nat S=
akimura
Sent: Thursday, March 15, 2012 2:04 AM
To: Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23


So, Eran's first proposal:

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex client=
s.

kind of meets my concern. There seems to be another issue around the useful=
ness of return_type in such case raised by Breno, and if I understand it co=
rrectly, Eran's answer was that these separate components may have the same=
 client_id so that return_type is a valid parameter to be sent at the reque=
st.

So, to clarify these, perhaps changing the above text slightly to the follo=
wing solves the problem?

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex client=
s.
  Each component MAY have the same client_id, in which case the server
  judges the client type and the associated security context  based on
  the response_type parameter in the request.

Would it solve your problem, Breno?

Best,

=3Dnat


--_000_4E1F6AAD24975D4BA5B16804296739436641F82BTK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I disagree.  The add=
-on is necessary exactly because several OAuth experts (Breno, Marius, Nat,=
 John, Nov, and I) all read the new text as a breaking change
 that prohibited exactly what the new text explicitly allows.  Given y=
ou agree that it doesn’t change the meaning, there’s no harm in=
 adding the text below, and plenty of good for the clarification it provide=
s.


 <=
/p>

I agree with Nat.  P=
lease add:


  Each component MAY =
have the same client_id, in which case the server 

  judges the client t=
ype and the associated security context  based on


  the response_type parameter in the request. <=
/p>

 <=
/p>

Or if you dislike that, j=
ust add:


  Each component MAY =
have the same client_id.


 <=
/p>

    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     Thanks,


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


 <=
/p>





From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Eran Hammer

Sent: Thursday, March 15, 2012 7:45 AM

To: Nat Sakimura; Breno de Medeiros; OAuth WG

Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23






 


This add-on is unnecessar=
y. It already says the authorization server can handle it any way it wants.=
 The fact that other registration options are possible clearly
 covers the client identifier reuse case. As for the response type, that=
217;s not an issue but more of an optimization for an edge case raised.


 <=
/p>

EH


 <=
/p>







From:
oauth-bounces@ietf.org 
[mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura

Sent: Thursday, March 15, 2012 2:04 AM

To: Breno de Medeiros; OAuth WG

Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23






 


 




So, Eran's first proposal: 






 








  A client application consisting of multiple c=
omponents, each with its

  own client type (e.g. a distributed client with both a confidential<=
br>
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure




  proper handling by the authorization server, =
unless the authorization

  server provides other registration options to specify such complex c=
lients. 






 






kind of meets my concern. There seems to be another =
issue around the usefulness of return_type in such case raised by Breno, an=
d if I understand it correctly, Eran's answer was that these separate compo=
nents may have the same client_id
 so that return_type is a valid parameter to be sent at the request. <=
o:p>






 






So, to clarify these, perhaps changing the above tex=
t slightly to the following solves the problem? 






 








  A client application consisting of multiple c=
omponents, each with its

  own client type (e.g. a distributed client with both a confidential<=
br>
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure




  proper handling by the authorization server, =
unless the authorization

  server provides other registration options to specify such complex c=
lients.  






  Each component MAY =
have the same client_id, in which case the server 





  judges the client t=
ype and the associated security context  based on


  the response_type parameter in the request. <=
/p>





 






Would it solve your problem, Breno? =







 






Best, 






 






=3Dnat






 










--_000_4E1F6AAD24975D4BA5B16804296739436641F82BTK5EX14MBXC284r_--

From luca.frosini@isti.cnr.it  Thu Mar 15 10:12:38 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC3B21F87BA for ; Thu, 15 Mar 2012 10:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.045
X-Spam-Level: 
X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245,  J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ze4ep5N3MUX for ; Thu, 15 Mar 2012 10:12:36 -0700 (PDT)
Received: from blade3.isti.cnr.it (blade3.isti.cnr.it [194.119.192.19]) by ietfa.amsl.com (Postfix) with ESMTP id AF50121F878A for ; Thu, 15 Mar 2012 10:12:36 -0700 (PDT)
Received: from [146.48.87.201] by mx.isti.cnr.it (PMDF V6.5-x6 #31988) with ESMTPSA id <01OD5JURD2COL5NY52@mx.isti.cnr.it> for oauth@ietf.org; Thu, 15 Mar 2012 18:11:34 +0100 (MET)
Date: Thu, 15 Mar 2012 18:11:37 +0100
From: Luca Frosini 
To: "oauth@ietf.org" 
Message-id: <4F6222C9.5010305@isti.cnr.it>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
X-INSM-ip-source: 146.48.87.201 Auth Done
Subject: [OAUTH-WG] Some minor comments to draft-ietf-oauth-v2-25
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 17:12:38 -0000

Hello,

I have read the draft of OAuth 2 rev 2.25 for the first time, so some of 
my comments may be useless.
Sorry in advance if some of them have already been discussed and I 
didn't find it in mailing list archive.

I found a grammatical error on page number 6, row 12 'refered' I think 
should be 'referred'.

The document use 'resource owner user-agent' without having introduced 
it first.
I don't know if it is possible to insert it in chapter 1.1, but I think 
this can be useful for the reader to identify this entity. It also 
avoids to make confusion regarding what a client is.

Regards

Luca

-- 
Ing. Luca Frosini

Istituto di Scienza e Tecnologie dell'Informazione "A. Faedo" (ISTI)
Italian National Research Council (CNR)

G. Moruzzi, 1 - 56124 Pisa, Italy
Area della Ricerca CNR di Pisa

Mob: (+39)  339 7697029
Web-site: http://www.lucafrosini.com
Skype: luca.frosini


From zachary.zeltsan@alcatel-lucent.com  Thu Mar 15 10:32:13 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C857221F87D8 for ; Thu, 15 Mar 2012 10:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.398
X-Spam-Level: 
X-Spam-Status: No, score=-9.398 tagged_above=-999 required=5 tests=[AWL=1.200,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY8e2m5EY2l7 for ; Thu, 15 Mar 2012 10:32:12 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BAC6821F86AA for ; Thu, 15 Mar 2012 10:32:12 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q2FHW3lN008743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 12:32:03 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2FHVile008107 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Mar 2012 12:32:03 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 15 Mar 2012 12:31:53 -0500
From: "Zeltsan, Zachary (Zachary)" 
To: "'Mike Jones'" , "'Hannes Tschofenig'" , "'oauth@ietf.org WG'" 
Date: Thu, 15 Mar 2012 12:31:47 -0500
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAMCRIf4APwgUm5DSot8V56SZZqRR3KgAFVZUA=
Message-ID: <5710F82C0E73B04FA559560098BF95B1250DCE94E0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References:  <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B1250DCE94E0USNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 17:32:13 -0000

--_000_5710F82C0E73B04FA559560098BF95B1250DCE94E0USNAVSXCHMBSA_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M=
ike Jones
Sent: Wednesday, March 14, 2012 4:55 PM
To: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

...  Considering OpenID Connect as a motivating use case for OAuth, SWD is =
the one spec that would then be missing for this OAuth use case.

...

Mike,

I will be happy to work with you on the OpenID Connect use case.  We could =
probably submit it as a separate I-D and later include it in the Use Case d=
ocument.  I agree with with you  that this is an important use case, and it=
 ought to be there independent of where the SWD work is done; in other word=
s, I think that we just need the use case description at this point (includ=
ing, pre- and post conditions)-not the requirements or the list of dependen=
cies.

Zachary



--_000_5710F82C0E73B04FA559560098BF95B1250DCE94E0USNAVSXCHMBSA_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


From: oauth-boun=
ces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones=

Sent: Wednesday, March 14, 2012 4:55 PM
To: Hannes Tsc=
hofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Ch=
artering
 
...  Considering OpenID Connect as a motivating use case fo=
r OAuth, SWD is the one spec that would then be missing for this OAuth use =
case.

...
 
Mike,
 
I will be happy to work with you on the OpenID C=
onnect use case.  We could probably submit it as a separate I-D and la=
ter include it in the Use Case document.  I agree with with you  =
that this is an important use case, and it ought to be there independent of=
 where the SWD work is done; in other words, I think that we just need the =
use case description at this point (including, pre- and post conditions)=
212;not the requirements or the list of dependencies.
=

 
Zachary

 
=

--_000_5710F82C0E73B04FA559560098BF95B1250DCE94E0USNAVSXCHMBSA_--

From eran@hueniverse.com  Thu Mar 15 11:32:45 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1937621F861A for ; Thu, 15 Mar 2012 11:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level: 
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXl3J4MjeGpT for ; Thu, 15 Mar 2012 11:32:44 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id DD3E921F85E1 for ; Thu, 15 Mar 2012 11:32:43 -0700 (PDT)
Received: (qmail 15708 invoked from network); 15 Mar 2012 18:32:39 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Mar 2012 18:32:39 -0000
Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id luYe1i00310TkE001uYfV7; Thu, 15 Mar 2012 11:32:39 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 15 Mar 2012 11:32:39 -0700
From: Eran Hammer 
To: Breno de Medeiros 
Date: Thu, 15 Mar 2012 11:32:38 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0C2f/JtqKWc0iVTcuWnTeyUXmkCQ==
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CB87810D16509eranhueniversecom_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 18:32:45 -0000

--_000_CB87810D16509eranhueniversecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Here are the facts:

 1.  The authorization server must know the client type in order to enforce=
 many of the requirements in the specification.
 2.  The requirement to provide a client type is not decorated with a MUST =
or SHALL but that is implied.
 3.  The specification only defines two client types: public and confidenti=
al. There is no client type defined for a hybrid client.
 4.  The specification needs to address the very common use case of clients=
 with both public and private components.

I don't want to discuss in the specification how client identifiers are pro=
visioned, nor do I want to discuss the potential binding of response types =
to client types. But we do need to provide some guidance to clients and aut=
horization servers what to do with clients that do not fit the current type=
 definitions.

It is far too late for us to define a new client type, along with all the s=
ecurity considerations that such type imply. Our entire security considerat=
ion section and protocol design are based on have a well defined client typ=
e.

Requiring separate registration for each component is the most straight-for=
ward solution. Allowing the authorization server to offer alternatives is t=
he backdoor to enable extensibility.

Within these constraints, I am open to other prose or creative solutions. B=
ut the add-ons proposed are all ugly hacks. They clarify specific questions=
 raised which I do not believe represent the core confusion here which is w=
hat is the right way to handle hybrid clients.

The best way to move forward is to take a minute and ask the group to share=
 how they handle such cases or how they think they should be handled. Based=
 on that we can come up with a clear solution.

EH

From: Breno de Medeiros >
Date: Thu, 15 Mar 2012 09:56:13 -0700
To: Eran Hammer-Lahav >
Cc: Nat Sakimura >, OAuth WG =
>
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23



On Thu, Mar 15, 2012 at 07:45, Eran Hammer > wrote:
This add-on is unnecessary. It already says the authorization server can ha=
ndle it any way it wants. The fact that other registration options are poss=
ible clearly covers the client identifier reuse case. As for the response t=
ype, that=92s not an issue but more of an optimization for an edge case rai=
sed.

It still feels like a horse by committee to me. "unless the authorization s=
erver provides other registration options to specify such complex clients."=
 seems a very round about way to say that the core spec already provides fo=
r such arrangements in the most common scenario. It is a bit of a stretch t=
o say that the server provides "other registration options" by simply follo=
wing strategy already laid out in the spec.

In particular, I feel that this wording will be harmful to register extende=
d behavior, e.g., alternative response_types by leading to fruitless conver=
sations about spec compliance in the absence of real security risks.

I do not believe the current text is the best representation of the spirit =
in which the spec was written (in particular the effort to specify two flow=
s in detail to deal with precisely this issue) and possibly lead to harmful=
 future interpretation.


EH

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 15, 2012 2:04 AM
To: Breno de Medeiros; OAuth WG

Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23


So, Eran's first proposal:

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex client=
s.

kind of meets my concern. There seems to be another issue around the useful=
ness of return_type in such case raised by Breno, and if I understand it co=
rrectly, Eran's answer was that these separate components may have the same=
 client_id so that return_type is a valid parameter to be sent at the reque=
st.

So, to clarify these, perhaps changing the above text slightly to the follo=
wing solves the problem?

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex client=
s.
  Each component MAY have the same client_id, in which case the server
  judges the client type and the associated security context  based on
  the response_type parameter in the request.

Would it solve your problem, Breno?

Best,

=3Dnat




--
--Breno

--_000_CB87810D16509eranhueniversecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



Here are the facts:
    The authorization server must know the client type in order to enforce ma=
ny of the requirements in the specification.
  1. The requirement to pro=
vide a client type is not decorated with a MUST or SHALL but that is implie=
d.
  2. The specification only defines two client types: public and conf=
idential. There is no client type defined for a hybrid client.
  3. The =
specification needs to address the very common use case of clients with bot=
h public and private components.
I don't want to discuss in t=
he specification how client identifiers are provisioned, nor do I want to d=
iscuss the potential binding of response types to client types. But we do n=
eed to provide some guidance to clients and authorization servers what to d=
o with clients that do not fit the current type definitions.

=

It is far too late for us to define a new client type, along wit=
h all the security considerations that such type imply. Our entire security=
 consideration section and protocol design are based on have a well defined=
 client type.

Requiring separate registration for =
each component is the most straight-forward solution. Allowing the authoriz=
ation server to offer alternatives is the backdoor to enable extensibility.=


Within these constraints, I am open to other pros=
e or creative solutions. But the add-ons proposed are all ugly hacks. They =
clarify specific questions raised which I do not believe represent the core=
 confusion here which is what is the right way to handle hybrid clients.

The best way to move forward is to take a minute and=
 ask the group to share how they handle such cases or how they think they s=
hould be handled. Based on that we can come up with a clear solution.
=


EH

From:  Breno de Medeiros <breno@google.com>
Date:  Thu, 15 Mar 2012 09:56:13 -0700
To: =
 Eran Hammer-Lahav <eran@h=
ueniverse.com>
Cc:  Nat S=
akimura <sakimura@gmail.com>=
;, OAuth WG <oauth@ietf.org>Subject:  Re: [OAUTH-WG] Fw: Break=
ing change in OAuth 2.0 rev. 23



On Thu, Mar 15, 2012 at 07:45, Eran Hammer <eran@hueniverse.com> wrote:
This a=
dd-on is unnecessary. It already says the authorization server can handle i=
t any way it wants. The fact that other registration options are possible c=
learly covers the client identifier reuse case. As for the response type, t=
hat=92s not an issue but more of an optimization for an edge case raised.

It still feels like a=
 horse by committee to me. "unless the authoriza=
tion server provides other registration option=
s to specify such complex clients." seems a very round about way to sa=
y that the core spec already provides for such arrangements in the most com=
mon scenario. It is a bit of a stretch to say that the server provides &quo=
t;other registration options" by simply following strategy already lai=
d out in the spec.

=
In particular, I feel that this wording will be harmful to=
 register extended behavior, e.g., alternative response_types by leading to=
 fruitless conversations about spec compliance in the absence of real secur=
ity risks.

I do not believe the current text is the best representation of th=
e spirit in which the spec was written (in particular the effort to specify=
 two flows in detail to deal with precisely this issue) and possibly lead t=
o harmful future interpretation.
 
<=
p class=3D"MsoNormal">
 
EH
 
=

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of=
 Nat Sakimura
Sent: Thursday, March 15, 2012 2:04 AM
To=
: Breno de Medeiros; OAuth WG

Subjec=
t: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
 
 
So=
, Eran's first proposal: 
 
  A client application consisting of multiple compon=
ents, each with its
  own client type (e.g. a distributed client wi=
th both a confidential
  server-based component and a public browse=
r-based component), MUST

  register each component separately as a different client to ensure
  proper handling by the =
authorization server, unless the authorization
  server provides ot=
her registration options to specify such complex clients. 
 
=

kind of meets my concern. There seems to be another =
issue around the usefulness of return_type in such case raised by Breno, an=
d if I understand it correctly, Eran's answer was that these separate compo=
nents may have the same client_id so that return_type is a valid parameter =
to be sent at the request. 
 
So, to c=
larify these, perhaps changing the above text slightly to the following sol=
ves the problem? 
<=
u> 
  A clie=
nt application consisting of multiple components, each with its
  o=
wn client type (e.g. a distributed client with both a confidential
 =
; server-based component and a public browser-based component), MUST

  register each component separately as a different client to ensure
  proper handling by the =
authorization server, unless the authorization
  server provides ot=
her registration options to specify such complex clients.  
  Each component MAY have the same client_id, in which case the server&nb=
sp;
  judges the client type and the associated security co=
ntext  based on 

  the response_type parameter in the request. 
 
=

Would it solve your problem, Breno? <=
/u>
 
Best, 
 
=3Dna=
t
 



-- 
--Breno


--_000_CB87810D16509eranhueniversecom_--

From breno@google.com  Thu Mar 15 11:54:07 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A6F21F8501 for ; Thu, 15 Mar 2012 11:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.677
X-Spam-Level: 
X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv2A0pwOQu8v for ; Thu, 15 Mar 2012 11:54:06 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E76BD21F84EA for ; Thu, 15 Mar 2012 11:54:05 -0700 (PDT)
Received: by iazz13 with SMTP id z13so4943761iaz.31 for ; Thu, 15 Mar 2012 11:54:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=m6Gw1SI1/M/Y9ROiZVr558HNI78vUdOnUBkxyLzMp38=; b=gH+Vic/eOqMCPQXG4xB4GAAZ5xlD/ZOhTuJAR4alc6MOadVzZrPZfnzb8kSKiVRZuk Cs14WRiaRILQsM/GzEtzVE9rpQWQ0GyUMW05MlwAe3E67A40DD6EVGpebWO1dqIaYDkf UjsmPciygvoEIsQ1FkVzEo4EwaThmCaenZQdMJ3lF4W1xr2i42SddFV0GpnnU80UqFlL I2WFDVEuAwkiuO8ff+JSt0GO+yj4U6gbY/0eeVzFaAuNrLnCqZEtVJagMiBG/lZ9N+68 wOI2Ypf6QooJazOFf6ZNCC8BCBTsnbb6RKbXu+LabXh+5PDo3zNtpm7wVJQr2l/eXHtB EOzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=m6Gw1SI1/M/Y9ROiZVr558HNI78vUdOnUBkxyLzMp38=; b=WRR5DfwjABididagaWsxx7IgqMDNKeVVRjMllRMG0mWHCAZmHOLlpqGUOP96b1aXZV /KtawWKR2DTuI8K7ofnhuJ/qimht8C9QSy3kGyGGTcARk/IGK8+6HMXw6SOdItdZFzP4 HDPD31MBh5UtTTiUu5kMrTHzjDQqopsZyizFRVpSxN5Lz2NQCt+u6HWM5Dge0nQwZTns G886gZ1ggP1xgL7ZOJXTXH+5tGaMZ67BNH8hU1J+XX4BrSV94qGGGC1fi9aS0tXRIs/O mL1mGh1rATpzXrBRkK5FjtkhrB9OXw4mVOo82ytWovJA2FaMB5vAPamidpHf5FkT6BRi C0Tg==
Received: by 10.50.153.169 with SMTP id vh9mr10697672igb.41.1331837645560; Thu, 15 Mar 2012 11:54:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.153.169 with SMTP id vh9mr10697664igb.41.1331837645488; Thu, 15 Mar 2012 11:54:05 -0700 (PDT)
Received: by 10.231.41.137 with HTTP; Thu, 15 Mar 2012 11:54:05 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 15 Mar 2012 11:54:05 -0700
Message-ID: 
From: Breno de Medeiros 
To: Eran Hammer 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQl0COmamSa0T9Oivj/zw5yXoWfOiKscj4smUtcV7+XEekJHLTsnecJBFX+ONTeR9zXazLgVcPZ0bs5wPjkC5IlvqoPxg8pY+Jk+jEUbmNVYEvMykfq9vy+JdTp1systWSmPBxSK
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 18:54:07 -0000

My proposal is to remove any reference to registration (which is a red
herring and has raised all the problems we refer here) and refer to
client authentication instead.

Proposal:

"Clients may be implemented as a distributed set of components that
run in different security contexts. For instance, a single client may
include a webserver component and a script component in a browser. It
is not appropriate for the different components to utilize the same
client authentication mechanisms, since client authentication
credentials that are held securely in one context cannot be deployed
securely in another.

Servers MUST mitigate security threats from client components that
cannot hold client credentials as securely by distinguishing them from
client components that can. Example of suitable measures are:

- Requiring separate registration of components such as web server and
a mobile application.
- Restricting the time validity of tokens issued to clients that hold
no authentication credentials, such as browser script-based
components."

Please don't truncate explanations in the interest of space if the
resulting text is confusing and possibly misleading. Better to say
nothing instead.

On Thu, Mar 15, 2012 at 11:32, Eran Hammer  wrote:
> Here are the facts:
>
> The authorization server must know the client type in order to enforce ma=
ny
> of the requirements in the specification.
> The requirement to provide a client type is not decorated with a MUST or
> SHALL but that is implied.
> The specification only defines two client types: public and confidential.
> There is no client type defined for a hybrid client.
> The specification needs to address the very common use case of clients wi=
th
> both public and private components.
>
> I don't want to discuss in the specification how client identifiers are
> provisioned, nor do I want to discuss the potential binding of response
> types to client types. But we do need to provide some guidance to clients
> and authorization servers what to do with clients that do not fit the
> current type definitions.
>
> It is far too late for us to define a new client type, along with all the
> security considerations that such type imply. Our entire security
> consideration section and protocol design are based on have a well define=
d
> client type.
>
> Requiring separate registration for each component is the most
> straight-forward solution. Allowing the authorization server to offer
> alternatives is the backdoor to enable extensibility.
>
> Within these constraints, I am open to other prose or creative solutions.
> But the add-ons proposed are all ugly hacks. They clarify specific questi=
ons
> raised which I do not believe represent the core confusion here which is
> what is the right way to handle hybrid clients.
>
> The best way to move forward is to take a minute and ask the group to sha=
re
> how they handle such cases or how they think they should be handled. Base=
d
> on that we can come up with a clear solution.
>
> EH
>
> From: Breno de Medeiros 
> Date: Thu, 15 Mar 2012 09:56:13 -0700
> To: Eran Hammer-Lahav 
> Cc: Nat Sakimura , OAuth WG 
>
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>
>
>
> On Thu, Mar 15, 2012 at 07:45, Eran Hammer  wrote:
>>
>> This add-on is unnecessary. It already says the authorization server can
>> handle it any way it wants. The fact that other registration options are
>> possible clearly covers the client identifier reuse case. As for the
>> response type, that=92s not an issue but more of an optimization for an =
edge
>> case raised.
>
>
> It still feels like a horse by committee to me. "unless=A0the
> authorization=A0server provides other registration options to specify suc=
h
> complex clients." seems a very round about way to say that the core spec
> already provides for such arrangements in the most common scenario. It is=
 a
> bit of a stretch to say that the server provides "other registration
> options" by simply following strategy already laid out in the spec.
>
> In particular, I feel that this wording will be harmful to register exten=
ded
> behavior, e.g., alternative response_types by leading to fruitless
> conversations about spec compliance in the absence of real security risks=
.
>
> I do not believe the current text is the best representation of the spiri=
t
> in which the spec was written (in particular the effort to specify two fl=
ows
> in detail to deal with precisely this issue) and possibly lead to harmful
> future interpretation.
>
>>
>>
>>
>> EH
>>
>>
>>
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O=
f
>> Nat Sakimura
>> Sent: Thursday, March 15, 2012 2:04 AM
>> To: Breno de Medeiros; OAuth WG
>>
>>
>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>
>>
>>
>>
>>
>> So, Eran's first proposal:
>>
>>
>>
>> =A0 A client application consisting of multiple components, each with it=
s
>> =A0 own client type (e.g. a distributed client with both a confidential
>> =A0 server-based component and a public browser-based component), MUST
>> =A0 register each component separately as a different client to ensure
>>
>> =A0 proper handling by the authorization server, unless the authorizatio=
n
>> =A0 server provides other registration options to specify such complex
>> clients.
>>
>>
>>
>> kind of meets my concern. There seems to be another issue around the
>> usefulness of return_type in such case raised by Breno, and if I underst=
and
>> it correctly, Eran's answer was that these separate components may have =
the
>> same client_id so that return_type is a valid parameter to be sent at th=
e
>> request.
>>
>>
>>
>> So, to clarify these, perhaps changing the above text slightly to the
>> following solves the problem?
>>
>>
>>
>> =A0 A client application consisting of multiple components, each with it=
s
>> =A0 own client type (e.g. a distributed client with both a confidential
>> =A0 server-based component and a public browser-based component), MUST
>> =A0 register each component separately as a different client to ensure
>>
>> =A0 proper handling by the authorization server, unless the authorizatio=
n
>> =A0 server provides other registration options to specify such complex
>> clients.
>>
>> =A0 Each component MAY have the same client_id, in which case the server
>>
>> =A0 judges the client type and the associated security context =A0based =
on
>> =A0 the response_type parameter in the request.
>>
>>
>>
>> Would it solve your problem, Breno?
>>
>>
>>
>> Best,
>>
>>
>>
>> =3Dnat
>>
>>
>
>
>
>
> --
> --Breno



--=20
--Breno

From eran@hueniverse.com  Thu Mar 15 12:14:14 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B65821F85E7 for ; Thu, 15 Mar 2012 12:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbWv51NRWuY2 for ; Thu, 15 Mar 2012 12:14:13 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 9B50621F85C7 for ; Thu, 15 Mar 2012 12:14:12 -0700 (PDT)
Received: (qmail 14865 invoked from network); 15 Mar 2012 19:14:12 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Mar 2012 19:14:12 -0000
Received: from P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id lvEB1i0050RWb6o01vECdC; Thu, 15 Mar 2012 12:14:12 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 15 Mar 2012 12:13:22 -0700
From: Eran Hammer 
To: Breno de Medeiros 
Date: Thu, 15 Mar 2012 12:13:21 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0C37BDyghx7EAgSJiDLZjIaBuGsg==
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 19:14:14 -0000

Which text in -25 are you proposing we remove exactly? I can't judge the
text below without the full context of where and how it is proposed in the
current document.

Also, you are ignoring my detailed analysis of the current facts. We have
two client types and the issue here is what to do with other, undefined
types.

EH


On 3/15/12 11:54 AM, "Breno de Medeiros"  wrote:

>My proposal is to remove any reference to registration (which is a red
>herring and has raised all the problems we refer here) and refer to
>client authentication instead.
>
>Proposal:
>
>"Clients may be implemented as a distributed set of components that
>run in different security contexts. For instance, a single client may
>include a webserver component and a script component in a browser. It
>is not appropriate for the different components to utilize the same
>client authentication mechanisms, since client authentication
>credentials that are held securely in one context cannot be deployed
>securely in another.
>
>Servers MUST mitigate security threats from client components that
>cannot hold client credentials as securely by distinguishing them from
>client components that can. Example of suitable measures are:
>
>- Requiring separate registration of components such as web server and
>a mobile application.
>- Restricting the time validity of tokens issued to clients that hold
>no authentication credentials, such as browser script-based
>components."
>
>Please don't truncate explanations in the interest of space if the
>resulting text is confusing and possibly misleading. Better to say
>nothing instead.
>
>On Thu, Mar 15, 2012 at 11:32, Eran Hammer  wrote:
>> Here are the facts:
>>
>> The authorization server must know the client type in order to enforce
>>many
>> of the requirements in the specification.
>> The requirement to provide a client type is not decorated with a MUST or
>> SHALL but that is implied.
>> The specification only defines two client types: public and
>>confidential.
>> There is no client type defined for a hybrid client.
>> The specification needs to address the very common use case of clients
>>with
>> both public and private components.
>>
>> I don't want to discuss in the specification how client identifiers are
>> provisioned, nor do I want to discuss the potential binding of response
>> types to client types. But we do need to provide some guidance to
>>clients
>> and authorization servers what to do with clients that do not fit the
>> current type definitions.
>>
>> It is far too late for us to define a new client type, along with all
>>the
>> security considerations that such type imply. Our entire security
>> consideration section and protocol design are based on have a well
>>defined
>> client type.
>>
>> Requiring separate registration for each component is the most
>> straight-forward solution. Allowing the authorization server to offer
>> alternatives is the backdoor to enable extensibility.
>>
>> Within these constraints, I am open to other prose or creative
>>solutions.
>> But the add-ons proposed are all ugly hacks. They clarify specific
>>questions
>> raised which I do not believe represent the core confusion here which is
>> what is the right way to handle hybrid clients.
>>
>> The best way to move forward is to take a minute and ask the group to
>>share
>> how they handle such cases or how they think they should be handled.
>>Based
>> on that we can come up with a clear solution.
>>
>> EH
>>
>> From: Breno de Medeiros 
>> Date: Thu, 15 Mar 2012 09:56:13 -0700
>> To: Eran Hammer-Lahav 
>> Cc: Nat Sakimura , OAuth WG 
>>
>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>
>>
>>
>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer  wrote:
>>>
>>> This add-on is unnecessary. It already says the authorization server
>>>can
>>> handle it any way it wants. The fact that other registration options
>>>are
>>> possible clearly covers the client identifier reuse case. As for the
>>> response type, that=B9s not an issue but more of an optimization for an
>>>edge
>>> case raised.
>>
>>
>> It still feels like a horse by committee to me. "unless the
>> authorization server provides other registration options to specify such
>> complex clients." seems a very round about way to say that the core spec
>> already provides for such arrangements in the most common scenario. It
>>is a
>> bit of a stretch to say that the server provides "other registration
>> options" by simply following strategy already laid out in the spec.
>>
>> In particular, I feel that this wording will be harmful to register
>>extended
>> behavior, e.g., alternative response_types by leading to fruitless
>> conversations about spec compliance in the absence of real security
>>risks.
>>
>> I do not believe the current text is the best representation of the
>>spirit
>> in which the spec was written (in particular the effort to specify two
>>flows
>> in detail to deal with precisely this issue) and possibly lead to
>>harmful
>> future interpretation.
>>
>>>
>>>
>>>
>>> EH
>>>
>>>
>>>
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>>Of
>>> Nat Sakimura
>>> Sent: Thursday, March 15, 2012 2:04 AM
>>> To: Breno de Medeiros; OAuth WG
>>>
>>>
>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>>
>>>
>>>
>>>
>>>
>>> So, Eran's first proposal:
>>>
>>>
>>>
>>>   A client application consisting of multiple components, each with its
>>>   own client type (e.g. a distributed client with both a confidential
>>>   server-based component and a public browser-based component), MUST
>>>   register each component separately as a different client to ensure
>>>
>>>   proper handling by the authorization server, unless the authorization
>>>   server provides other registration options to specify such complex
>>> clients.
>>>
>>>
>>>
>>> kind of meets my concern. There seems to be another issue around the
>>> usefulness of return_type in such case raised by Breno, and if I
>>>understand
>>> it correctly, Eran's answer was that these separate components may
>>>have the
>>> same client_id so that return_type is a valid parameter to be sent at
>>>the
>>> request.
>>>
>>>
>>>
>>> So, to clarify these, perhaps changing the above text slightly to the
>>> following solves the problem?
>>>
>>>
>>>
>>>   A client application consisting of multiple components, each with its
>>>   own client type (e.g. a distributed client with both a confidential
>>>   server-based component and a public browser-based component), MUST
>>>   register each component separately as a different client to ensure
>>>
>>>   proper handling by the authorization server, unless the authorization
>>>   server provides other registration options to specify such complex
>>> clients.
>>>
>>>   Each component MAY have the same client_id, in which case the server
>>>
>>>   judges the client type and the associated security context  based on
>>>   the response_type parameter in the request.
>>>
>>>
>>>
>>> Would it solve your problem, Breno?
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>>
>>> =3Dnat
>>>
>>>
>>
>>
>>
>>
>> --
>> --Breno
>
>
>
>--=20
>--Breno


From breno@google.com  Thu Mar 15 12:30:06 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D7621F84E4 for ; Thu, 15 Mar 2012 12:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.92
X-Spam-Level: 
X-Spam-Status: No, score=-101.92 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_UNN=1.814, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syR3aSNwdMB9 for ; Thu, 15 Mar 2012 12:30:05 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B23E21F8503 for ; Thu, 15 Mar 2012 12:30:05 -0700 (PDT)
Received: by iazz13 with SMTP id z13so4987716iaz.31 for ; Thu, 15 Mar 2012 12:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=UZK3pVmBNkSeyey+YfvjrwKfBVg7a+RMYhmKEacVvgA=; b=JmcjUxEsvXN/MhcoVPCtNg97dHmjxfdKi6+z7Pev9B1AzMWbR7KlXXE075uC1DA2x/ VV8mWBQIMHRCIfZeWc4a0LDZm5koriak63hOzTnUppQeGZCtAPaI2cO3MYtB8ZvmBVq0 EawPQhm+whnnx3ZgWPl2g1bG94NcwMlJIvrM5h85kqhEe+r2S/zEAZBRG3FYjmdt1A+i D4bYF+eXf/RxCc+fuDjHioDnpjN08UTBFXJk2PLToh08dh41uMryEIosb8gR3cLP3Mfa ZPyA2ARqlQIz2W7e4PqAtnn0eF8F37gRE2CVhJSF3k9ytJlhW9I4LUVwWDfU/7ZhoDtg iaoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=UZK3pVmBNkSeyey+YfvjrwKfBVg7a+RMYhmKEacVvgA=; b=MgWmTdNpcx5HXr/5vEDEqoDKedje4Ed2LzPBJPILuv0bZbAh3gfLpM30RV5ulmfzwZ S5WCwrjcmeOyHiZreeLPjMEJpkcgebRuMay04tz+9IIq0tX9v3jPzcW8Z+4i4hhTYU+9 ULhH1NL/zdcwI/r7GkM1eSI2uQqqu+BwcKjUAHCDWPOxs7BPKiWvtbIf4IwrG4dyGIh2 IFlmsDGBa5SPfzf5Hx3HlW2e0asJU4pZ0dFVOSCc2ICtFU4hF2d34nBhtaZt0GUeQizF hmPRcfeZZwLOMj5U3j1x+q02DO52/9SN4VTUe8P4fZyD3jVmVJiLpg9LbeUtM2M8wXZR ml1Q==
Received: by 10.50.207.5 with SMTP id ls5mr10777482igc.51.1331839805042; Thu, 15 Mar 2012 12:30:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.207.5 with SMTP id ls5mr10777429igc.51.1331839804002; Thu, 15 Mar 2012 12:30:04 -0700 (PDT)
Received: by 10.231.41.137 with HTTP; Thu, 15 Mar 2012 12:30:03 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 15 Mar 2012 12:30:03 -0700
Message-ID: 
From: Breno de Medeiros 
To: Eran Hammer 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkZLMyqsnE8zeXHyPbMiEuZN0GZ1os/XAPvtHD1jtNaWsIQdaduOxJ2Lv4U+PiU4qkJQfYqnUldlZ7P8EPRqLfKhsyS+YESCX9SOERYZMGWTUOBs69SnYA0xIJGbfCOBJC/094y
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 19:30:06 -0000

I am proposing the entire removal of:

"A client application consisting of multiple components, each with its
own client type (e.g. a distributed client with both a confidential
server-based component and a public browser-based component), MUST
register each component separately as a different client to ensure
proper handling by the authorization server."

In particular the example of a server-side component versus
browser-based components is particularly unhelpful since it violates
the entire principle of why two response_type 'code' and 'token' were
defined, and how OAuth2 is typically implemented. That's when I claim
this normative language is redefining the protocol.


On Thu, Mar 15, 2012 at 12:13, Eran Hammer  wrote:
> Which text in -25 are you proposing we remove exactly? I can't judge the
> text below without the full context of where and how it is proposed in th=
e
> current document.
>
> Also, you are ignoring my detailed analysis of the current facts. We have
> two client types and the issue here is what to do with other, undefined
> types.
>
> EH
>
>
> On 3/15/12 11:54 AM, "Breno de Medeiros"  wrote:
>
>>My proposal is to remove any reference to registration (which is a red
>>herring and has raised all the problems we refer here) and refer to
>>client authentication instead.
>>
>>Proposal:
>>
>>"Clients may be implemented as a distributed set of components that
>>run in different security contexts. For instance, a single client may
>>include a webserver component and a script component in a browser. It
>>is not appropriate for the different components to utilize the same
>>client authentication mechanisms, since client authentication
>>credentials that are held securely in one context cannot be deployed
>>securely in another.
>>
>>Servers MUST mitigate security threats from client components that
>>cannot hold client credentials as securely by distinguishing them from
>>client components that can. Example of suitable measures are:
>>
>>- Requiring separate registration of components such as web server and
>>a mobile application.
>>- Restricting the time validity of tokens issued to clients that hold
>>no authentication credentials, such as browser script-based
>>components."
>>
>>Please don't truncate explanations in the interest of space if the
>>resulting text is confusing and possibly misleading. Better to say
>>nothing instead.
>>
>>On Thu, Mar 15, 2012 at 11:32, Eran Hammer  wrote:
>>> Here are the facts:
>>>
>>> The authorization server must know the client type in order to enforce
>>>many
>>> of the requirements in the specification.
>>> The requirement to provide a client type is not decorated with a MUST o=
r
>>> SHALL but that is implied.
>>> The specification only defines two client types: public and
>>>confidential.
>>> There is no client type defined for a hybrid client.
>>> The specification needs to address the very common use case of clients
>>>with
>>> both public and private components.
>>>
>>> I don't want to discuss in the specification how client identifiers are
>>> provisioned, nor do I want to discuss the potential binding of response
>>> types to client types. But we do need to provide some guidance to
>>>clients
>>> and authorization servers what to do with clients that do not fit the
>>> current type definitions.
>>>
>>> It is far too late for us to define a new client type, along with all
>>>the
>>> security considerations that such type imply. Our entire security
>>> consideration section and protocol design are based on have a well
>>>defined
>>> client type.
>>>
>>> Requiring separate registration for each component is the most
>>> straight-forward solution. Allowing the authorization server to offer
>>> alternatives is the backdoor to enable extensibility.
>>>
>>> Within these constraints, I am open to other prose or creative
>>>solutions.
>>> But the add-ons proposed are all ugly hacks. They clarify specific
>>>questions
>>> raised which I do not believe represent the core confusion here which i=
s
>>> what is the right way to handle hybrid clients.
>>>
>>> The best way to move forward is to take a minute and ask the group to
>>>share
>>> how they handle such cases or how they think they should be handled.
>>>Based
>>> on that we can come up with a clear solution.
>>>
>>> EH
>>>
>>> From: Breno de Medeiros 
>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
>>> To: Eran Hammer-Lahav 
>>> Cc: Nat Sakimura , OAuth WG 
>>>
>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>>
>>>
>>>
>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer  wrote:
>>>>
>>>> This add-on is unnecessary. It already says the authorization server
>>>>can
>>>> handle it any way it wants. The fact that other registration options
>>>>are
>>>> possible clearly covers the client identifier reuse case. As for the
>>>> response type, that=B9s not an issue but more of an optimization for a=
n
>>>>edge
>>>> case raised.
>>>
>>>
>>> It still feels like a horse by committee to me. "unless the
>>> authorization server provides other registration options to specify suc=
h
>>> complex clients." seems a very round about way to say that the core spe=
c
>>> already provides for such arrangements in the most common scenario. It
>>>is a
>>> bit of a stretch to say that the server provides "other registration
>>> options" by simply following strategy already laid out in the spec.
>>>
>>> In particular, I feel that this wording will be harmful to register
>>>extended
>>> behavior, e.g., alternative response_types by leading to fruitless
>>> conversations about spec compliance in the absence of real security
>>>risks.
>>>
>>> I do not believe the current text is the best representation of the
>>>spirit
>>> in which the spec was written (in particular the effort to specify two
>>>flows
>>> in detail to deal with precisely this issue) and possibly lead to
>>>harmful
>>> future interpretation.
>>>
>>>>
>>>>
>>>>
>>>> EH
>>>>
>>>>
>>>>
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>>>Of
>>>> Nat Sakimura
>>>> Sent: Thursday, March 15, 2012 2:04 AM
>>>> To: Breno de Medeiros; OAuth WG
>>>>
>>>>
>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So, Eran's first proposal:
>>>>
>>>>
>>>>
>>>> =A0 A client application consisting of multiple components, each with =
its
>>>> =A0 own client type (e.g. a distributed client with both a confidentia=
l
>>>> =A0 server-based component and a public browser-based component), MUST
>>>> =A0 register each component separately as a different client to ensure
>>>>
>>>> =A0 proper handling by the authorization server, unless the authorizat=
ion
>>>> =A0 server provides other registration options to specify such complex
>>>> clients.
>>>>
>>>>
>>>>
>>>> kind of meets my concern. There seems to be another issue around the
>>>> usefulness of return_type in such case raised by Breno, and if I
>>>>understand
>>>> it correctly, Eran's answer was that these separate components may
>>>>have the
>>>> same client_id so that return_type is a valid parameter to be sent at
>>>>the
>>>> request.
>>>>
>>>>
>>>>
>>>> So, to clarify these, perhaps changing the above text slightly to the
>>>> following solves the problem?
>>>>
>>>>
>>>>
>>>> =A0 A client application consisting of multiple components, each with =
its
>>>> =A0 own client type (e.g. a distributed client with both a confidentia=
l
>>>> =A0 server-based component and a public browser-based component), MUST
>>>> =A0 register each component separately as a different client to ensure
>>>>
>>>> =A0 proper handling by the authorization server, unless the authorizat=
ion
>>>> =A0 server provides other registration options to specify such complex
>>>> clients.
>>>>
>>>> =A0 Each component MAY have the same client_id, in which case the serv=
er
>>>>
>>>> =A0 judges the client type and the associated security context =A0base=
d on
>>>> =A0 the response_type parameter in the request.
>>>>
>>>>
>>>>
>>>> Would it solve your problem, Breno?
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>>
>>>>
>>>> =3Dnat
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> --Breno
>>
>>
>>
>>--
>>--Breno
>



--=20
--Breno

From eran@hueniverse.com  Thu Mar 15 13:59:55 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F45721F86B4 for ; Thu, 15 Mar 2012 13:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.663
X-Spam-Level: 
X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xXuYfMFqO9T for ; Thu, 15 Mar 2012 13:59:54 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 298BF21F865F for ; Thu, 15 Mar 2012 13:59:54 -0700 (PDT)
Received: (qmail 29865 invoked from network); 15 Mar 2012 20:59:41 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Mar 2012 20:59:41 -0000
Received: from P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id lwzQ1i0050RWb6o01wzhN0; Thu, 15 Mar 2012 13:59:41 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 15 Mar 2012 13:13:24 -0700
From: Eran Hammer 
To: Breno de Medeiros 
Date: Thu, 15 Mar 2012 13:13:21 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0C6BM8zEDXz4hPQYSBfWAJEHLb3Q==
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 20:59:55 -0000

T2suIFRoYXQncyBtdWNoIGJldHRlciB0aGFuIG15IGd1ZXNzIHRoYXQgeW91IHdhbnRlZCB0byBk
cm9wIGFsbCB0aGUNCnJlZ2lzdHJhdGlvbiB0ZXh0IGZyb20gdGhlIHNwZWNpZmljYXRpb26hpg0K
DQpXaGF0IEknbSBsb29raW5nIGZvciBpcyBhIHNpbXBsZSB0ZXh0IHRoYXQgYW5zd2VycyB0aGUg
cXVlc3Rpb246DQoNCiJXaGF0IHRvIGRvIGlmIG15IGNsaWVudCBpc24ndCBzaW1wbHkgcHVibGlj
IG9yIGNvbmZpZGVudGlhbD8iDQoNCklmIHdlIGp1c3QgZHJvcCB0aGUgY3VycmVudCB0ZXh0LCB0
aGUgYW5zd2VyIGlzIGltcGxpY2l0bHkgInlvdSBjYW4ndCBoYXZlDQpzdWNoIGEgY2xpZW50IiBi
ZWNhdXNlIHRoZXJlIGlzIG5vIHdheSB0byByZWdpc3RlciBhIGNsaWVudCBvZiBhbnkgb3RoZXIN
CnR5cGUuDQoNClNvIGxldCdzIHRyeSB0aGlzIGFnYWluLCBhbmQgZm9jdXMgZXhjbHVzaXZlbHkg
b24gYW5zd2VyaW5nIHRoaXMgcXVlc3Rpb24uDQpNeSB0ZXh0IHRha2VzIGEgcG9zaXRpb24gd2hp
Y2ggaXMsICJ5b3UgY2FuJ3QgLSB1bmxlc3MiLiBZb3VyIHN1Z2dlc3Rpb24NCmlzIG1vcmUgb2Yg
YSB2YWd1ZSBkaXNjdXNzaW9uIG9mIHRoZSB0b3BpYy4gSSdkIGxpa2UgdG8gc2VlIGNsZWFyLA0K
bm9ybWF0aXZlIGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uLg0KDQpFSA0KDQoNCk9uIDMvMTUvMTIg
MTI6MzAgUE0sICJCcmVubyBkZSBNZWRlaXJvcyIgPGJyZW5vQGdvb2dsZS5jb20+IHdyb3RlOg0K
DQo+SSBhbSBwcm9wb3NpbmcgdGhlIGVudGlyZSByZW1vdmFsIG9mOg0KPg0KPiJBIGNsaWVudCBh
cHBsaWNhdGlvbiBjb25zaXN0aW5nIG9mIG11bHRpcGxlIGNvbXBvbmVudHMsIGVhY2ggd2l0aCBp
dHMNCj5vd24gY2xpZW50IHR5cGUgKGUuZy4gYSBkaXN0cmlidXRlZCBjbGllbnQgd2l0aCBib3Ro
IGEgY29uZmlkZW50aWFsDQo+c2VydmVyLWJhc2VkIGNvbXBvbmVudCBhbmQgYSBwdWJsaWMgYnJv
d3Nlci1iYXNlZCBjb21wb25lbnQpLCBNVVNUDQo+cmVnaXN0ZXIgZWFjaCBjb21wb25lbnQgc2Vw
YXJhdGVseSBhcyBhIGRpZmZlcmVudCBjbGllbnQgdG8gZW5zdXJlDQo+cHJvcGVyIGhhbmRsaW5n
IGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4iDQo+DQo+SW4gcGFydGljdWxhciB0aGUgZXhh
bXBsZSBvZiBhIHNlcnZlci1zaWRlIGNvbXBvbmVudCB2ZXJzdXMNCj5icm93c2VyLWJhc2VkIGNv
bXBvbmVudHMgaXMgcGFydGljdWxhcmx5IHVuaGVscGZ1bCBzaW5jZSBpdCB2aW9sYXRlcw0KPnRo
ZSBlbnRpcmUgcHJpbmNpcGxlIG9mIHdoeSB0d28gcmVzcG9uc2VfdHlwZSAnY29kZScgYW5kICd0
b2tlbicgd2VyZQ0KPmRlZmluZWQsIGFuZCBob3cgT0F1dGgyIGlzIHR5cGljYWxseSBpbXBsZW1l
bnRlZC4gVGhhdCdzIHdoZW4gSSBjbGFpbQ0KPnRoaXMgbm9ybWF0aXZlIGxhbmd1YWdlIGlzIHJl
ZGVmaW5pbmcgdGhlIHByb3RvY29sLg0KPg0KPg0KPk9uIFRodSwgTWFyIDE1LCAyMDEyIGF0IDEy
OjEzLCBFcmFuIEhhbW1lciA8ZXJhbkBodWVuaXZlcnNlLmNvbT4gd3JvdGU6DQo+PiBXaGljaCB0
ZXh0IGluIC0yNSBhcmUgeW91IHByb3Bvc2luZyB3ZSByZW1vdmUgZXhhY3RseT8gSSBjYW4ndCBq
dWRnZSB0aGUNCj4+IHRleHQgYmVsb3cgd2l0aG91dCB0aGUgZnVsbCBjb250ZXh0IG9mIHdoZXJl
IGFuZCBob3cgaXQgaXMgcHJvcG9zZWQgaW4NCj4+dGhlDQo+PiBjdXJyZW50IGRvY3VtZW50Lg0K
Pj4NCj4+IEFsc28sIHlvdSBhcmUgaWdub3JpbmcgbXkgZGV0YWlsZWQgYW5hbHlzaXMgb2YgdGhl
IGN1cnJlbnQgZmFjdHMuIFdlDQo+PmhhdmUNCj4+IHR3byBjbGllbnQgdHlwZXMgYW5kIHRoZSBp
c3N1ZSBoZXJlIGlzIHdoYXQgdG8gZG8gd2l0aCBvdGhlciwgdW5kZWZpbmVkDQo+PiB0eXBlcy4N
Cj4+DQo+PiBFSA0KPj4NCj4+DQo+PiBPbiAzLzE1LzEyIDExOjU0IEFNLCAiQnJlbm8gZGUgTWVk
ZWlyb3MiIDxicmVub0Bnb29nbGUuY29tPiB3cm90ZToNCj4+DQo+Pj5NeSBwcm9wb3NhbCBpcyB0
byByZW1vdmUgYW55IHJlZmVyZW5jZSB0byByZWdpc3RyYXRpb24gKHdoaWNoIGlzIGEgcmVkDQo+
Pj5oZXJyaW5nIGFuZCBoYXMgcmFpc2VkIGFsbCB0aGUgcHJvYmxlbXMgd2UgcmVmZXIgaGVyZSkg
YW5kIHJlZmVyIHRvDQo+Pj5jbGllbnQgYXV0aGVudGljYXRpb24gaW5zdGVhZC4NCj4+Pg0KPj4+
UHJvcG9zYWw6DQo+Pj4NCj4+PiJDbGllbnRzIG1heSBiZSBpbXBsZW1lbnRlZCBhcyBhIGRpc3Ry
aWJ1dGVkIHNldCBvZiBjb21wb25lbnRzIHRoYXQNCj4+PnJ1biBpbiBkaWZmZXJlbnQgc2VjdXJp
dHkgY29udGV4dHMuIEZvciBpbnN0YW5jZSwgYSBzaW5nbGUgY2xpZW50IG1heQ0KPj4+aW5jbHVk
ZSBhIHdlYnNlcnZlciBjb21wb25lbnQgYW5kIGEgc2NyaXB0IGNvbXBvbmVudCBpbiBhIGJyb3dz
ZXIuIEl0DQo+Pj5pcyBub3QgYXBwcm9wcmlhdGUgZm9yIHRoZSBkaWZmZXJlbnQgY29tcG9uZW50
cyB0byB1dGlsaXplIHRoZSBzYW1lDQo+Pj5jbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNt
cywgc2luY2UgY2xpZW50IGF1dGhlbnRpY2F0aW9uDQo+Pj5jcmVkZW50aWFscyB0aGF0IGFyZSBo
ZWxkIHNlY3VyZWx5IGluIG9uZSBjb250ZXh0IGNhbm5vdCBiZSBkZXBsb3llZA0KPj4+c2VjdXJl
bHkgaW4gYW5vdGhlci4NCj4+Pg0KPj4+U2VydmVycyBNVVNUIG1pdGlnYXRlIHNlY3VyaXR5IHRo
cmVhdHMgZnJvbSBjbGllbnQgY29tcG9uZW50cyB0aGF0DQo+Pj5jYW5ub3QgaG9sZCBjbGllbnQg
Y3JlZGVudGlhbHMgYXMgc2VjdXJlbHkgYnkgZGlzdGluZ3Vpc2hpbmcgdGhlbSBmcm9tDQo+Pj5j
bGllbnQgY29tcG9uZW50cyB0aGF0IGNhbi4gRXhhbXBsZSBvZiBzdWl0YWJsZSBtZWFzdXJlcyBh
cmU6DQo+Pj4NCj4+Pi0gUmVxdWlyaW5nIHNlcGFyYXRlIHJlZ2lzdHJhdGlvbiBvZiBjb21wb25l
bnRzIHN1Y2ggYXMgd2ViIHNlcnZlciBhbmQNCj4+PmEgbW9iaWxlIGFwcGxpY2F0aW9uLg0KPj4+
LSBSZXN0cmljdGluZyB0aGUgdGltZSB2YWxpZGl0eSBvZiB0b2tlbnMgaXNzdWVkIHRvIGNsaWVu
dHMgdGhhdCBob2xkDQo+Pj5ubyBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscywgc3VjaCBhcyBi
cm93c2VyIHNjcmlwdC1iYXNlZA0KPj4+Y29tcG9uZW50cy4iDQo+Pj4NCj4+PlBsZWFzZSBkb24n
dCB0cnVuY2F0ZSBleHBsYW5hdGlvbnMgaW4gdGhlIGludGVyZXN0IG9mIHNwYWNlIGlmIHRoZQ0K
Pj4+cmVzdWx0aW5nIHRleHQgaXMgY29uZnVzaW5nIGFuZCBwb3NzaWJseSBtaXNsZWFkaW5nLiBC
ZXR0ZXIgdG8gc2F5DQo+Pj5ub3RoaW5nIGluc3RlYWQuDQo+Pj4NCj4+Pk9uIFRodSwgTWFyIDE1
LCAyMDEyIGF0IDExOjMyLCBFcmFuIEhhbW1lciA8ZXJhbkBodWVuaXZlcnNlLmNvbT4gd3JvdGU6
DQo+Pj4+IEhlcmUgYXJlIHRoZSBmYWN0czoNCj4+Pj4NCj4+Pj4gVGhlIGF1dGhvcml6YXRpb24g
c2VydmVyIG11c3Qga25vdyB0aGUgY2xpZW50IHR5cGUgaW4gb3JkZXIgdG8gZW5mb3JjZQ0KPj4+
Pm1hbnkNCj4+Pj4gb2YgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGUgc3BlY2lmaWNhdGlvbi4NCj4+
Pj4gVGhlIHJlcXVpcmVtZW50IHRvIHByb3ZpZGUgYSBjbGllbnQgdHlwZSBpcyBub3QgZGVjb3Jh
dGVkIHdpdGggYSBNVVNUDQo+Pj4+b3INCj4+Pj4gU0hBTEwgYnV0IHRoYXQgaXMgaW1wbGllZC4N
Cj4+Pj4gVGhlIHNwZWNpZmljYXRpb24gb25seSBkZWZpbmVzIHR3byBjbGllbnQgdHlwZXM6IHB1
YmxpYyBhbmQNCj4+Pj5jb25maWRlbnRpYWwuDQo+Pj4+IFRoZXJlIGlzIG5vIGNsaWVudCB0eXBl
IGRlZmluZWQgZm9yIGEgaHlicmlkIGNsaWVudC4NCj4+Pj4gVGhlIHNwZWNpZmljYXRpb24gbmVl
ZHMgdG8gYWRkcmVzcyB0aGUgdmVyeSBjb21tb24gdXNlIGNhc2Ugb2YgY2xpZW50cw0KPj4+Pndp
dGgNCj4+Pj4gYm90aCBwdWJsaWMgYW5kIHByaXZhdGUgY29tcG9uZW50cy4NCj4+Pj4NCj4+Pj4g
SSBkb24ndCB3YW50IHRvIGRpc2N1c3MgaW4gdGhlIHNwZWNpZmljYXRpb24gaG93IGNsaWVudCBp
ZGVudGlmaWVycw0KPj4+PmFyZQ0KPj4+PiBwcm92aXNpb25lZCwgbm9yIGRvIEkgd2FudCB0byBk
aXNjdXNzIHRoZSBwb3RlbnRpYWwgYmluZGluZyBvZg0KPj4+PnJlc3BvbnNlDQo+Pj4+IHR5cGVz
IHRvIGNsaWVudCB0eXBlcy4gQnV0IHdlIGRvIG5lZWQgdG8gcHJvdmlkZSBzb21lIGd1aWRhbmNl
IHRvDQo+Pj4+Y2xpZW50cw0KPj4+PiBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHdoYXQgdG8g
ZG8gd2l0aCBjbGllbnRzIHRoYXQgZG8gbm90IGZpdCB0aGUNCj4+Pj4gY3VycmVudCB0eXBlIGRl
ZmluaXRpb25zLg0KPj4+Pg0KPj4+PiBJdCBpcyBmYXIgdG9vIGxhdGUgZm9yIHVzIHRvIGRlZmlu
ZSBhIG5ldyBjbGllbnQgdHlwZSwgYWxvbmcgd2l0aCBhbGwNCj4+Pj50aGUNCj4+Pj4gc2VjdXJp
dHkgY29uc2lkZXJhdGlvbnMgdGhhdCBzdWNoIHR5cGUgaW1wbHkuIE91ciBlbnRpcmUgc2VjdXJp
dHkNCj4+Pj4gY29uc2lkZXJhdGlvbiBzZWN0aW9uIGFuZCBwcm90b2NvbCBkZXNpZ24gYXJlIGJh
c2VkIG9uIGhhdmUgYSB3ZWxsDQo+Pj4+ZGVmaW5lZA0KPj4+PiBjbGllbnQgdHlwZS4NCj4+Pj4N
Cj4+Pj4gUmVxdWlyaW5nIHNlcGFyYXRlIHJlZ2lzdHJhdGlvbiBmb3IgZWFjaCBjb21wb25lbnQg
aXMgdGhlIG1vc3QNCj4+Pj4gc3RyYWlnaHQtZm9yd2FyZCBzb2x1dGlvbi4gQWxsb3dpbmcgdGhl
IGF1dGhvcml6YXRpb24gc2VydmVyIHRvIG9mZmVyDQo+Pj4+IGFsdGVybmF0aXZlcyBpcyB0aGUg
YmFja2Rvb3IgdG8gZW5hYmxlIGV4dGVuc2liaWxpdHkuDQo+Pj4+DQo+Pj4+IFdpdGhpbiB0aGVz
ZSBjb25zdHJhaW50cywgSSBhbSBvcGVuIHRvIG90aGVyIHByb3NlIG9yIGNyZWF0aXZlDQo+Pj4+
c29sdXRpb25zLg0KPj4+PiBCdXQgdGhlIGFkZC1vbnMgcHJvcG9zZWQgYXJlIGFsbCB1Z2x5IGhh
Y2tzLiBUaGV5IGNsYXJpZnkgc3BlY2lmaWMNCj4+Pj5xdWVzdGlvbnMNCj4+Pj4gcmFpc2VkIHdo
aWNoIEkgZG8gbm90IGJlbGlldmUgcmVwcmVzZW50IHRoZSBjb3JlIGNvbmZ1c2lvbiBoZXJlIHdo
aWNoDQo+Pj4+aXMNCj4+Pj4gd2hhdCBpcyB0aGUgcmlnaHQgd2F5IHRvIGhhbmRsZSBoeWJyaWQg
Y2xpZW50cy4NCj4+Pj4NCj4+Pj4gVGhlIGJlc3Qgd2F5IHRvIG1vdmUgZm9yd2FyZCBpcyB0byB0
YWtlIGEgbWludXRlIGFuZCBhc2sgdGhlIGdyb3VwIHRvDQo+Pj4+c2hhcmUNCj4+Pj4gaG93IHRo
ZXkgaGFuZGxlIHN1Y2ggY2FzZXMgb3IgaG93IHRoZXkgdGhpbmsgdGhleSBzaG91bGQgYmUgaGFu
ZGxlZC4NCj4+Pj5CYXNlZA0KPj4+PiBvbiB0aGF0IHdlIGNhbiBjb21lIHVwIHdpdGggYSBjbGVh
ciBzb2x1dGlvbi4NCj4+Pj4NCj4+Pj4gRUgNCj4+Pj4NCj4+Pj4gRnJvbTogQnJlbm8gZGUgTWVk
ZWlyb3MgPGJyZW5vQGdvb2dsZS5jb20+DQo+Pj4+IERhdGU6IFRodSwgMTUgTWFyIDIwMTIgMDk6
NTY6MTMgLTA3MDANCj4+Pj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2IDxlcmFuQGh1ZW5pdmVyc2Uu
Y29tPg0KPj4+PiBDYzogTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+LCBPQXV0aCBX
RyA8b2F1dGhAaWV0Zi5vcmc+DQo+Pj4+DQo+Pj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEZ3
OiBCcmVha2luZyBjaGFuZ2UgaW4gT0F1dGggMi4wIHJldi4gMjMNCj4+Pj4NCj4+Pj4NCj4+Pj4N
Cj4+Pj4gT24gVGh1LCBNYXIgMTUsIDIwMTIgYXQgMDc6NDUsIEVyYW4gSGFtbWVyIDxlcmFuQGh1
ZW5pdmVyc2UuY29tPg0KPj4+Pndyb3RlOg0KPj4+Pj4NCj4+Pj4+IFRoaXMgYWRkLW9uIGlzIHVu
bmVjZXNzYXJ5LiBJdCBhbHJlYWR5IHNheXMgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQo+Pj4+
PmNhbg0KPj4+Pj4gaGFuZGxlIGl0IGFueSB3YXkgaXQgd2FudHMuIFRoZSBmYWN0IHRoYXQgb3Ro
ZXIgcmVnaXN0cmF0aW9uIG9wdGlvbnMNCj4+Pj4+YXJlDQo+Pj4+PiBwb3NzaWJsZSBjbGVhcmx5
IGNvdmVycyB0aGUgY2xpZW50IGlkZW50aWZpZXIgcmV1c2UgY2FzZS4gQXMgZm9yIHRoZQ0KPj4+
Pj4gcmVzcG9uc2UgdHlwZSwgdGhhdKn2cyBub3QgYW4gaXNzdWUgYnV0IG1vcmUgb2YgYW4gb3B0
aW1pemF0aW9uIGZvciBhbg0KPj4+Pj5lZGdlDQo+Pj4+PiBjYXNlIHJhaXNlZC4NCj4+Pj4NCj4+
Pj4NCj4+Pj4gSXQgc3RpbGwgZmVlbHMgbGlrZSBhIGhvcnNlIGJ5IGNvbW1pdHRlZSB0byBtZS4g
InVubGVzcyB0aGUNCj4+Pj4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcHJvdmlkZXMgb3RoZXIgcmVn
aXN0cmF0aW9uIG9wdGlvbnMgdG8gc3BlY2lmeQ0KPj4+PnN1Y2gNCj4+Pj4gY29tcGxleCBjbGll
bnRzLiIgc2VlbXMgYSB2ZXJ5IHJvdW5kIGFib3V0IHdheSB0byBzYXkgdGhhdCB0aGUgY29yZQ0K
Pj4+PnNwZWMNCj4+Pj4gYWxyZWFkeSBwcm92aWRlcyBmb3Igc3VjaCBhcnJhbmdlbWVudHMgaW4g
dGhlIG1vc3QgY29tbW9uIHNjZW5hcmlvLiBJdA0KPj4+PmlzIGENCj4+Pj4gYml0IG9mIGEgc3Ry
ZXRjaCB0byBzYXkgdGhhdCB0aGUgc2VydmVyIHByb3ZpZGVzICJvdGhlciByZWdpc3RyYXRpb24N
Cj4+Pj4gb3B0aW9ucyIgYnkgc2ltcGx5IGZvbGxvd2luZyBzdHJhdGVneSBhbHJlYWR5IGxhaWQg
b3V0IGluIHRoZSBzcGVjLg0KPj4+Pg0KPj4+PiBJbiBwYXJ0aWN1bGFyLCBJIGZlZWwgdGhhdCB0
aGlzIHdvcmRpbmcgd2lsbCBiZSBoYXJtZnVsIHRvIHJlZ2lzdGVyDQo+Pj4+ZXh0ZW5kZWQNCj4+
Pj4gYmVoYXZpb3IsIGUuZy4sIGFsdGVybmF0aXZlIHJlc3BvbnNlX3R5cGVzIGJ5IGxlYWRpbmcg
dG8gZnJ1aXRsZXNzDQo+Pj4+IGNvbnZlcnNhdGlvbnMgYWJvdXQgc3BlYyBjb21wbGlhbmNlIGlu
IHRoZSBhYnNlbmNlIG9mIHJlYWwgc2VjdXJpdHkNCj4+Pj5yaXNrcy4NCj4+Pj4NCj4+Pj4gSSBk
byBub3QgYmVsaWV2ZSB0aGUgY3VycmVudCB0ZXh0IGlzIHRoZSBiZXN0IHJlcHJlc2VudGF0aW9u
IG9mIHRoZQ0KPj4+PnNwaXJpdA0KPj4+PiBpbiB3aGljaCB0aGUgc3BlYyB3YXMgd3JpdHRlbiAo
aW4gcGFydGljdWxhciB0aGUgZWZmb3J0IHRvIHNwZWNpZnkgdHdvDQo+Pj4+Zmxvd3MNCj4+Pj4g
aW4gZGV0YWlsIHRvIGRlYWwgd2l0aCBwcmVjaXNlbHkgdGhpcyBpc3N1ZSkgYW5kIHBvc3NpYmx5
IGxlYWQgdG8NCj4+Pj5oYXJtZnVsDQo+Pj4+IGZ1dHVyZSBpbnRlcnByZXRhdGlvbi4NCj4+Pj4N
Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEVIDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+
PiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZ10gT24NCj4+Pj4+QmVoYWxmDQo+Pj4+Pk9mDQo+Pj4+PiBOYXQgU2FraW11cmENCj4+Pj4+
IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNSwgMjAxMiAyOjA0IEFNDQo+Pj4+PiBUbzogQnJlbm8g
ZGUgTWVkZWlyb3M7IE9BdXRoIFdHDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFN1YmplY3Q6IFJlOiBb
T0FVVEgtV0ddIEZ3OiBCcmVha2luZyBjaGFuZ2UgaW4gT0F1dGggMi4wIHJldi4gMjMNCj4+Pj4+
DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gU28sIEVyYW4ncyBmaXJzdCBwcm9w
b3NhbDoNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ICAgQSBjbGllbnQgYXBwbGljYXRpb24g
Y29uc2lzdGluZyBvZiBtdWx0aXBsZSBjb21wb25lbnRzLCBlYWNoIHdpdGgNCj4+Pj4+aXRzDQo+
Pj4+PiAgIG93biBjbGllbnQgdHlwZSAoZS5nLiBhIGRpc3RyaWJ1dGVkIGNsaWVudCB3aXRoIGJv
dGggYSBjb25maWRlbnRpYWwNCj4+Pj4+ICAgc2VydmVyLWJhc2VkIGNvbXBvbmVudCBhbmQgYSBw
dWJsaWMgYnJvd3Nlci1iYXNlZCBjb21wb25lbnQpLCBNVVNUDQo+Pj4+PiAgIHJlZ2lzdGVyIGVh
Y2ggY29tcG9uZW50IHNlcGFyYXRlbHkgYXMgYSBkaWZmZXJlbnQgY2xpZW50IHRvIGVuc3VyZQ0K
Pj4+Pj4NCj4+Pj4+ICAgcHJvcGVyIGhhbmRsaW5nIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZl
ciwgdW5sZXNzIHRoZQ0KPj4+Pj5hdXRob3JpemF0aW9uDQo+Pj4+PiAgIHNlcnZlciBwcm92aWRl
cyBvdGhlciByZWdpc3RyYXRpb24gb3B0aW9ucyB0byBzcGVjaWZ5IHN1Y2ggY29tcGxleA0KPj4+
Pj4gY2xpZW50cy4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IGtpbmQgb2YgbWVldHMgbXkg
Y29uY2Vybi4gVGhlcmUgc2VlbXMgdG8gYmUgYW5vdGhlciBpc3N1ZSBhcm91bmQgdGhlDQo+Pj4+
PiB1c2VmdWxuZXNzIG9mIHJldHVybl90eXBlIGluIHN1Y2ggY2FzZSByYWlzZWQgYnkgQnJlbm8s
IGFuZCBpZiBJDQo+Pj4+PnVuZGVyc3RhbmQNCj4+Pj4+IGl0IGNvcnJlY3RseSwgRXJhbidzIGFu
c3dlciB3YXMgdGhhdCB0aGVzZSBzZXBhcmF0ZSBjb21wb25lbnRzIG1heQ0KPj4+Pj5oYXZlIHRo
ZQ0KPj4+Pj4gc2FtZSBjbGllbnRfaWQgc28gdGhhdCByZXR1cm5fdHlwZSBpcyBhIHZhbGlkIHBh
cmFtZXRlciB0byBiZSBzZW50IGF0DQo+Pj4+PnRoZQ0KPj4+Pj4gcmVxdWVzdC4NCj4+Pj4+DQo+
Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFNvLCB0byBjbGFyaWZ5IHRoZXNlLCBwZXJoYXBzIGNoYW5naW5n
IHRoZSBhYm92ZSB0ZXh0IHNsaWdodGx5IHRvIHRoZQ0KPj4+Pj4gZm9sbG93aW5nIHNvbHZlcyB0
aGUgcHJvYmxlbT8NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ICAgQSBjbGllbnQgYXBwbGlj
YXRpb24gY29uc2lzdGluZyBvZiBtdWx0aXBsZSBjb21wb25lbnRzLCBlYWNoIHdpdGgNCj4+Pj4+
aXRzDQo+Pj4+PiAgIG93biBjbGllbnQgdHlwZSAoZS5nLiBhIGRpc3RyaWJ1dGVkIGNsaWVudCB3
aXRoIGJvdGggYSBjb25maWRlbnRpYWwNCj4+Pj4+ICAgc2VydmVyLWJhc2VkIGNvbXBvbmVudCBh
bmQgYSBwdWJsaWMgYnJvd3Nlci1iYXNlZCBjb21wb25lbnQpLCBNVVNUDQo+Pj4+PiAgIHJlZ2lz
dGVyIGVhY2ggY29tcG9uZW50IHNlcGFyYXRlbHkgYXMgYSBkaWZmZXJlbnQgY2xpZW50IHRvIGVu
c3VyZQ0KPj4+Pj4NCj4+Pj4+ICAgcHJvcGVyIGhhbmRsaW5nIGJ5IHRoZSBhdXRob3JpemF0aW9u
IHNlcnZlciwgdW5sZXNzIHRoZQ0KPj4+Pj5hdXRob3JpemF0aW9uDQo+Pj4+PiAgIHNlcnZlciBw
cm92aWRlcyBvdGhlciByZWdpc3RyYXRpb24gb3B0aW9ucyB0byBzcGVjaWZ5IHN1Y2ggY29tcGxl
eA0KPj4+Pj4gY2xpZW50cy4NCj4+Pj4+DQo+Pj4+PiAgIEVhY2ggY29tcG9uZW50IE1BWSBoYXZl
IHRoZSBzYW1lIGNsaWVudF9pZCwgaW4gd2hpY2ggY2FzZSB0aGUNCj4+Pj4+c2VydmVyDQo+Pj4+
Pg0KPj4+Pj4gICBqdWRnZXMgdGhlIGNsaWVudCB0eXBlIGFuZCB0aGUgYXNzb2NpYXRlZCBzZWN1
cml0eSBjb250ZXh0ICBiYXNlZA0KPj4+Pj5vbg0KPj4+Pj4gICB0aGUgcmVzcG9uc2VfdHlwZSBw
YXJhbWV0ZXIgaW4gdGhlIHJlcXVlc3QuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBXb3Vs
ZCBpdCBzb2x2ZSB5b3VyIHByb2JsZW0sIEJyZW5vPw0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+
Pj4gQmVzdCwNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ID1uYXQNCj4+Pj4+DQo+Pj4+Pg0K
Pj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiAtLQ0KPj4+PiAtLUJyZW5vDQo+Pj4NCj4+Pg0K
Pj4+DQo+Pj4tLQ0KPj4+LS1CcmVubw0KPj4NCj4NCj4NCj4NCj4tLSANCj4tLUJyZW5vDQoNCg==

From breno@google.com  Thu Mar 15 14:12:10 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A65C21E8029 for ; Thu, 15 Mar 2012 14:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.575
X-Spam-Level: 
X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiqlO-N4Ahyz for ; Thu, 15 Mar 2012 14:12:09 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1201021E8025 for ; Thu, 15 Mar 2012 14:12:08 -0700 (PDT)
Received: by iazz13 with SMTP id z13so5114045iaz.31 for ; Thu, 15 Mar 2012 14:12:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=Q7noc2T8WuWT9+g5rKa7CuoX2ZtaOhViQY6R+13lkeI=; b=WlVt1fF67oqJhcwOi+zIbjsOld4079UVxspZafPVvT4FLrjp5A3JeWCmbtCGEkqTFO vQggbVBKtXgIw9iCcd02WTP2iGrSP4QQ4UNpFuDwrv5kSri05KR92AH4Fowb0Vo62UDS XaDFTjE+jQM6XdggIQsQp6odR951gkv0ll53KMM+H6VIKr5KopzPVy9HzFe2eXR3+pjT sUSEqiegKdUzsBPoRhhQCpVGVy6mZ9Lkl9soOrmjB0rLvuWirlpUgQ+CHFOm7b2QThY6 ghRHj+5qJbm611IjAam1kqHsBksa3PuSacVdLbVVVZ28uZRkw1VHyz597KY4t/LH/ssn XZCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=Q7noc2T8WuWT9+g5rKa7CuoX2ZtaOhViQY6R+13lkeI=; b=nNfLxjM4A7YkVgXkN/Tc6lrPtGUIG9Mtr+9u5JnKZVL+PmUb+HPesfk7uTICEPpoeI xMI8AVW+4wx7UrKsquFQElpk7SwUQcMJD12bsQEJSizNm699ekabXDAy5/R8RdLKyttg UgfnA6ywJkU0AhSYtuvNlZu0JKMnyKYVgoZiokYJ19ziF9fFP/qJXPOTE9ZDc9yxUimg hxW4gMaRgYQx6NiV7ca8VdNCl8Mw2nbf1fycKXBqbX1zhw8lpNQWTpleaF74+yA5XJYf W1JYLLTDY8tBI5t1UOo+oTL25B6CY4VWuBtdWPZrJ1SRgjsDlTbigzZ0Y2S4XIh8dkiX h1nA==
Received: by 10.50.149.131 with SMTP id ua3mr18119715igb.41.1331845928596; Thu, 15 Mar 2012 14:12:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.149.131 with SMTP id ua3mr18119705igb.41.1331845928516; Thu, 15 Mar 2012 14:12:08 -0700 (PDT)
Received: by 10.231.41.137 with HTTP; Thu, 15 Mar 2012 14:12:08 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 15 Mar 2012 14:12:08 -0700
Message-ID: 
From: Breno de Medeiros 
To: Eran Hammer 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmP4SviMfsfjRQ6O/vPj8Z3muoMGWTO3yobXWFywC3sePzLAFxm3ZdBz0y7LhlDJUdNxWAIn49MF2R+xDQZcFOqaKswZTMi6LrH0FAZ3ycSC/CSVGdtWRWGmqOfTvo8kfR4tC4h
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 21:12:10 -0000

On Thu, Mar 15, 2012 at 13:13, Eran Hammer  wrote:
> Ok. That's much better than my guess that you wanted to drop all the
> registration text from the specification=85
>
> What I'm looking for is a simple text that answers the question:
>
> "What to do if my client isn't simply public or confidential?"
>
> If we just drop the current text, the answer is implicitly "you can't hav=
e
> such a client" because there is no way to register a client of any other
> type.
>
> So let's try this again, and focus exclusively on answering this question=
.
> My text takes a position which is, "you can't - unless". Your suggestion
> is more of a vague discussion of the topic. I'd like to see clear,
> normative answer to this question.

The current version is normative but far from clear. In fact, the most
natural interpretation is that it bans normal practice and throws away
the work that was done in defining different flow types to support
normal practice.

1. I don't see the need or desirability to put normative language on
registration practices.
2. The contents of said normative language are harmful.

I suggest two alternatives:

1. Remove the language.
2. Substitute the language by non-normative informative discussion.

You can also do other things, like introduce normative language that
makes sense. But I have not yet seen proposed language that would be
acceptable.

>
> EH
>
>
> On 3/15/12 12:30 PM, "Breno de Medeiros"  wrote:
>
>>I am proposing the entire removal of:
>>
>>"A client application consisting of multiple components, each with its
>>own client type (e.g. a distributed client with both a confidential
>>server-based component and a public browser-based component), MUST
>>register each component separately as a different client to ensure
>>proper handling by the authorization server."
>>
>>In particular the example of a server-side component versus
>>browser-based components is particularly unhelpful since it violates
>>the entire principle of why two response_type 'code' and 'token' were
>>defined, and how OAuth2 is typically implemented. That's when I claim
>>this normative language is redefining the protocol.
>>
>>
>>On Thu, Mar 15, 2012 at 12:13, Eran Hammer  wrote:
>>> Which text in -25 are you proposing we remove exactly? I can't judge th=
e
>>> text below without the full context of where and how it is proposed in
>>>the
>>> current document.
>>>
>>> Also, you are ignoring my detailed analysis of the current facts. We
>>>have
>>> two client types and the issue here is what to do with other, undefined
>>> types.
>>>
>>> EH
>>>
>>>
>>> On 3/15/12 11:54 AM, "Breno de Medeiros"  wrote:
>>>
>>>>My proposal is to remove any reference to registration (which is a red
>>>>herring and has raised all the problems we refer here) and refer to
>>>>client authentication instead.
>>>>
>>>>Proposal:
>>>>
>>>>"Clients may be implemented as a distributed set of components that
>>>>run in different security contexts. For instance, a single client may
>>>>include a webserver component and a script component in a browser. It
>>>>is not appropriate for the different components to utilize the same
>>>>client authentication mechanisms, since client authentication
>>>>credentials that are held securely in one context cannot be deployed
>>>>securely in another.
>>>>
>>>>Servers MUST mitigate security threats from client components that
>>>>cannot hold client credentials as securely by distinguishing them from
>>>>client components that can. Example of suitable measures are:
>>>>
>>>>- Requiring separate registration of components such as web server and
>>>>a mobile application.
>>>>- Restricting the time validity of tokens issued to clients that hold
>>>>no authentication credentials, such as browser script-based
>>>>components."
>>>>
>>>>Please don't truncate explanations in the interest of space if the
>>>>resulting text is confusing and possibly misleading. Better to say
>>>>nothing instead.
>>>>
>>>>On Thu, Mar 15, 2012 at 11:32, Eran Hammer  wrote:
>>>>> Here are the facts:
>>>>>
>>>>> The authorization server must know the client type in order to enforc=
e
>>>>>many
>>>>> of the requirements in the specification.
>>>>> The requirement to provide a client type is not decorated with a MUST
>>>>>or
>>>>> SHALL but that is implied.
>>>>> The specification only defines two client types: public and
>>>>>confidential.
>>>>> There is no client type defined for a hybrid client.
>>>>> The specification needs to address the very common use case of client=
s
>>>>>with
>>>>> both public and private components.
>>>>>
>>>>> I don't want to discuss in the specification how client identifiers
>>>>>are
>>>>> provisioned, nor do I want to discuss the potential binding of
>>>>>response
>>>>> types to client types. But we do need to provide some guidance to
>>>>>clients
>>>>> and authorization servers what to do with clients that do not fit the
>>>>> current type definitions.
>>>>>
>>>>> It is far too late for us to define a new client type, along with all
>>>>>the
>>>>> security considerations that such type imply. Our entire security
>>>>> consideration section and protocol design are based on have a well
>>>>>defined
>>>>> client type.
>>>>>
>>>>> Requiring separate registration for each component is the most
>>>>> straight-forward solution. Allowing the authorization server to offer
>>>>> alternatives is the backdoor to enable extensibility.
>>>>>
>>>>> Within these constraints, I am open to other prose or creative
>>>>>solutions.
>>>>> But the add-ons proposed are all ugly hacks. They clarify specific
>>>>>questions
>>>>> raised which I do not believe represent the core confusion here which
>>>>>is
>>>>> what is the right way to handle hybrid clients.
>>>>>
>>>>> The best way to move forward is to take a minute and ask the group to
>>>>>share
>>>>> how they handle such cases or how they think they should be handled.
>>>>>Based
>>>>> on that we can come up with a clear solution.
>>>>>
>>>>> EH
>>>>>
>>>>> From: Breno de Medeiros 
>>>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
>>>>> To: Eran Hammer-Lahav 
>>>>> Cc: Nat Sakimura , OAuth WG 
>>>>>
>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer 
>>>>>wrote:
>>>>>>
>>>>>> This add-on is unnecessary. It already says the authorization server
>>>>>>can
>>>>>> handle it any way it wants. The fact that other registration options
>>>>>>are
>>>>>> possible clearly covers the client identifier reuse case. As for the
>>>>>> response type, that=B9s not an issue but more of an optimization for=
 an
>>>>>>edge
>>>>>> case raised.
>>>>>
>>>>>
>>>>> It still feels like a horse by committee to me. "unless the
>>>>> authorization server provides other registration options to specify
>>>>>such
>>>>> complex clients." seems a very round about way to say that the core
>>>>>spec
>>>>> already provides for such arrangements in the most common scenario. I=
t
>>>>>is a
>>>>> bit of a stretch to say that the server provides "other registration
>>>>> options" by simply following strategy already laid out in the spec.
>>>>>
>>>>> In particular, I feel that this wording will be harmful to register
>>>>>extended
>>>>> behavior, e.g., alternative response_types by leading to fruitless
>>>>> conversations about spec compliance in the absence of real security
>>>>>risks.
>>>>>
>>>>> I do not believe the current text is the best representation of the
>>>>>spirit
>>>>> in which the spec was written (in particular the effort to specify tw=
o
>>>>>flows
>>>>> in detail to deal with precisely this issue) and possibly lead to
>>>>>harmful
>>>>> future interpretation.
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> EH
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>>>Behalf
>>>>>>Of
>>>>>> Nat Sakimura
>>>>>> Sent: Thursday, March 15, 2012 2:04 AM
>>>>>> To: Breno de Medeiros; OAuth WG
>>>>>>
>>>>>>
>>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> So, Eran's first proposal:
>>>>>>
>>>>>>
>>>>>>
>>>>>> =A0 A client application consisting of multiple components, each wit=
h
>>>>>>its
>>>>>> =A0 own client type (e.g. a distributed client with both a confident=
ial
>>>>>> =A0 server-based component and a public browser-based component), MU=
ST
>>>>>> =A0 register each component separately as a different client to ensu=
re
>>>>>>
>>>>>> =A0 proper handling by the authorization server, unless the
>>>>>>authorization
>>>>>> =A0 server provides other registration options to specify such compl=
ex
>>>>>> clients.
>>>>>>
>>>>>>
>>>>>>
>>>>>> kind of meets my concern. There seems to be another issue around the
>>>>>> usefulness of return_type in such case raised by Breno, and if I
>>>>>>understand
>>>>>> it correctly, Eran's answer was that these separate components may
>>>>>>have the
>>>>>> same client_id so that return_type is a valid parameter to be sent a=
t
>>>>>>the
>>>>>> request.
>>>>>>
>>>>>>
>>>>>>
>>>>>> So, to clarify these, perhaps changing the above text slightly to th=
e
>>>>>> following solves the problem?
>>>>>>
>>>>>>
>>>>>>
>>>>>> =A0 A client application consisting of multiple components, each wit=
h
>>>>>>its
>>>>>> =A0 own client type (e.g. a distributed client with both a confident=
ial
>>>>>> =A0 server-based component and a public browser-based component), MU=
ST
>>>>>> =A0 register each component separately as a different client to ensu=
re
>>>>>>
>>>>>> =A0 proper handling by the authorization server, unless the
>>>>>>authorization
>>>>>> =A0 server provides other registration options to specify such compl=
ex
>>>>>> clients.
>>>>>>
>>>>>> =A0 Each component MAY have the same client_id, in which case the
>>>>>>server
>>>>>>
>>>>>> =A0 judges the client type and the associated security context =A0ba=
sed
>>>>>>on
>>>>>> =A0 the response_type parameter in the request.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Would it solve your problem, Breno?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>>
>>>>>>
>>>>>> =3Dnat
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --Breno
>>>>
>>>>
>>>>
>>>>--
>>>>--Breno
>>>
>>
>>
>>
>>--
>>--Breno
>



--=20
--Breno

From eran@hueniverse.com  Thu Mar 15 15:44:24 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D352821F875D for ; Thu, 15 Mar 2012 15:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level: 
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0ut0mnYMt4e for ; Thu, 15 Mar 2012 15:44:23 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id BCB5D21F8754 for ; Thu, 15 Mar 2012 15:44:23 -0700 (PDT)
Received: (qmail 27876 invoked from network); 15 Mar 2012 22:44:21 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Mar 2012 22:44:21 -0000
Received: from P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id lykL1i0030RWb6o01ykMky; Thu, 15 Mar 2012 15:44:21 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 15 Mar 2012 15:43:43 -0700
From: Eran Hammer 
To: Breno de Medeiros 
Date: Thu, 15 Mar 2012 15:43:33 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0C8EwAWND4xIX8S2GQp6XyGSevPQADIRFA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08AC2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 22:44:24 -0000

I don't know how to better explain myself. Forget about the text you have i=
ssue with. Just answer this:

Reading the specification (with that text removed), what happens when a hyb=
rid client wants to register? What client type does it provide? How should =
the server handle this case?

EH

> -----Original Message-----
> From: Breno de Medeiros [mailto:breno@google.com]
> Sent: Thursday, March 15, 2012 2:12 PM
> To: Eran Hammer
> Cc: Nat Sakimura; OAuth WG
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>=20
> On Thu, Mar 15, 2012 at 13:13, Eran Hammer 
> wrote:
> > Ok. That's much better than my guess that you wanted to drop all the
> > registration text from the specification.
> >
> > What I'm looking for is a simple text that answers the question:
> >
> > "What to do if my client isn't simply public or confidential?"
> >
> > If we just drop the current text, the answer is implicitly "you can't
> > have such a client" because there is no way to register a client of
> > any other type.
> >
> > So let's try this again, and focus exclusively on answering this questi=
on.
> > My text takes a position which is, "you can't - unless". Your
> > suggestion is more of a vague discussion of the topic. I'd like to see
> > clear, normative answer to this question.
>=20
> The current version is normative but far from clear. In fact, the most na=
tural
> interpretation is that it bans normal practice and throws away the work t=
hat
> was done in defining different flow types to support normal practice.
>=20
> 1. I don't see the need or desirability to put normative language on
> registration practices.
> 2. The contents of said normative language are harmful.
>=20
> I suggest two alternatives:
>=20
> 1. Remove the language.
> 2. Substitute the language by non-normative informative discussion.
>=20
> You can also do other things, like introduce normative language that make=
s
> sense. But I have not yet seen proposed language that would be acceptable=
.
>=20
> >
> > EH
> >
> >
> > On 3/15/12 12:30 PM, "Breno de Medeiros"  wrote:
> >
> >>I am proposing the entire removal of:
> >>
> >>"A client application consisting of multiple components, each with its
> >>own client type (e.g. a distributed client with both a confidential
> >>server-based component and a public browser-based component), MUST
> >>register each component separately as a different client to ensure
> >>proper handling by the authorization server."
> >>
> >>In particular the example of a server-side component versus
> >>browser-based components is particularly unhelpful since it violates
> >>the entire principle of why two response_type 'code' and 'token' were
> >>defined, and how OAuth2 is typically implemented. That's when I claim
> >>this normative language is redefining the protocol.
> >>
> >>
> >>On Thu, Mar 15, 2012 at 12:13, Eran Hammer 
> wrote:
> >>> Which text in -25 are you proposing we remove exactly? I can't judge
> >>>the  text below without the full context of where and how it is
> >>>proposed in the  current document.
> >>>
> >>> Also, you are ignoring my detailed analysis of the current facts. We
> >>>have  two client types and the issue here is what to do with other,
> >>>undefined  types.
> >>>
> >>> EH
> >>>
> >>>
> >>> On 3/15/12 11:54 AM, "Breno de Medeiros" 
> wrote:
> >>>
> >>>>My proposal is to remove any reference to registration (which is a
> >>>>red herring and has raised all the problems we refer here) and refer
> >>>>to client authentication instead.
> >>>>
> >>>>Proposal:
> >>>>
> >>>>"Clients may be implemented as a distributed set of components that
> >>>>run in different security contexts. For instance, a single client
> >>>>may include a webserver component and a script component in a
> >>>>browser. It is not appropriate for the different components to
> >>>>utilize the same client authentication mechanisms, since client
> >>>>authentication credentials that are held securely in one context
> >>>>cannot be deployed securely in another.
> >>>>
> >>>>Servers MUST mitigate security threats from client components that
> >>>>cannot hold client credentials as securely by distinguishing them
> >>>>from client components that can. Example of suitable measures are:
> >>>>
> >>>>- Requiring separate registration of components such as web server
> >>>>and a mobile application.
> >>>>- Restricting the time validity of tokens issued to clients that
> >>>>hold no authentication credentials, such as browser script-based
> >>>>components."
> >>>>
> >>>>Please don't truncate explanations in the interest of space if the
> >>>>resulting text is confusing and possibly misleading. Better to say
> >>>>nothing instead.
> >>>>
> >>>>On Thu, Mar 15, 2012 at 11:32, Eran Hammer 
> wrote:
> >>>>> Here are the facts:
> >>>>>
> >>>>> The authorization server must know the client type in order to
> >>>>>enforce many  of the requirements in the specification.
> >>>>> The requirement to provide a client type is not decorated with a
> >>>>>MUST or  SHALL but that is implied.
> >>>>> The specification only defines two client types: public and
> >>>>>confidential.
> >>>>> There is no client type defined for a hybrid client.
> >>>>> The specification needs to address the very common use case of
> >>>>>clients with  both public and private components.
> >>>>>
> >>>>> I don't want to discuss in the specification how client
> >>>>>identifiers are  provisioned, nor do I want to discuss the
> >>>>>potential binding of response  types to client types. But we do
> >>>>>need to provide some guidance to clients  and authorization servers
> >>>>>what to do with clients that do not fit the  current type
> >>>>>definitions.
> >>>>>
> >>>>> It is far too late for us to define a new client type, along with
> >>>>>all the  security considerations that such type imply. Our entire
> >>>>>security  consideration section and protocol design are based on
> >>>>>have a well defined  client type.
> >>>>>
> >>>>> Requiring separate registration for each component is the most
> >>>>> straight-forward solution. Allowing the authorization server to
> >>>>> offer alternatives is the backdoor to enable extensibility.
> >>>>>
> >>>>> Within these constraints, I am open to other prose or creative
> >>>>>solutions.
> >>>>> But the add-ons proposed are all ugly hacks. They clarify specific
> >>>>>questions  raised which I do not believe represent the core
> >>>>>confusion here which is  what is the right way to handle hybrid
> >>>>>clients.
> >>>>>
> >>>>> The best way to move forward is to take a minute and ask the group
> >>>>>to share  how they handle such cases or how they think they should
> >>>>>be handled.
> >>>>>Based
> >>>>> on that we can come up with a clear solution.
> >>>>>
> >>>>> EH
> >>>>>
> >>>>> From: Breno de Medeiros 
> >>>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
> >>>>> To: Eran Hammer-Lahav 
> >>>>> Cc: Nat Sakimura , OAuth WG
> 
> >>>>>
> >>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer 
> >>>>>wrote:
> >>>>>>
> >>>>>> This add-on is unnecessary. It already says the authorization
> >>>>>>server can  handle it any way it wants. The fact that other
> >>>>>>registration options are  possible clearly covers the client
> >>>>>>identifier reuse case. As for the  response type, that=B9s not an
> >>>>>>issue but more of an optimization for an edge  case raised.
> >>>>>
> >>>>>
> >>>>> It still feels like a horse by committee to me. "unless the
> >>>>>authorization server provides other registration options to specify
> >>>>>such  complex clients." seems a very round about way to say that
> >>>>>the core spec  already provides for such arrangements in the most
> >>>>>common scenario. It is a  bit of a stretch to say that the server
> >>>>>provides "other registration  options" by simply following strategy
> >>>>>already laid out in the spec.
> >>>>>
> >>>>> In particular, I feel that this wording will be harmful to
> >>>>>register extended  behavior, e.g., alternative response_types by
> >>>>>leading to fruitless  conversations about spec compliance in the
> >>>>>absence of real security risks.
> >>>>>
> >>>>> I do not believe the current text is the best representation of
> >>>>>the spirit  in which the spec was written (in particular the effort
> >>>>>to specify two flows  in detail to deal with precisely this issue)
> >>>>>and possibly lead to harmful  future interpretation.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> EH
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >>>>>>Behalf Of  Nat Sakimura
> >>>>>> Sent: Thursday, March 15, 2012 2:04 AM
> >>>>>> To: Breno de Medeiros; OAuth WG
> >>>>>>
> >>>>>>
> >>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> So, Eran's first proposal:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> =A0 A client application consisting of multiple components, each
> >>>>>>with its
> >>>>>> =A0 own client type (e.g. a distributed client with both a
> >>>>>>confidential
> >>>>>> =A0 server-based component and a public browser-based component),
> >>>>>>MUST
> >>>>>> =A0 register each component separately as a different client to
> >>>>>>ensure
> >>>>>>
> >>>>>> =A0 proper handling by the authorization server, unless the
> >>>>>>authorization
> >>>>>> =A0 server provides other registration options to specify such
> >>>>>>complex  clients.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> kind of meets my concern. There seems to be another issue around
> >>>>>>the  usefulness of return_type in such case raised by Breno, and
> >>>>>>if I understand  it correctly, Eran's answer was that these
> >>>>>>separate components may have the  same client_id so that
> >>>>>>return_type is a valid parameter to be sent at the  request.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> So, to clarify these, perhaps changing the above text slightly to
> >>>>>> the following solves the problem?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> =A0 A client application consisting of multiple components, each
> >>>>>>with its
> >>>>>> =A0 own client type (e.g. a distributed client with both a
> >>>>>>confidential
> >>>>>> =A0 server-based component and a public browser-based component),
> >>>>>>MUST
> >>>>>> =A0 register each component separately as a different client to
> >>>>>>ensure
> >>>>>>
> >>>>>> =A0 proper handling by the authorization server, unless the
> >>>>>>authorization
> >>>>>> =A0 server provides other registration options to specify such
> >>>>>>complex  clients.
> >>>>>>
> >>>>>> =A0 Each component MAY have the same client_id, in which case the
> >>>>>>server
> >>>>>>
> >>>>>> =A0 judges the client type and the associated security context
> >>>>>>based on
> >>>>>> =A0 the response_type parameter in the request.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Would it solve your problem, Breno?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Best,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> =3Dnat
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> --Breno
> >>>>
> >>>>
> >>>>
> >>>>--
> >>>>--Breno
> >>>
> >>
> >>
> >>
> >>--
> >>--Breno
> >
>=20
>=20
>=20
> --
> --Breno

From breno@google.com  Thu Mar 15 15:54:44 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B5A21F857D for ; Thu, 15 Mar 2012 15:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.675
X-Spam-Level: 
X-Spam-Status: No, score=-102.675 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiv5HWpSKKc6 for ; Thu, 15 Mar 2012 15:54:43 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84EA421F857F for ; Thu, 15 Mar 2012 15:54:43 -0700 (PDT)
Received: by iazz13 with SMTP id z13so5231350iaz.31 for ; Thu, 15 Mar 2012 15:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=rqNJrRROROQKkxPDNRPq/8ZFmROW8fzS9juFJD61Blw=; b=OfZDoNO076ka2jQTl3mX+Eju9qPdmjmmgLMQ1idV6iyZN/6g+/GqBjoo1qgHLDveaN jtNns040RHogrtUoQNgNFbCOPIlIoDw+OpHPhaglJ7v9L4W2ZLZFI8O9R0mGqAJoIeYA Ny8domLYUe5HgA4ovlB4wIYQKBzoBHo4jUCBABYydNkLJRwnOF1mlPMNPUbR59m054iW 4vEwgF5pD0ZPkIhvS0zhzBfBNvqwMU7bJT6KN4eA//u598qjRlDe3DBfdz2uMOL/P43W y27JJMmRjvEK5otQqSxk6uScZU/t+tCckLSl2W2LhZC6z2lNdh04XTVHtnheHCfheuFc 4Pzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=rqNJrRROROQKkxPDNRPq/8ZFmROW8fzS9juFJD61Blw=; b=kf/cNNGrXzalv6Eo5oNWnXBmc+4QHpZpe+rJ6HDjf4EzWaImNUlA9JrP/ZwXtLDr8c 6PY0kZntSVQ9V/QVsTlFzvrHGdjrqfYXRJ36X/ccaCVJVTVBJhBB1wdWo+lXeDNiVv4A mFstHaWDhTN5g4yc/y/lEsWQPFdGYpPXu51xMTL/9nPplInkyPnOT7uhjOFekTLxXW07 W5jyJCJBUtafP55JR7SjvWDlWbUmeP/iPvJoL0kz3UHhyaDisjuo0L6geRbHaJQAk/Ky KTW3Me51DZ02m31zPwTyo+nXKtS9WeY7dqxgg5hPofoNeSQAJ9OtPiyjI2CsitznUyua rYcQ==
Received: by 10.50.187.231 with SMTP id fv7mr18349699igc.51.1331852082815; Thu, 15 Mar 2012 15:54:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.187.231 with SMTP id fv7mr18349693igc.51.1331852082698; Thu, 15 Mar 2012 15:54:42 -0700 (PDT)
Received: by 10.231.41.137 with HTTP; Thu, 15 Mar 2012 15:54:42 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08AC2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:    <90C41DD21FB7C64BB94121FBBC2E723453AFF08AC2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 15 Mar 2012 15:54:42 -0700
Message-ID: 
From: Breno de Medeiros 
To: Eran Hammer 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkT/HpSTf3yJe0EbqMYeCPdpIBmquiKb8QkuO2Z8mL+q2gFFCTeBu+HxEBhsFenjENwSzH17J/U2V0i8Oq5Zb5ImbBpEq4qnflHXdriUscZKc9V8+sIBnB6Fa9qpSxOCifyM95/
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 22:54:44 -0000

On Thu, Mar 15, 2012 at 15:43, Eran Hammer  wrote:
> I don't know how to better explain myself. Forget about the text you have=
 issue with. Just answer this:
>
> Reading the specification (with that text removed), what happens when a h=
ybrid client wants to register? What client type does it provide? How shoul=
d the server handle this case?

In the example case of the webserver + browser-based client
components, I think the server should just allow it. The browser does
not need to expose the client_secret since it requires no
authentication credentials. The webserver should use the client
credentials acquired during registration to authenticate itself when
using the code flow.

It's more interesting when mobile applications and webserver want to
share credentials. The mitigation strategy of limiting lifetime of
tokens may not work in this case. In general the registration server
should not allow the use of a single registration in this case. This
case is different from the above in the sense that installed
applications are typically _also_ using the 'code' flow, but from a
different security context. A server could allow both clients to share
the same registration information, but segregate the set of redirect
URLs and tie the code to each security context and apply different
client authentication requirements to each. Or the server could
require separate client registration for each component.

>
> EH
>
>> -----Original Message-----
>> From: Breno de Medeiros [mailto:breno@google.com]
>> Sent: Thursday, March 15, 2012 2:12 PM
>> To: Eran Hammer
>> Cc: Nat Sakimura; OAuth WG
>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>
>> On Thu, Mar 15, 2012 at 13:13, Eran Hammer 
>> wrote:
>> > Ok. That's much better than my guess that you wanted to drop all the
>> > registration text from the specification.
>> >
>> > What I'm looking for is a simple text that answers the question:
>> >
>> > "What to do if my client isn't simply public or confidential?"
>> >
>> > If we just drop the current text, the answer is implicitly "you can't
>> > have such a client" because there is no way to register a client of
>> > any other type.
>> >
>> > So let's try this again, and focus exclusively on answering this quest=
ion.
>> > My text takes a position which is, "you can't - unless". Your
>> > suggestion is more of a vague discussion of the topic. I'd like to see
>> > clear, normative answer to this question.
>>
>> The current version is normative but far from clear. In fact, the most n=
atural
>> interpretation is that it bans normal practice and throws away the work =
that
>> was done in defining different flow types to support normal practice.
>>
>> 1. I don't see the need or desirability to put normative language on
>> registration practices.
>> 2. The contents of said normative language are harmful.
>>
>> I suggest two alternatives:
>>
>> 1. Remove the language.
>> 2. Substitute the language by non-normative informative discussion.
>>
>> You can also do other things, like introduce normative language that mak=
es
>> sense. But I have not yet seen proposed language that would be acceptabl=
e.
>>
>> >
>> > EH
>> >
>> >
>> > On 3/15/12 12:30 PM, "Breno de Medeiros"  wrote:
>> >
>> >>I am proposing the entire removal of:
>> >>
>> >>"A client application consisting of multiple components, each with its
>> >>own client type (e.g. a distributed client with both a confidential
>> >>server-based component and a public browser-based component), MUST
>> >>register each component separately as a different client to ensure
>> >>proper handling by the authorization server."
>> >>
>> >>In particular the example of a server-side component versus
>> >>browser-based components is particularly unhelpful since it violates
>> >>the entire principle of why two response_type 'code' and 'token' were
>> >>defined, and how OAuth2 is typically implemented. That's when I claim
>> >>this normative language is redefining the protocol.
>> >>
>> >>
>> >>On Thu, Mar 15, 2012 at 12:13, Eran Hammer 
>> wrote:
>> >>> Which text in -25 are you proposing we remove exactly? I can't judge
>> >>>the =A0text below without the full context of where and how it is
>> >>>proposed in the =A0current document.
>> >>>
>> >>> Also, you are ignoring my detailed analysis of the current facts. We
>> >>>have =A0two client types and the issue here is what to do with other,
>> >>>undefined =A0types.
>> >>>
>> >>> EH
>> >>>
>> >>>
>> >>> On 3/15/12 11:54 AM, "Breno de Medeiros" 
>> wrote:
>> >>>
>> >>>>My proposal is to remove any reference to registration (which is a
>> >>>>red herring and has raised all the problems we refer here) and refer
>> >>>>to client authentication instead.
>> >>>>
>> >>>>Proposal:
>> >>>>
>> >>>>"Clients may be implemented as a distributed set of components that
>> >>>>run in different security contexts. For instance, a single client
>> >>>>may include a webserver component and a script component in a
>> >>>>browser. It is not appropriate for the different components to
>> >>>>utilize the same client authentication mechanisms, since client
>> >>>>authentication credentials that are held securely in one context
>> >>>>cannot be deployed securely in another.
>> >>>>
>> >>>>Servers MUST mitigate security threats from client components that
>> >>>>cannot hold client credentials as securely by distinguishing them
>> >>>>from client components that can. Example of suitable measures are:
>> >>>>
>> >>>>- Requiring separate registration of components such as web server
>> >>>>and a mobile application.
>> >>>>- Restricting the time validity of tokens issued to clients that
>> >>>>hold no authentication credentials, such as browser script-based
>> >>>>components."
>> >>>>
>> >>>>Please don't truncate explanations in the interest of space if the
>> >>>>resulting text is confusing and possibly misleading. Better to say
>> >>>>nothing instead.
>> >>>>
>> >>>>On Thu, Mar 15, 2012 at 11:32, Eran Hammer 
>> wrote:
>> >>>>> Here are the facts:
>> >>>>>
>> >>>>> The authorization server must know the client type in order to
>> >>>>>enforce many =A0of the requirements in the specification.
>> >>>>> The requirement to provide a client type is not decorated with a
>> >>>>>MUST or =A0SHALL but that is implied.
>> >>>>> The specification only defines two client types: public and
>> >>>>>confidential.
>> >>>>> There is no client type defined for a hybrid client.
>> >>>>> The specification needs to address the very common use case of
>> >>>>>clients with =A0both public and private components.
>> >>>>>
>> >>>>> I don't want to discuss in the specification how client
>> >>>>>identifiers are =A0provisioned, nor do I want to discuss the
>> >>>>>potential binding of response =A0types to client types. But we do
>> >>>>>need to provide some guidance to clients =A0and authorization serve=
rs
>> >>>>>what to do with clients that do not fit the =A0current type
>> >>>>>definitions.
>> >>>>>
>> >>>>> It is far too late for us to define a new client type, along with
>> >>>>>all the =A0security considerations that such type imply. Our entire
>> >>>>>security =A0consideration section and protocol design are based on
>> >>>>>have a well defined =A0client type.
>> >>>>>
>> >>>>> Requiring separate registration for each component is the most
>> >>>>> straight-forward solution. Allowing the authorization server to
>> >>>>> offer alternatives is the backdoor to enable extensibility.
>> >>>>>
>> >>>>> Within these constraints, I am open to other prose or creative
>> >>>>>solutions.
>> >>>>> But the add-ons proposed are all ugly hacks. They clarify specific
>> >>>>>questions =A0raised which I do not believe represent the core
>> >>>>>confusion here which is =A0what is the right way to handle hybrid
>> >>>>>clients.
>> >>>>>
>> >>>>> The best way to move forward is to take a minute and ask the group
>> >>>>>to share =A0how they handle such cases or how they think they shoul=
d
>> >>>>>be handled.
>> >>>>>Based
>> >>>>> on that we can come up with a clear solution.
>> >>>>>
>> >>>>> EH
>> >>>>>
>> >>>>> From: Breno de Medeiros 
>> >>>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
>> >>>>> To: Eran Hammer-Lahav 
>> >>>>> Cc: Nat Sakimura , OAuth WG
>> 
>> >>>>>
>> >>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer 
>> >>>>>wrote:
>> >>>>>>
>> >>>>>> This add-on is unnecessary. It already says the authorization
>> >>>>>>server can =A0handle it any way it wants. The fact that other
>> >>>>>>registration options are =A0possible clearly covers the client
>> >>>>>>identifier reuse case. As for the =A0response type, that=B9s not a=
n
>> >>>>>>issue but more of an optimization for an edge =A0case raised.
>> >>>>>
>> >>>>>
>> >>>>> It still feels like a horse by committee to me. "unless the
>> >>>>>authorization server provides other registration options to specify
>> >>>>>such =A0complex clients." seems a very round about way to say that
>> >>>>>the core spec =A0already provides for such arrangements in the most
>> >>>>>common scenario. It is a =A0bit of a stretch to say that the server
>> >>>>>provides "other registration =A0options" by simply following strate=
gy
>> >>>>>already laid out in the spec.
>> >>>>>
>> >>>>> In particular, I feel that this wording will be harmful to
>> >>>>>register extended =A0behavior, e.g., alternative response_types by
>> >>>>>leading to fruitless =A0conversations about spec compliance in the
>> >>>>>absence of real security risks.
>> >>>>>
>> >>>>> I do not believe the current text is the best representation of
>> >>>>>the spirit =A0in which the spec was written (in particular the effo=
rt
>> >>>>>to specify two flows =A0in detail to deal with precisely this issue=
)
>> >>>>>and possibly lead to harmful =A0future interpretation.
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> EH
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>> >>>>>>Behalf Of =A0Nat Sakimura
>> >>>>>> Sent: Thursday, March 15, 2012 2:04 AM
>> >>>>>> To: Breno de Medeiros; OAuth WG
>> >>>>>>
>> >>>>>>
>> >>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> So, Eran's first proposal:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> =A0 A client application consisting of multiple components, each
>> >>>>>>with its
>> >>>>>> =A0 own client type (e.g. a distributed client with both a
>> >>>>>>confidential
>> >>>>>> =A0 server-based component and a public browser-based component),
>> >>>>>>MUST
>> >>>>>> =A0 register each component separately as a different client to
>> >>>>>>ensure
>> >>>>>>
>> >>>>>> =A0 proper handling by the authorization server, unless the
>> >>>>>>authorization
>> >>>>>> =A0 server provides other registration options to specify such
>> >>>>>>complex =A0clients.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> kind of meets my concern. There seems to be another issue around
>> >>>>>>the =A0usefulness of return_type in such case raised by Breno, and
>> >>>>>>if I understand =A0it correctly, Eran's answer was that these
>> >>>>>>separate components may have the =A0same client_id so that
>> >>>>>>return_type is a valid parameter to be sent at the =A0request.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> So, to clarify these, perhaps changing the above text slightly to
>> >>>>>> the following solves the problem?
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> =A0 A client application consisting of multiple components, each
>> >>>>>>with its
>> >>>>>> =A0 own client type (e.g. a distributed client with both a
>> >>>>>>confidential
>> >>>>>> =A0 server-based component and a public browser-based component),
>> >>>>>>MUST
>> >>>>>> =A0 register each component separately as a different client to
>> >>>>>>ensure
>> >>>>>>
>> >>>>>> =A0 proper handling by the authorization server, unless the
>> >>>>>>authorization
>> >>>>>> =A0 server provides other registration options to specify such
>> >>>>>>complex =A0clients.
>> >>>>>>
>> >>>>>> =A0 Each component MAY have the same client_id, in which case the
>> >>>>>>server
>> >>>>>>
>> >>>>>> =A0 judges the client type and the associated security context
>> >>>>>>based on
>> >>>>>> =A0 the response_type parameter in the request.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Would it solve your problem, Breno?
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Best,
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> =3Dnat
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> --Breno
>> >>>>
>> >>>>
>> >>>>
>> >>>>--
>> >>>>--Breno
>> >>>
>> >>
>> >>
>> >>
>> >>--
>> >>--Breno
>> >
>>
>>
>>
>> --
>> --Breno



--=20
--Breno

From breno.demedeiros@gmail.com  Sat Mar 17 08:50:37 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6697921F85B7 for ; Sat, 17 Mar 2012 08:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.736
X-Spam-Level: 
X-Spam-Status: No, score=-102.736 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db-5DAHx3uo5 for ; Sat, 17 Mar 2012 08:50:36 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7664321F861F for ; Sat, 17 Mar 2012 08:50:27 -0700 (PDT)
Received: by iazz13 with SMTP id z13so8206532iaz.31 for ; Sat, 17 Mar 2012 08:50:27 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eOQMn137jZC6B/sBovedTnzVtII6ADeWrB3KPEOXGpA=; b=aoZCqvg5UFTQBevZ3QZFIGVurZUOv2qT79r/T9W1SwG7Yq7mvCVEz1l15rpfCAQRe2 q4R8QQf73XhiP0zL68OzfclzJjPpg5jq9zuRvDthKZG0ZQbtvn7OkHiwTz0904MgO/uh SNGgYKb1+LgKHjNEB0U7eyHqZuir4xdD/iQWuVjET6i/jsyPrXoTutNkFwXYXyyBd3FA vHon56wUXKOtMp5G7PgXn/B5kFgHxQUff2UcPCor2eOIi0DkC3pWA0cmDlUcWdgj9C2+ TOL2gmTPupMuh1VY+7/YF3hhe7p+djAPDUvFAjaO4pBc5mmLR6H/KgpBzNjgBy03JfY0 QhQA==
MIME-Version: 1.0
Received: by 10.60.18.197 with SMTP id y5mr7264073oed.58.1331999427014; Sat, 17 Mar 2012 08:50:27 -0700 (PDT)
Sender: breno.demedeiros@gmail.com
Received: by 10.182.49.198 with HTTP; Sat, 17 Mar 2012 08:50:26 -0700 (PDT)
In-Reply-To: 
References:    <90C41DD21FB7C64BB94121FBBC2E723453AFF08AC2@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
Date: Sat, 17 Mar 2012 08:50:26 -0700
X-Google-Sender-Auth: Tewl9Q70zDdjBa7vNpPW4amGI9I
Message-ID: 
From: Breno 
To: Eran Hammer 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Mar 2012 15:50:37 -0000

To summarize, I am weary of registration normative language that
appears to disallow common practice implemented by servers to securely
support multi-component applications. If these common practices will
be non-compliant (or at least it appears to be so on first reading by
many different people with detailed knowledge of the spec), isn't it
incumbent on this spec to provide guidance on _how_ different
components of an application will interoperate under different
registration? At least for the very common case of a webserver +
browser component, the importance of which is already enshrined in the
spec by the definition of two response_types and flows?

On Thu, Mar 15, 2012 at 3:54 PM, Breno de Medeiros  wrote=
:
> On Thu, Mar 15, 2012 at 15:43, Eran Hammer  wrote:
>> I don't know how to better explain myself. Forget about the text you hav=
e issue with. Just answer this:
>>
>> Reading the specification (with that text removed), what happens when a =
hybrid client wants to register? What client type does it provide? How shou=
ld the server handle this case?
>
> In the example case of the webserver + browser-based client
> components, I think the server should just allow it. The browser does
> not need to expose the client_secret since it requires no
> authentication credentials. The webserver should use the client
> credentials acquired during registration to authenticate itself when
> using the code flow.
>
> It's more interesting when mobile applications and webserver want to
> share credentials. The mitigation strategy of limiting lifetime of
> tokens may not work in this case. In general the registration server
> should not allow the use of a single registration in this case. This
> case is different from the above in the sense that installed
> applications are typically _also_ using the 'code' flow, but from a
> different security context. A server could allow both clients to share
> the same registration information, but segregate the set of redirect
> URLs and tie the code to each security context and apply different
> client authentication requirements to each. Or the server could
> require separate client registration for each component.
>
>>
>> EH
>>
>>> -----Original Message-----
>>> From: Breno de Medeiros [mailto:breno@google.com]
>>> Sent: Thursday, March 15, 2012 2:12 PM
>>> To: Eran Hammer
>>> Cc: Nat Sakimura; OAuth WG
>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>>
>>> On Thu, Mar 15, 2012 at 13:13, Eran Hammer 
>>> wrote:
>>> > Ok. That's much better than my guess that you wanted to drop all the
>>> > registration text from the specification.
>>> >
>>> > What I'm looking for is a simple text that answers the question:
>>> >
>>> > "What to do if my client isn't simply public or confidential?"
>>> >
>>> > If we just drop the current text, the answer is implicitly "you can't
>>> > have such a client" because there is no way to register a client of
>>> > any other type.
>>> >
>>> > So let's try this again, and focus exclusively on answering this ques=
tion.
>>> > My text takes a position which is, "you can't - unless". Your
>>> > suggestion is more of a vague discussion of the topic. I'd like to se=
e
>>> > clear, normative answer to this question.
>>>
>>> The current version is normative but far from clear. In fact, the most =
natural
>>> interpretation is that it bans normal practice and throws away the work=
 that
>>> was done in defining different flow types to support normal practice.
>>>
>>> 1. I don't see the need or desirability to put normative language on
>>> registration practices.
>>> 2. The contents of said normative language are harmful.
>>>
>>> I suggest two alternatives:
>>>
>>> 1. Remove the language.
>>> 2. Substitute the language by non-normative informative discussion.
>>>
>>> You can also do other things, like introduce normative language that ma=
kes
>>> sense. But I have not yet seen proposed language that would be acceptab=
le.
>>>
>>> >
>>> > EH
>>> >
>>> >
>>> > On 3/15/12 12:30 PM, "Breno de Medeiros"  wrote:
>>> >
>>> >>I am proposing the entire removal of:
>>> >>
>>> >>"A client application consisting of multiple components, each with it=
s
>>> >>own client type (e.g. a distributed client with both a confidential
>>> >>server-based component and a public browser-based component), MUST
>>> >>register each component separately as a different client to ensure
>>> >>proper handling by the authorization server."
>>> >>
>>> >>In particular the example of a server-side component versus
>>> >>browser-based components is particularly unhelpful since it violates
>>> >>the entire principle of why two response_type 'code' and 'token' were
>>> >>defined, and how OAuth2 is typically implemented. That's when I claim
>>> >>this normative language is redefining the protocol.
>>> >>
>>> >>
>>> >>On Thu, Mar 15, 2012 at 12:13, Eran Hammer 
>>> wrote:
>>> >>> Which text in -25 are you proposing we remove exactly? I can't judg=
e
>>> >>>the =A0text below without the full context of where and how it is
>>> >>>proposed in the =A0current document.
>>> >>>
>>> >>> Also, you are ignoring my detailed analysis of the current facts. W=
e
>>> >>>have =A0two client types and the issue here is what to do with other=
,
>>> >>>undefined =A0types.
>>> >>>
>>> >>> EH
>>> >>>
>>> >>>
>>> >>> On 3/15/12 11:54 AM, "Breno de Medeiros" 
>>> wrote:
>>> >>>
>>> >>>>My proposal is to remove any reference to registration (which is a
>>> >>>>red herring and has raised all the problems we refer here) and refe=
r
>>> >>>>to client authentication instead.
>>> >>>>
>>> >>>>Proposal:
>>> >>>>
>>> >>>>"Clients may be implemented as a distributed set of components that
>>> >>>>run in different security contexts. For instance, a single client
>>> >>>>may include a webserver component and a script component in a
>>> >>>>browser. It is not appropriate for the different components to
>>> >>>>utilize the same client authentication mechanisms, since client
>>> >>>>authentication credentials that are held securely in one context
>>> >>>>cannot be deployed securely in another.
>>> >>>>
>>> >>>>Servers MUST mitigate security threats from client components that
>>> >>>>cannot hold client credentials as securely by distinguishing them
>>> >>>>from client components that can. Example of suitable measures are:
>>> >>>>
>>> >>>>- Requiring separate registration of components such as web server
>>> >>>>and a mobile application.
>>> >>>>- Restricting the time validity of tokens issued to clients that
>>> >>>>hold no authentication credentials, such as browser script-based
>>> >>>>components."
>>> >>>>
>>> >>>>Please don't truncate explanations in the interest of space if the
>>> >>>>resulting text is confusing and possibly misleading. Better to say
>>> >>>>nothing instead.
>>> >>>>
>>> >>>>On Thu, Mar 15, 2012 at 11:32, Eran Hammer 
>>> wrote:
>>> >>>>> Here are the facts:
>>> >>>>>
>>> >>>>> The authorization server must know the client type in order to
>>> >>>>>enforce many =A0of the requirements in the specification.
>>> >>>>> The requirement to provide a client type is not decorated with a
>>> >>>>>MUST or =A0SHALL but that is implied.
>>> >>>>> The specification only defines two client types: public and
>>> >>>>>confidential.
>>> >>>>> There is no client type defined for a hybrid client.
>>> >>>>> The specification needs to address the very common use case of
>>> >>>>>clients with =A0both public and private components.
>>> >>>>>
>>> >>>>> I don't want to discuss in the specification how client
>>> >>>>>identifiers are =A0provisioned, nor do I want to discuss the
>>> >>>>>potential binding of response =A0types to client types. But we do
>>> >>>>>need to provide some guidance to clients =A0and authorization serv=
ers
>>> >>>>>what to do with clients that do not fit the =A0current type
>>> >>>>>definitions.
>>> >>>>>
>>> >>>>> It is far too late for us to define a new client type, along with
>>> >>>>>all the =A0security considerations that such type imply. Our entir=
e
>>> >>>>>security =A0consideration section and protocol design are based on
>>> >>>>>have a well defined =A0client type.
>>> >>>>>
>>> >>>>> Requiring separate registration for each component is the most
>>> >>>>> straight-forward solution. Allowing the authorization server to
>>> >>>>> offer alternatives is the backdoor to enable extensibility.
>>> >>>>>
>>> >>>>> Within these constraints, I am open to other prose or creative
>>> >>>>>solutions.
>>> >>>>> But the add-ons proposed are all ugly hacks. They clarify specifi=
c
>>> >>>>>questions =A0raised which I do not believe represent the core
>>> >>>>>confusion here which is =A0what is the right way to handle hybrid
>>> >>>>>clients.
>>> >>>>>
>>> >>>>> The best way to move forward is to take a minute and ask the grou=
p
>>> >>>>>to share =A0how they handle such cases or how they think they shou=
ld
>>> >>>>>be handled.
>>> >>>>>Based
>>> >>>>> on that we can come up with a clear solution.
>>> >>>>>
>>> >>>>> EH
>>> >>>>>
>>> >>>>> From: Breno de Medeiros 
>>> >>>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
>>> >>>>> To: Eran Hammer-Lahav 
>>> >>>>> Cc: Nat Sakimura , OAuth WG
>>> 
>>> >>>>>
>>> >>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer 
>>> >>>>>wrote:
>>> >>>>>>
>>> >>>>>> This add-on is unnecessary. It already says the authorization
>>> >>>>>>server can =A0handle it any way it wants. The fact that other
>>> >>>>>>registration options are =A0possible clearly covers the client
>>> >>>>>>identifier reuse case. As for the =A0response type, that=B9s not =
an
>>> >>>>>>issue but more of an optimization for an edge =A0case raised.
>>> >>>>>
>>> >>>>>
>>> >>>>> It still feels like a horse by committee to me. "unless the
>>> >>>>>authorization server provides other registration options to specif=
y
>>> >>>>>such =A0complex clients." seems a very round about way to say that
>>> >>>>>the core spec =A0already provides for such arrangements in the mos=
t
>>> >>>>>common scenario. It is a =A0bit of a stretch to say that the serve=
r
>>> >>>>>provides "other registration =A0options" by simply following strat=
egy
>>> >>>>>already laid out in the spec.
>>> >>>>>
>>> >>>>> In particular, I feel that this wording will be harmful to
>>> >>>>>register extended =A0behavior, e.g., alternative response_types by
>>> >>>>>leading to fruitless =A0conversations about spec compliance in the
>>> >>>>>absence of real security risks.
>>> >>>>>
>>> >>>>> I do not believe the current text is the best representation of
>>> >>>>>the spirit =A0in which the spec was written (in particular the eff=
ort
>>> >>>>>to specify two flows =A0in detail to deal with precisely this issu=
e)
>>> >>>>>and possibly lead to harmful =A0future interpretation.
>>> >>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> EH
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>> >>>>>>Behalf Of =A0Nat Sakimura
>>> >>>>>> Sent: Thursday, March 15, 2012 2:04 AM
>>> >>>>>> To: Breno de Medeiros; OAuth WG
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> So, Eran's first proposal:
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> =A0 A client application consisting of multiple components, each
>>> >>>>>>with its
>>> >>>>>> =A0 own client type (e.g. a distributed client with both a
>>> >>>>>>confidential
>>> >>>>>> =A0 server-based component and a public browser-based component)=
,
>>> >>>>>>MUST
>>> >>>>>> =A0 register each component separately as a different client to
>>> >>>>>>ensure
>>> >>>>>>
>>> >>>>>> =A0 proper handling by the authorization server, unless the
>>> >>>>>>authorization
>>> >>>>>> =A0 server provides other registration options to specify such
>>> >>>>>>complex =A0clients.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> kind of meets my concern. There seems to be another issue around
>>> >>>>>>the =A0usefulness of return_type in such case raised by Breno, an=
d
>>> >>>>>>if I understand =A0it correctly, Eran's answer was that these
>>> >>>>>>separate components may have the =A0same client_id so that
>>> >>>>>>return_type is a valid parameter to be sent at the =A0request.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> So, to clarify these, perhaps changing the above text slightly t=
o
>>> >>>>>> the following solves the problem?
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> =A0 A client application consisting of multiple components, each
>>> >>>>>>with its
>>> >>>>>> =A0 own client type (e.g. a distributed client with both a
>>> >>>>>>confidential
>>> >>>>>> =A0 server-based component and a public browser-based component)=
,
>>> >>>>>>MUST
>>> >>>>>> =A0 register each component separately as a different client to
>>> >>>>>>ensure
>>> >>>>>>
>>> >>>>>> =A0 proper handling by the authorization server, unless the
>>> >>>>>>authorization
>>> >>>>>> =A0 server provides other registration options to specify such
>>> >>>>>>complex =A0clients.
>>> >>>>>>
>>> >>>>>> =A0 Each component MAY have the same client_id, in which case th=
e
>>> >>>>>>server
>>> >>>>>>
>>> >>>>>> =A0 judges the client type and the associated security context
>>> >>>>>>based on
>>> >>>>>> =A0 the response_type parameter in the request.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Would it solve your problem, Breno?
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Best,
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> =3Dnat
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> --Breno
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>--
>>> >>>>--Breno
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >>--
>>> >>--Breno
>>> >
>>>
>>>
>>>
>>> --
>>> --Breno
>
>
>
> --
> --Breno
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--=20
Breno de Medeiros

From eran@hueniverse.com  Sat Mar 17 09:18:13 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1427F21F8623 for ; Sat, 17 Mar 2012 09:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level: 
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRqByg5G5Ldk for ; Sat, 17 Mar 2012 09:18:11 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A5EF521F8617 for ; Sat, 17 Mar 2012 09:18:11 -0700 (PDT)
Received: (qmail 9752 invoked from network); 17 Mar 2012 16:18:10 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Mar 2012 16:18:10 -0000
Received: from P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.47]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id mgJ91i00211lQaG01gJ9ZK; Sat, 17 Mar 2012 09:18:09 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Sat, 17 Mar 2012 09:18:10 -0700
From: Eran Hammer 
To: Breno 
Date: Sat, 17 Mar 2012 09:17:57 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0EVbAbos7Kg0kAQ4ihiH0/IHaAoQAAlH+g
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:    <90C41DD21FB7C64BB94121FBBC2E723453AFF08AC2@P3PW5EX1MB01.EX1.SECURESERVER.NET>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Mar 2012 16:18:13 -0000

How about we phrase it the other way:

A clients may be implemented as a distributed set of components, each with =
a different
client type and security context (e.g. a distributed client with both a con=
fidential
server-based component and a public browser-based component). If the author=
ization
 server does not provide support for such clients, or does not provide guid=
ance with regard
to their registration, the client SHOULD register each component as a separ=
ate client.

This does two thing: put the server's policy first instead of as the except=
ion, and uses SHOULD instead of MUST which seems to be too strong for many =
people.

Better?

EH


> -----Original Message-----
> From: breno.demedeiros@gmail.com
> [mailto:breno.demedeiros@gmail.com] On Behalf Of Breno
> Sent: Saturday, March 17, 2012 8:50 AM
> To: Eran Hammer
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>
> To summarize, I am weary of registration normative language that appears =
to
> disallow common practice implemented by servers to securely support multi=
-
> component applications. If these common practices will be non-compliant (=
or
> at least it appears to be so on first reading by many different people wi=
th
> detailed knowledge of the spec), isn't it incumbent on this spec to provi=
de
> guidance on _how_ different components of an application will interoperat=
e
> under different registration? At least for the very common case of a
> webserver + browser component, the importance of which is already
> enshrined in the spec by the definition of two response_types and flows?
>
> On Thu, Mar 15, 2012 at 3:54 PM, Breno de Medeiros 
> wrote:
> > On Thu, Mar 15, 2012 at 15:43, Eran Hammer 
> wrote:
> >> I don't know how to better explain myself. Forget about the text you
> have issue with. Just answer this:
> >>
> >> Reading the specification (with that text removed), what happens when =
a
> hybrid client wants to register? What client type does it provide? How sh=
ould
> the server handle this case?
> >
> > In the example case of the webserver + browser-based client
> > components, I think the server should just allow it. The browser does
> > not need to expose the client_secret since it requires no
> > authentication credentials. The webserver should use the client
> > credentials acquired during registration to authenticate itself when
> > using the code flow.
> >
> > It's more interesting when mobile applications and webserver want to
> > share credentials. The mitigation strategy of limiting lifetime of
> > tokens may not work in this case. In general the registration server
> > should not allow the use of a single registration in this case. This
> > case is different from the above in the sense that installed
> > applications are typically _also_ using the 'code' flow, but from a
> > different security context. A server could allow both clients to share
> > the same registration information, but segregate the set of redirect
> > URLs and tie the code to each security context and apply different
> > client authentication requirements to each. Or the server could
> > require separate client registration for each component.
> >
> >>
> >> EH
> >>
> >>> -----Original Message-----
> >>> From: Breno de Medeiros [mailto:breno@google.com]
> >>> Sent: Thursday, March 15, 2012 2:12 PM
> >>> To: Eran Hammer
> >>> Cc: Nat Sakimura; OAuth WG
> >>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >>>
> >>> On Thu, Mar 15, 2012 at 13:13, Eran Hammer 
> >>> wrote:
> >>> > Ok. That's much better than my guess that you wanted to drop all
> >>> > the registration text from the specification.
> >>> >
> >>> > What I'm looking for is a simple text that answers the question:
> >>> >
> >>> > "What to do if my client isn't simply public or confidential?"
> >>> >
> >>> > If we just drop the current text, the answer is implicitly "you
> >>> > can't have such a client" because there is no way to register a
> >>> > client of any other type.
> >>> >
> >>> > So let's try this again, and focus exclusively on answering this qu=
estion.
> >>> > My text takes a position which is, "you can't - unless". Your
> >>> > suggestion is more of a vague discussion of the topic. I'd like to
> >>> > see clear, normative answer to this question.
> >>>
> >>> The current version is normative but far from clear. In fact, the
> >>> most natural interpretation is that it bans normal practice and
> >>> throws away the work that was done in defining different flow types t=
o
> support normal practice.
> >>>
> >>> 1. I don't see the need or desirability to put normative language on
> >>> registration practices.
> >>> 2. The contents of said normative language are harmful.
> >>>
> >>> I suggest two alternatives:
> >>>
> >>> 1. Remove the language.
> >>> 2. Substitute the language by non-normative informative discussion.
> >>>
> >>> You can also do other things, like introduce normative language that
> >>> makes sense. But I have not yet seen proposed language that would be
> acceptable.
> >>>
> >>> >
> >>> > EH
> >>> >
> >>> >
> >>> > On 3/15/12 12:30 PM, "Breno de Medeiros" 
> wrote:
> >>> >
> >>> >>I am proposing the entire removal of:
> >>> >>
> >>> >>"A client application consisting of multiple components, each with
> >>> >>its own client type (e.g. a distributed client with both a
> >>> >>confidential server-based component and a public browser-based
> >>> >>component), MUST register each component separately as a different
> >>> >>client to ensure proper handling by the authorization server."
> >>> >>
> >>> >>In particular the example of a server-side component versus
> >>> >>browser-based components is particularly unhelpful since it
> >>> >>violates the entire principle of why two response_type 'code' and
> >>> >>'token' were defined, and how OAuth2 is typically implemented.
> >>> >>That's when I claim this normative language is redefining the proto=
col.
> >>> >>
> >>> >>
> >>> >>On Thu, Mar 15, 2012 at 12:13, Eran Hammer 
> >>> wrote:
> >>> >>> Which text in -25 are you proposing we remove exactly? I can't
> >>> >>>judge the  text below without the full context of where and how
> >>> >>>it is proposed in the  current document.
> >>> >>>
> >>> >>> Also, you are ignoring my detailed analysis of the current
> >>> >>>facts. We have  two client types and the issue here is what to do
> >>> >>>with other, undefined  types.
> >>> >>>
> >>> >>> EH
> >>> >>>
> >>> >>>
> >>> >>> On 3/15/12 11:54 AM, "Breno de Medeiros" 
> >>> wrote:
> >>> >>>
> >>> >>>>My proposal is to remove any reference to registration (which is
> >>> >>>>a red herring and has raised all the problems we refer here) and
> >>> >>>>refer to client authentication instead.
> >>> >>>>
> >>> >>>>Proposal:
> >>> >>>>
> >>> >>>>"Clients may be implemented as a distributed set of components
> >>> >>>>that run in different security contexts. For instance, a single
> >>> >>>>client may include a webserver component and a script component
> >>> >>>>in a browser. It is not appropriate for the different components
> >>> >>>>to utilize the same client authentication mechanisms, since
> >>> >>>>client authentication credentials that are held securely in one
> >>> >>>>context cannot be deployed securely in another.
> >>> >>>>
> >>> >>>>Servers MUST mitigate security threats from client components
> >>> >>>>that cannot hold client credentials as securely by
> >>> >>>>distinguishing them from client components that can. Example of
> suitable measures are:
> >>> >>>>
> >>> >>>>- Requiring separate registration of components such as web
> >>> >>>>server and a mobile application.
> >>> >>>>- Restricting the time validity of tokens issued to clients that
> >>> >>>>hold no authentication credentials, such as browser script-based
> >>> >>>>components."
> >>> >>>>
> >>> >>>>Please don't truncate explanations in the interest of space if
> >>> >>>>the resulting text is confusing and possibly misleading. Better
> >>> >>>>to say nothing instead.
> >>> >>>>
> >>> >>>>On Thu, Mar 15, 2012 at 11:32, Eran Hammer
> 
> >>> wrote:
> >>> >>>>> Here are the facts:
> >>> >>>>>
> >>> >>>>> The authorization server must know the client type in order to
> >>> >>>>>enforce many  of the requirements in the specification.
> >>> >>>>> The requirement to provide a client type is not decorated with
> >>> >>>>>a MUST or  SHALL but that is implied.
> >>> >>>>> The specification only defines two client types: public and
> >>> >>>>>confidential.
> >>> >>>>> There is no client type defined for a hybrid client.
> >>> >>>>> The specification needs to address the very common use case of
> >>> >>>>>clients with  both public and private components.
> >>> >>>>>
> >>> >>>>> I don't want to discuss in the specification how client
> >>> >>>>>identifiers are  provisioned, nor do I want to discuss the
> >>> >>>>>potential binding of response  types to client types. But we do
> >>> >>>>>need to provide some guidance to clients  and authorization
> >>> >>>>>servers what to do with clients that do not fit the  current
> >>> >>>>>type definitions.
> >>> >>>>>
> >>> >>>>> It is far too late for us to define a new client type, along
> >>> >>>>>with all the  security considerations that such type imply. Our
> >>> >>>>>entire security  consideration section and protocol design are
> >>> >>>>>based on have a well defined  client type.
> >>> >>>>>
> >>> >>>>> Requiring separate registration for each component is the most
> >>> >>>>> straight-forward solution. Allowing the authorization server
> >>> >>>>> to offer alternatives is the backdoor to enable extensibility.
> >>> >>>>>
> >>> >>>>> Within these constraints, I am open to other prose or creative
> >>> >>>>>solutions.
> >>> >>>>> But the add-ons proposed are all ugly hacks. They clarify
> >>> >>>>>specific questions  raised which I do not believe represent the
> >>> >>>>>core confusion here which is  what is the right way to handle
> >>> >>>>>hybrid clients.
> >>> >>>>>
> >>> >>>>> The best way to move forward is to take a minute and ask the
> >>> >>>>>group to share  how they handle such cases or how they think
> >>> >>>>>they should be handled.
> >>> >>>>>Based
> >>> >>>>> on that we can come up with a clear solution.
> >>> >>>>>
> >>> >>>>> EH
> >>> >>>>>
> >>> >>>>> From: Breno de Medeiros 
> >>> >>>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
> >>> >>>>> To: Eran Hammer-Lahav 
> >>> >>>>> Cc: Nat Sakimura , OAuth WG
> >>> 
> >>> >>>>>
> >>> >>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev.
> >>> >>>>> 23
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer
> >>> >>>>>
> >>> >>>>>wrote:
> >>> >>>>>>
> >>> >>>>>> This add-on is unnecessary. It already says the authorization
> >>> >>>>>>server can  handle it any way it wants. The fact that other
> >>> >>>>>>registration options are  possible clearly covers the client
> >>> >>>>>>identifier reuse case. As for the  response type, that=B9s not
> >>> >>>>>>an issue but more of an optimization for an edge  case raised.
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> It still feels like a horse by committee to me. "unless the
> >>> >>>>>authorization server provides other registration options to
> >>> >>>>>specify such  complex clients." seems a very round about way to
> >>> >>>>>say that the core spec  already provides for such arrangements
> >>> >>>>>in the most common scenario. It is a  bit of a stretch to say
> >>> >>>>>that the server provides "other registration  options" by
> >>> >>>>>simply following strategy already laid out in the spec.
> >>> >>>>>
> >>> >>>>> In particular, I feel that this wording will be harmful to
> >>> >>>>>register extended  behavior, e.g., alternative response_types
> >>> >>>>>by leading to fruitless  conversations about spec compliance in
> >>> >>>>>the absence of real security risks.
> >>> >>>>>
> >>> >>>>> I do not believe the current text is the best representation
> >>> >>>>>of the spirit  in which the spec was written (in particular the
> >>> >>>>>effort to specify two flows  in detail to deal with precisely
> >>> >>>>>this issue) and possibly lead to harmful  future interpretation.
> >>> >>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> EH
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
> bounces@ietf.org]
> >>> >>>>>>On Behalf Of  Nat Sakimura
> >>> >>>>>> Sent: Thursday, March 15, 2012 2:04 AM
> >>> >>>>>> To: Breno de Medeiros; OAuth WG
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev.
> >>> >>>>>> 23
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> So, Eran's first proposal:
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>   A client application consisting of multiple components,
> >>> >>>>>>each with its
> >>> >>>>>>   own client type (e.g. a distributed client with both a
> >>> >>>>>>confidential
> >>> >>>>>>   server-based component and a public browser-based
> >>> >>>>>>component), MUST
> >>> >>>>>>   register each component separately as a different client to
> >>> >>>>>>ensure
> >>> >>>>>>
> >>> >>>>>>   proper handling by the authorization server, unless the
> >>> >>>>>>authorization
> >>> >>>>>>   server provides other registration options to specify such
> >>> >>>>>>complex  clients.
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> kind of meets my concern. There seems to be another issue
> >>> >>>>>>around the  usefulness of return_type in such case raised by
> >>> >>>>>>Breno, and if I understand  it correctly, Eran's answer was
> >>> >>>>>>that these separate components may have the  same client_id
> so
> >>> >>>>>>that return_type is a valid parameter to be sent at the  reques=
t.
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> So, to clarify these, perhaps changing the above text
> >>> >>>>>> slightly to the following solves the problem?
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>   A client application consisting of multiple components,
> >>> >>>>>>each with its
> >>> >>>>>>   own client type (e.g. a distributed client with both a
> >>> >>>>>>confidential
> >>> >>>>>>   server-based component and a public browser-based
> >>> >>>>>>component), MUST
> >>> >>>>>>   register each component separately as a different client to
> >>> >>>>>>ensure
> >>> >>>>>>
> >>> >>>>>>   proper handling by the authorization server, unless the
> >>> >>>>>>authorization
> >>> >>>>>>   server provides other registration options to specify such
> >>> >>>>>>complex  clients.
> >>> >>>>>>
> >>> >>>>>>   Each component MAY have the same client_id, in which case
> >>> >>>>>>the server
> >>> >>>>>>
> >>> >>>>>>   judges the client type and the associated security context
> >>> >>>>>>based on
> >>> >>>>>>   the response_type parameter in the request.
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> Would it solve your problem, Breno?
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> Best,
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> =3Dnat
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> --
> >>> >>>>> --Breno
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>--
> >>> >>>>--Breno
> >>> >>>
> >>> >>
> >>> >>
> >>> >>
> >>> >>--
> >>> >>--Breno
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> --Breno
> >
> >
> >
> > --
> > --Breno
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
> Breno de Medeiros

From breno.demedeiros@gmail.com  Sat Mar 17 12:10:33 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5AA21F866B for ; Sat, 17 Mar 2012 12:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.776
X-Spam-Level: 
X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvAW6nI0ycBq for ; Sat, 17 Mar 2012 12:10:31 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D992521F864C for ; Sat, 17 Mar 2012 12:10:24 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so303402obb.31 for ; Sat, 17 Mar 2012 12:10:24 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5PDk8BDCbunWoxAZiv9w36qWXD5BXU2JcMLTWX8X4Ek=; b=D6pxmVxdH/uZobfijT6JsJhGbt/eBs3bNopXjiD07iFWdVmIMAbs41XnOscCBrkTqR zisddYYKZ+KTu89P6HeLmah7BaqclzYJ7qhbiLY7RPPI8gF79C/P/sVmlGtDikBH6O5E QBsNNU+JkRa/gakBxS9IzPy387XDHNPMYZFlkkYSc6EEumYJ7NTOhC7jc+xyquIgg2k7 IDgxske2c6dQAX6W0ZO05QXifSR7y6IxJUpqzva3+7HyaMCcsXjHUVVO8J1ocSK8x9+z T7mEEkrQPTCNtMyZivynk+NGXt47Gxcl1KPw/0Vy/uNqmKRbD1oDEeVo6tj4cykT+gmY WMFg==
MIME-Version: 1.0
Received: by 10.182.1.2 with SMTP id 2mr7061825obi.58.1332011424355; Sat, 17 Mar 2012 12:10:24 -0700 (PDT)
Sender: breno.demedeiros@gmail.com
Received: by 10.182.49.198 with HTTP; Sat, 17 Mar 2012 12:10:24 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:    <90C41DD21FB7C64BB94121FBBC2E723453AFF08AC2@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF08C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Sat, 17 Mar 2012 12:10:24 -0700
X-Google-Sender-Auth: QTuu9lidlAuMj-JrkZRxhv_O00Q
Message-ID: 
From: Breno 
To: Eran Hammer 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Mar 2012 19:10:33 -0000

That is much clearer. Thank you.

On Sat, Mar 17, 2012 at 9:17 AM, Eran Hammer  wrote:
> How about we phrase it the other way:
>
> A clients may be implemented as a distributed set of components, each wit=
h a different
> client type and security context (e.g. a distributed client with both a c=
onfidential
> server-based component and a public browser-based component). If the auth=
orization
> =A0server does not provide support for such clients, or does not provide =
guidance with regard
> to their registration, the client SHOULD register each component as a sep=
arate client.
>
> This does two thing: put the server's policy first instead of as the exce=
ption, and uses SHOULD instead of MUST which seems to be too strong for man=
y people.
>
> Better?
>
> EH
>
>
>> -----Original Message-----
>> From: breno.demedeiros@gmail.com
>> [mailto:breno.demedeiros@gmail.com] On Behalf Of Breno
>> Sent: Saturday, March 17, 2012 8:50 AM
>> To: Eran Hammer
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>
>> To summarize, I am weary of registration normative language that appears=
 to
>> disallow common practice implemented by servers to securely support mult=
i-
>> component applications. If these common practices will be non-compliant =
(or
>> at least it appears to be so on first reading by many different people w=
ith
>> detailed knowledge of the spec), isn't it incumbent on this spec to prov=
ide
>> guidance on _how_ different components of an application will interopera=
te
>> under different registration? At least for the very common case of a
>> webserver + browser component, the importance of which is already
>> enshrined in the spec by the definition of two response_types and flows?
>>
>> On Thu, Mar 15, 2012 at 3:54 PM, Breno de Medeiros 
>> wrote:
>> > On Thu, Mar 15, 2012 at 15:43, Eran Hammer 
>> wrote:
>> >> I don't know how to better explain myself. Forget about the text you
>> have issue with. Just answer this:
>> >>
>> >> Reading the specification (with that text removed), what happens when=
 a
>> hybrid client wants to register? What client type does it provide? How s=
hould
>> the server handle this case?
>> >
>> > In the example case of the webserver + browser-based client
>> > components, I think the server should just allow it. The browser does
>> > not need to expose the client_secret since it requires no
>> > authentication credentials. The webserver should use the client
>> > credentials acquired during registration to authenticate itself when
>> > using the code flow.
>> >
>> > It's more interesting when mobile applications and webserver want to
>> > share credentials. The mitigation strategy of limiting lifetime of
>> > tokens may not work in this case. In general the registration server
>> > should not allow the use of a single registration in this case. This
>> > case is different from the above in the sense that installed
>> > applications are typically _also_ using the 'code' flow, but from a
>> > different security context. A server could allow both clients to share
>> > the same registration information, but segregate the set of redirect
>> > URLs and tie the code to each security context and apply different
>> > client authentication requirements to each. Or the server could
>> > require separate client registration for each component.
>> >
>> >>
>> >> EH
>> >>
>> >>> -----Original Message-----
>> >>> From: Breno de Medeiros [mailto:breno@google.com]
>> >>> Sent: Thursday, March 15, 2012 2:12 PM
>> >>> To: Eran Hammer
>> >>> Cc: Nat Sakimura; OAuth WG
>> >>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>> >>>
>> >>> On Thu, Mar 15, 2012 at 13:13, Eran Hammer 
>> >>> wrote:
>> >>> > Ok. That's much better than my guess that you wanted to drop all
>> >>> > the registration text from the specification.
>> >>> >
>> >>> > What I'm looking for is a simple text that answers the question:
>> >>> >
>> >>> > "What to do if my client isn't simply public or confidential?"
>> >>> >
>> >>> > If we just drop the current text, the answer is implicitly "you
>> >>> > can't have such a client" because there is no way to register a
>> >>> > client of any other type.
>> >>> >
>> >>> > So let's try this again, and focus exclusively on answering this q=
uestion.
>> >>> > My text takes a position which is, "you can't - unless". Your
>> >>> > suggestion is more of a vague discussion of the topic. I'd like to
>> >>> > see clear, normative answer to this question.
>> >>>
>> >>> The current version is normative but far from clear. In fact, the
>> >>> most natural interpretation is that it bans normal practice and
>> >>> throws away the work that was done in defining different flow types =
to
>> support normal practice.
>> >>>
>> >>> 1. I don't see the need or desirability to put normative language on
>> >>> registration practices.
>> >>> 2. The contents of said normative language are harmful.
>> >>>
>> >>> I suggest two alternatives:
>> >>>
>> >>> 1. Remove the language.
>> >>> 2. Substitute the language by non-normative informative discussion.
>> >>>
>> >>> You can also do other things, like introduce normative language that
>> >>> makes sense. But I have not yet seen proposed language that would be
>> acceptable.
>> >>>
>> >>> >
>> >>> > EH
>> >>> >
>> >>> >
>> >>> > On 3/15/12 12:30 PM, "Breno de Medeiros" 
>> wrote:
>> >>> >
>> >>> >>I am proposing the entire removal of:
>> >>> >>
>> >>> >>"A client application consisting of multiple components, each with
>> >>> >>its own client type (e.g. a distributed client with both a
>> >>> >>confidential server-based component and a public browser-based
>> >>> >>component), MUST register each component separately as a different
>> >>> >>client to ensure proper handling by the authorization server."
>> >>> >>
>> >>> >>In particular the example of a server-side component versus
>> >>> >>browser-based components is particularly unhelpful since it
>> >>> >>violates the entire principle of why two response_type 'code' and
>> >>> >>'token' were defined, and how OAuth2 is typically implemented.
>> >>> >>That's when I claim this normative language is redefining the prot=
ocol.
>> >>> >>
>> >>> >>
>> >>> >>On Thu, Mar 15, 2012 at 12:13, Eran Hammer 
>> >>> wrote:
>> >>> >>> Which text in -25 are you proposing we remove exactly? I can't
>> >>> >>>judge the =A0text below without the full context of where and how
>> >>> >>>it is proposed in the =A0current document.
>> >>> >>>
>> >>> >>> Also, you are ignoring my detailed analysis of the current
>> >>> >>>facts. We have =A0two client types and the issue here is what to =
do
>> >>> >>>with other, undefined =A0types.
>> >>> >>>
>> >>> >>> EH
>> >>> >>>
>> >>> >>>
>> >>> >>> On 3/15/12 11:54 AM, "Breno de Medeiros" 
>> >>> wrote:
>> >>> >>>
>> >>> >>>>My proposal is to remove any reference to registration (which is
>> >>> >>>>a red herring and has raised all the problems we refer here) and
>> >>> >>>>refer to client authentication instead.
>> >>> >>>>
>> >>> >>>>Proposal:
>> >>> >>>>
>> >>> >>>>"Clients may be implemented as a distributed set of components
>> >>> >>>>that run in different security contexts. For instance, a single
>> >>> >>>>client may include a webserver component and a script component
>> >>> >>>>in a browser. It is not appropriate for the different components
>> >>> >>>>to utilize the same client authentication mechanisms, since
>> >>> >>>>client authentication credentials that are held securely in one
>> >>> >>>>context cannot be deployed securely in another.
>> >>> >>>>
>> >>> >>>>Servers MUST mitigate security threats from client components
>> >>> >>>>that cannot hold client credentials as securely by
>> >>> >>>>distinguishing them from client components that can. Example of
>> suitable measures are:
>> >>> >>>>
>> >>> >>>>- Requiring separate registration of components such as web
>> >>> >>>>server and a mobile application.
>> >>> >>>>- Restricting the time validity of tokens issued to clients that
>> >>> >>>>hold no authentication credentials, such as browser script-based
>> >>> >>>>components."
>> >>> >>>>
>> >>> >>>>Please don't truncate explanations in the interest of space if
>> >>> >>>>the resulting text is confusing and possibly misleading. Better
>> >>> >>>>to say nothing instead.
>> >>> >>>>
>> >>> >>>>On Thu, Mar 15, 2012 at 11:32, Eran Hammer
>> 
>> >>> wrote:
>> >>> >>>>> Here are the facts:
>> >>> >>>>>
>> >>> >>>>> The authorization server must know the client type in order to
>> >>> >>>>>enforce many =A0of the requirements in the specification.
>> >>> >>>>> The requirement to provide a client type is not decorated with
>> >>> >>>>>a MUST or =A0SHALL but that is implied.
>> >>> >>>>> The specification only defines two client types: public and
>> >>> >>>>>confidential.
>> >>> >>>>> There is no client type defined for a hybrid client.
>> >>> >>>>> The specification needs to address the very common use case of
>> >>> >>>>>clients with =A0both public and private components.
>> >>> >>>>>
>> >>> >>>>> I don't want to discuss in the specification how client
>> >>> >>>>>identifiers are =A0provisioned, nor do I want to discuss the
>> >>> >>>>>potential binding of response =A0types to client types. But we =
do
>> >>> >>>>>need to provide some guidance to clients =A0and authorization
>> >>> >>>>>servers what to do with clients that do not fit the =A0current
>> >>> >>>>>type definitions.
>> >>> >>>>>
>> >>> >>>>> It is far too late for us to define a new client type, along
>> >>> >>>>>with all the =A0security considerations that such type imply. O=
ur
>> >>> >>>>>entire security =A0consideration section and protocol design ar=
e
>> >>> >>>>>based on have a well defined =A0client type.
>> >>> >>>>>
>> >>> >>>>> Requiring separate registration for each component is the most
>> >>> >>>>> straight-forward solution. Allowing the authorization server
>> >>> >>>>> to offer alternatives is the backdoor to enable extensibility.
>> >>> >>>>>
>> >>> >>>>> Within these constraints, I am open to other prose or creative
>> >>> >>>>>solutions.
>> >>> >>>>> But the add-ons proposed are all ugly hacks. They clarify
>> >>> >>>>>specific questions =A0raised which I do not believe represent t=
he
>> >>> >>>>>core confusion here which is =A0what is the right way to handle
>> >>> >>>>>hybrid clients.
>> >>> >>>>>
>> >>> >>>>> The best way to move forward is to take a minute and ask the
>> >>> >>>>>group to share =A0how they handle such cases or how they think
>> >>> >>>>>they should be handled.
>> >>> >>>>>Based
>> >>> >>>>> on that we can come up with a clear solution.
>> >>> >>>>>
>> >>> >>>>> EH
>> >>> >>>>>
>> >>> >>>>> From: Breno de Medeiros 
>> >>> >>>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
>> >>> >>>>> To: Eran Hammer-Lahav 
>> >>> >>>>> Cc: Nat Sakimura , OAuth WG
>> >>> 
>> >>> >>>>>
>> >>> >>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev.
>> >>> >>>>> 23
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer
>> >>> >>>>>
>> >>> >>>>>wrote:
>> >>> >>>>>>
>> >>> >>>>>> This add-on is unnecessary. It already says the authorization
>> >>> >>>>>>server can =A0handle it any way it wants. The fact that other
>> >>> >>>>>>registration options are =A0possible clearly covers the client
>> >>> >>>>>>identifier reuse case. As for the =A0response type, that=B9s n=
ot
>> >>> >>>>>>an issue but more of an optimization for an edge =A0case raise=
d.
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> It still feels like a horse by committee to me. "unless the
>> >>> >>>>>authorization server provides other registration options to
>> >>> >>>>>specify such =A0complex clients." seems a very round about way =
to
>> >>> >>>>>say that the core spec =A0already provides for such arrangement=
s
>> >>> >>>>>in the most common scenario. It is a =A0bit of a stretch to say
>> >>> >>>>>that the server provides "other registration =A0options" by
>> >>> >>>>>simply following strategy already laid out in the spec.
>> >>> >>>>>
>> >>> >>>>> In particular, I feel that this wording will be harmful to
>> >>> >>>>>register extended =A0behavior, e.g., alternative response_types
>> >>> >>>>>by leading to fruitless =A0conversations about spec compliance =
in
>> >>> >>>>>the absence of real security risks.
>> >>> >>>>>
>> >>> >>>>> I do not believe the current text is the best representation
>> >>> >>>>>of the spirit =A0in which the spec was written (in particular t=
he
>> >>> >>>>>effort to specify two flows =A0in detail to deal with precisely
>> >>> >>>>>this issue) and possibly lead to harmful =A0future interpretati=
on.
>> >>> >>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> EH
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
>> bounces@ietf.org]
>> >>> >>>>>>On Behalf Of =A0Nat Sakimura
>> >>> >>>>>> Sent: Thursday, March 15, 2012 2:04 AM
>> >>> >>>>>> To: Breno de Medeiros; OAuth WG
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev.
>> >>> >>>>>> 23
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> So, Eran's first proposal:
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> =A0 A client application consisting of multiple components,
>> >>> >>>>>>each with its
>> >>> >>>>>> =A0 own client type (e.g. a distributed client with both a
>> >>> >>>>>>confidential
>> >>> >>>>>> =A0 server-based component and a public browser-based
>> >>> >>>>>>component), MUST
>> >>> >>>>>> =A0 register each component separately as a different client =
to
>> >>> >>>>>>ensure
>> >>> >>>>>>
>> >>> >>>>>> =A0 proper handling by the authorization server, unless the
>> >>> >>>>>>authorization
>> >>> >>>>>> =A0 server provides other registration options to specify suc=
h
>> >>> >>>>>>complex =A0clients.
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> kind of meets my concern. There seems to be another issue
>> >>> >>>>>>around the =A0usefulness of return_type in such case raised by
>> >>> >>>>>>Breno, and if I understand =A0it correctly, Eran's answer was
>> >>> >>>>>>that these separate components may have the =A0same client_id
>> so
>> >>> >>>>>>that return_type is a valid parameter to be sent at the =A0req=
uest.
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> So, to clarify these, perhaps changing the above text
>> >>> >>>>>> slightly to the following solves the problem?
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> =A0 A client application consisting of multiple components,
>> >>> >>>>>>each with its
>> >>> >>>>>> =A0 own client type (e.g. a distributed client with both a
>> >>> >>>>>>confidential
>> >>> >>>>>> =A0 server-based component and a public browser-based
>> >>> >>>>>>component), MUST
>> >>> >>>>>> =A0 register each component separately as a different client =
to
>> >>> >>>>>>ensure
>> >>> >>>>>>
>> >>> >>>>>> =A0 proper handling by the authorization server, unless the
>> >>> >>>>>>authorization
>> >>> >>>>>> =A0 server provides other registration options to specify suc=
h
>> >>> >>>>>>complex =A0clients.
>> >>> >>>>>>
>> >>> >>>>>> =A0 Each component MAY have the same client_id, in which case
>> >>> >>>>>>the server
>> >>> >>>>>>
>> >>> >>>>>> =A0 judges the client type and the associated security contex=
t
>> >>> >>>>>>based on
>> >>> >>>>>> =A0 the response_type parameter in the request.
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> Would it solve your problem, Breno?
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> Best,
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> =3Dnat
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> --
>> >>> >>>>> --Breno
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>--
>> >>> >>>>--Breno
>> >>> >>>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>--
>> >>> >>--Breno
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> --Breno
>> >
>> >
>> >
>> > --
>> > --Breno
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> --
>> Breno de Medeiros
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--=20
Breno de Medeiros

From eran@hueniverse.com  Sat Mar 17 14:43:32 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB49D21F8647 for ; Sat, 17 Mar 2012 14:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCCCmuShba7R for ; Sat, 17 Mar 2012 14:43:31 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 4A64A21F8623 for ; Sat, 17 Mar 2012 14:43:31 -0700 (PDT)
Received: (qmail 6184 invoked from network); 17 Mar 2012 21:43:30 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Mar 2012 21:43:30 -0000
Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id mljW1i00110TkE001ljWse; Sat, 17 Mar 2012 14:43:30 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Sat, 17 Mar 2012 14:43:30 -0700
From: Eran Hammer 
To: Mike Jones , "'Nat Sakimura (sakimura@gmail.com)'" 
Date: Sat, 17 Mar 2012 14:43:17 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0EcZv/vnX/z0xoSZKzNFuHaHYn5QAFUocw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08C24@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:    <90C41DD21FB7C64BB94121FBBC2E723453AFF08AC2@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF08C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Mar 2012 21:43:32 -0000

Mike, Nat,

Does the new text work for you?

EH

> -----Original Message-----
> From: breno.demedeiros@gmail.com
> [mailto:breno.demedeiros@gmail.com] On Behalf Of Breno
> Sent: Saturday, March 17, 2012 12:10 PM
> To: Eran Hammer
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>
> That is much clearer. Thank you.
>
> On Sat, Mar 17, 2012 at 9:17 AM, Eran Hammer 
> wrote:
> > How about we phrase it the other way:
> >
> > A clients may be implemented as a distributed set of components, each
> > with a different client type and security context (e.g. a distributed
> > client with both a confidential server-based component and a public
> > browser-based component). If the authorization
> >  server does not provide support for such clients, or does not provide
> > guidance with regard to their registration, the client SHOULD register =
each
> component as a separate client.
> >
> > This does two thing: put the server's policy first instead of as the ex=
ception,
> and uses SHOULD instead of MUST which seems to be too strong for many
> people.
> >
> > Better?
> >
> > EH
> >
> >
> >> -----Original Message-----
> >> From: breno.demedeiros@gmail.com
> >> [mailto:breno.demedeiros@gmail.com] On Behalf Of Breno
> >> Sent: Saturday, March 17, 2012 8:50 AM
> >> To: Eran Hammer
> >> Cc: OAuth WG
> >> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >>
> >> To summarize, I am weary of registration normative language that
> >> appears to disallow common practice implemented by servers to
> >> securely support multi- component applications. If these common
> >> practices will be non-compliant (or at least it appears to be so on
> >> first reading by many different people with detailed knowledge of the
> >> spec), isn't it incumbent on this spec to provide guidance on _how_
> >> different components of an application will interoperate under
> >> different registration? At least for the very common case of a
> >> webserver + browser component, the importance of which is already
> enshrined in the spec by the definition of two response_types and flows?
> >>
> >> On Thu, Mar 15, 2012 at 3:54 PM, Breno de Medeiros
> 
> >> wrote:
> >> > On Thu, Mar 15, 2012 at 15:43, Eran Hammer 
> >> wrote:
> >> >> I don't know how to better explain myself. Forget about the text
> >> >> you
> >> have issue with. Just answer this:
> >> >>
> >> >> Reading the specification (with that text removed), what happens
> >> >> when a
> >> hybrid client wants to register? What client type does it provide?
> >> How should the server handle this case?
> >> >
> >> > In the example case of the webserver + browser-based client
> >> > components, I think the server should just allow it. The browser
> >> > does not need to expose the client_secret since it requires no
> >> > authentication credentials. The webserver should use the client
> >> > credentials acquired during registration to authenticate itself
> >> > when using the code flow.
> >> >
> >> > It's more interesting when mobile applications and webserver want
> >> > to share credentials. The mitigation strategy of limiting lifetime
> >> > of tokens may not work in this case. In general the registration
> >> > server should not allow the use of a single registration in this
> >> > case. This case is different from the above in the sense that
> >> > installed applications are typically _also_ using the 'code' flow,
> >> > but from a different security context. A server could allow both
> >> > clients to share the same registration information, but segregate
> >> > the set of redirect URLs and tie the code to each security context
> >> > and apply different client authentication requirements to each. Or
> >> > the server could require separate client registration for each
> component.
> >> >
> >> >>
> >> >> EH
> >> >>
> >> >>> -----Original Message-----
> >> >>> From: Breno de Medeiros [mailto:breno@google.com]
> >> >>> Sent: Thursday, March 15, 2012 2:12 PM
> >> >>> To: Eran Hammer
> >> >>> Cc: Nat Sakimura; OAuth WG
> >> >>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >> >>>
> >> >>> On Thu, Mar 15, 2012 at 13:13, Eran Hammer
> 
> >> >>> wrote:
> >> >>> > Ok. That's much better than my guess that you wanted to drop
> >> >>> > all the registration text from the specification.
> >> >>> >
> >> >>> > What I'm looking for is a simple text that answers the question:
> >> >>> >
> >> >>> > "What to do if my client isn't simply public or confidential?"
> >> >>> >
> >> >>> > If we just drop the current text, the answer is implicitly "you
> >> >>> > can't have such a client" because there is no way to register a
> >> >>> > client of any other type.
> >> >>> >
> >> >>> > So let's try this again, and focus exclusively on answering this
> question.
> >> >>> > My text takes a position which is, "you can't - unless". Your
> >> >>> > suggestion is more of a vague discussion of the topic. I'd like
> >> >>> > to see clear, normative answer to this question.
> >> >>>
> >> >>> The current version is normative but far from clear. In fact, the
> >> >>> most natural interpretation is that it bans normal practice and
> >> >>> throws away the work that was done in defining different flow
> >> >>> types to
> >> support normal practice.
> >> >>>
> >> >>> 1. I don't see the need or desirability to put normative language
> >> >>> on registration practices.
> >> >>> 2. The contents of said normative language are harmful.
> >> >>>
> >> >>> I suggest two alternatives:
> >> >>>
> >> >>> 1. Remove the language.
> >> >>> 2. Substitute the language by non-normative informative discussion=
.
> >> >>>
> >> >>> You can also do other things, like introduce normative language
> >> >>> that makes sense. But I have not yet seen proposed language that
> >> >>> would be
> >> acceptable.
> >> >>>
> >> >>> >
> >> >>> > EH
> >> >>> >
> >> >>> >
> >> >>> > On 3/15/12 12:30 PM, "Breno de Medeiros" 
> >> wrote:
> >> >>> >
> >> >>> >>I am proposing the entire removal of:
> >> >>> >>
> >> >>> >>"A client application consisting of multiple components, each
> >> >>> >>with its own client type (e.g. a distributed client with both a
> >> >>> >>confidential server-based component and a public browser-based
> >> >>> >>component), MUST register each component separately as a
> >> >>> >>different client to ensure proper handling by the authorization
> server."
> >> >>> >>
> >> >>> >>In particular the example of a server-side component versus
> >> >>> >>browser-based components is particularly unhelpful since it
> >> >>> >>violates the entire principle of why two response_type 'code'
> >> >>> >>and 'token' were defined, and how OAuth2 is typically
> implemented.
> >> >>> >>That's when I claim this normative language is redefining the
> protocol.
> >> >>> >>
> >> >>> >>
> >> >>> >>On Thu, Mar 15, 2012 at 12:13, Eran Hammer
> >> >>> >>
> >> >>> wrote:
> >> >>> >>> Which text in -25 are you proposing we remove exactly? I
> >> >>> >>>can't judge the  text below without the full context of where
> >> >>> >>>and how it is proposed in the  current document.
> >> >>> >>>
> >> >>> >>> Also, you are ignoring my detailed analysis of the current
> >> >>> >>>facts. We have  two client types and the issue here is what to
> >> >>> >>>do with other, undefined  types.
> >> >>> >>>
> >> >>> >>> EH
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> On 3/15/12 11:54 AM, "Breno de Medeiros"
> 
> >> >>> wrote:
> >> >>> >>>
> >> >>> >>>>My proposal is to remove any reference to registration (which
> >> >>> >>>>is a red herring and has raised all the problems we refer
> >> >>> >>>>here) and refer to client authentication instead.
> >> >>> >>>>
> >> >>> >>>>Proposal:
> >> >>> >>>>
> >> >>> >>>>"Clients may be implemented as a distributed set of
> >> >>> >>>>components that run in different security contexts. For
> >> >>> >>>>instance, a single client may include a webserver component
> >> >>> >>>>and a script component in a browser. It is not appropriate
> >> >>> >>>>for the different components to utilize the same client
> >> >>> >>>>authentication mechanisms, since client authentication
> >> >>> >>>>credentials that are held securely in one context cannot be
> deployed securely in another.
> >> >>> >>>>
> >> >>> >>>>Servers MUST mitigate security threats from client components
> >> >>> >>>>that cannot hold client credentials as securely by
> >> >>> >>>>distinguishing them from client components that can. Example
> >> >>> >>>>of
> >> suitable measures are:
> >> >>> >>>>
> >> >>> >>>>- Requiring separate registration of components such as web
> >> >>> >>>>server and a mobile application.
> >> >>> >>>>- Restricting the time validity of tokens issued to clients
> >> >>> >>>>that hold no authentication credentials, such as browser
> >> >>> >>>>script-based components."
> >> >>> >>>>
> >> >>> >>>>Please don't truncate explanations in the interest of space
> >> >>> >>>>if the resulting text is confusing and possibly misleading.
> >> >>> >>>>Better to say nothing instead.
> >> >>> >>>>
> >> >>> >>>>On Thu, Mar 15, 2012 at 11:32, Eran Hammer
> >> 
> >> >>> wrote:
> >> >>> >>>>> Here are the facts:
> >> >>> >>>>>
> >> >>> >>>>> The authorization server must know the client type in order
> >> >>> >>>>>to enforce many  of the requirements in the specification.
> >> >>> >>>>> The requirement to provide a client type is not decorated
> >> >>> >>>>>with a MUST or  SHALL but that is implied.
> >> >>> >>>>> The specification only defines two client types: public and
> >> >>> >>>>>confidential.
> >> >>> >>>>> There is no client type defined for a hybrid client.
> >> >>> >>>>> The specification needs to address the very common use case
> >> >>> >>>>>of clients with  both public and private components.
> >> >>> >>>>>
> >> >>> >>>>> I don't want to discuss in the specification how client
> >> >>> >>>>>identifiers are  provisioned, nor do I want to discuss the
> >> >>> >>>>>potential binding of response  types to client types. But we
> >> >>> >>>>>do need to provide some guidance to clients  and
> >> >>> >>>>>authorization servers what to do with clients that do not
> >> >>> >>>>>fit the  current type definitions.
> >> >>> >>>>>
> >> >>> >>>>> It is far too late for us to define a new client type,
> >> >>> >>>>>along with all the  security considerations that such type
> >> >>> >>>>>imply. Our entire security  consideration section and
> >> >>> >>>>>protocol design are based on have a well defined  client type=
.
> >> >>> >>>>>
> >> >>> >>>>> Requiring separate registration for each component is the
> >> >>> >>>>> most straight-forward solution. Allowing the authorization
> >> >>> >>>>> server to offer alternatives is the backdoor to enable
> extensibility.
> >> >>> >>>>>
> >> >>> >>>>> Within these constraints, I am open to other prose or
> >> >>> >>>>>creative solutions.
> >> >>> >>>>> But the add-ons proposed are all ugly hacks. They clarify
> >> >>> >>>>>specific questions  raised which I do not believe represent
> >> >>> >>>>>the core confusion here which is  what is the right way to
> >> >>> >>>>>handle hybrid clients.
> >> >>> >>>>>
> >> >>> >>>>> The best way to move forward is to take a minute and ask
> >> >>> >>>>>the group to share  how they handle such cases or how they
> >> >>> >>>>>think they should be handled.
> >> >>> >>>>>Based
> >> >>> >>>>> on that we can come up with a clear solution.
> >> >>> >>>>>
> >> >>> >>>>> EH
> >> >>> >>>>>
> >> >>> >>>>> From: Breno de Medeiros 
> >> >>> >>>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
> >> >>> >>>>> To: Eran Hammer-Lahav 
> >> >>> >>>>> Cc: Nat Sakimura , OAuth WG
> >> >>> 
> >> >>> >>>>>
> >> >>> >>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
> rev.
> >> >>> >>>>> 23
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer
> >> >>> >>>>>
> >> >>> >>>>>wrote:
> >> >>> >>>>>>
> >> >>> >>>>>> This add-on is unnecessary. It already says the
> >> >>> >>>>>>authorization server can  handle it any way it wants. The
> >> >>> >>>>>>fact that other registration options are  possible clearly
> >> >>> >>>>>>covers the client identifier reuse case. As for the
> >> >>> >>>>>>response type, that=B9s not an issue but more of an
> optimization for an edge  case raised.
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>> It still feels like a horse by committee to me. "unless the
> >> >>> >>>>>authorization server provides other registration options to
> >> >>> >>>>>specify such  complex clients." seems a very round about way
> >> >>> >>>>>to say that the core spec  already provides for such
> >> >>> >>>>>arrangements in the most common scenario. It is a  bit of a
> >> >>> >>>>>stretch to say that the server provides "other registration
> >> >>> >>>>>options" by simply following strategy already laid out in the
> spec.
> >> >>> >>>>>
> >> >>> >>>>> In particular, I feel that this wording will be harmful to
> >> >>> >>>>>register extended  behavior, e.g., alternative
> >> >>> >>>>>response_types by leading to fruitless  conversations about
> >> >>> >>>>>spec compliance in the absence of real security risks.
> >> >>> >>>>>
> >> >>> >>>>> I do not believe the current text is the best
> >> >>> >>>>>representation of the spirit  in which the spec was written
> >> >>> >>>>>(in particular the effort to specify two flows  in detail to
> >> >>> >>>>>deal with precisely this issue) and possibly lead to
> harmful  future interpretation.
> >> >>> >>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> EH
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
> >> bounces@ietf.org]
> >> >>> >>>>>>On Behalf Of  Nat Sakimura
> >> >>> >>>>>> Sent: Thursday, March 15, 2012 2:04 AM
> >> >>> >>>>>> To: Breno de Medeiros; OAuth WG
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
> rev.
> >> >>> >>>>>> 23
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> So, Eran's first proposal:
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>   A client application consisting of multiple components,
> >> >>> >>>>>>each with its
> >> >>> >>>>>>   own client type (e.g. a distributed client with both a
> >> >>> >>>>>>confidential
> >> >>> >>>>>>   server-based component and a public browser-based
> >> >>> >>>>>>component), MUST
> >> >>> >>>>>>   register each component separately as a different client
> >> >>> >>>>>>to ensure
> >> >>> >>>>>>
> >> >>> >>>>>>   proper handling by the authorization server, unless the
> >> >>> >>>>>>authorization
> >> >>> >>>>>>   server provides other registration options to specify
> >> >>> >>>>>>such complex  clients.
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> kind of meets my concern. There seems to be another issue
> >> >>> >>>>>>around the  usefulness of return_type in such case raised
> >> >>> >>>>>>by Breno, and if I understand  it correctly, Eran's answer
> >> >>> >>>>>>was that these separate components may have the  same
> >> >>> >>>>>>client_id
> >> so
> >> >>> >>>>>>that return_type is a valid parameter to be sent at
> the  request.
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> So, to clarify these, perhaps changing the above text
> >> >>> >>>>>> slightly to the following solves the problem?
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>   A client application consisting of multiple components,
> >> >>> >>>>>>each with its
> >> >>> >>>>>>   own client type (e.g. a distributed client with both a
> >> >>> >>>>>>confidential
> >> >>> >>>>>>   server-based component and a public browser-based
> >> >>> >>>>>>component), MUST
> >> >>> >>>>>>   register each component separately as a different client
> >> >>> >>>>>>to ensure
> >> >>> >>>>>>
> >> >>> >>>>>>   proper handling by the authorization server, unless the
> >> >>> >>>>>>authorization
> >> >>> >>>>>>   server provides other registration options to specify
> >> >>> >>>>>>such complex  clients.
> >> >>> >>>>>>
> >> >>> >>>>>>   Each component MAY have the same client_id, in which
> >> >>> >>>>>>case the server
> >> >>> >>>>>>
> >> >>> >>>>>>   judges the client type and the associated security
> >> >>> >>>>>>context based on
> >> >>> >>>>>>   the response_type parameter in the request.
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> Would it solve your problem, Breno?
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> Best,
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> =3Dnat
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>> --
> >> >>> >>>>> --Breno
> >> >>> >>>>
> >> >>> >>>>
> >> >>> >>>>
> >> >>> >>>>--
> >> >>> >>>>--Breno
> >> >>> >>>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>--
> >> >>> >>--Breno
> >> >>> >
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> --Breno
> >> >
> >> >
> >> >
> >> > --
> >> > --Breno
> >> > _______________________________________________
> >> > OAuth mailing list
> >> > OAuth@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >>
> >> --
> >> Breno de Medeiros
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
> Breno de Medeiros

From eran@hueniverse.com  Sat Mar 17 16:11:43 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB2621F8666 for ; Sat, 17 Mar 2012 16:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level: 
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.231,  BAYES_00=-2.599, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6wGFYZ5cfXT for ; Sat, 17 Mar 2012 16:11:42 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 83EAA21F85DD for ; Sat, 17 Mar 2012 16:11:42 -0700 (PDT)
Received: (qmail 20639 invoked from network); 17 Mar 2012 23:11:41 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Mar 2012 23:11:41 -0000
Received: from P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id mnBf1i0010RWb6o01nBhV2; Sat, 17 Mar 2012 16:11:41 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 17 Mar 2012 09:25:35 -0700
From: Eran Hammer 
To: John Bradley 
Date: Sat, 17 Mar 2012 09:25:23 -0700
Thread-Topic: [OAUTH-WG] Last Call:  (The OAuth 2.0	Authorization Protocol: Bearer Tokens) to Proposed Standard
Thread-Index: Acz9Rmgmn7QNqLoOT1OzbE+KGkQxzgHFBRcA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08C1D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4F1F3D84.1030300@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723453AAB9682E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7D4DB9C9-7194-42A0-A573-4243FE27E512@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723453AFCD4072@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Julian Reschke , "oauth@ietf.org" , "ietf@ietf.org" , The IESG 
Subject: Re: [OAUTH-WG] Last Call:  (The OAuth 2.0	Authorization Protocol: Bearer Tokens) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Mar 2012 23:11:43 -0000

I am treating this issue as closed, unless someone wants to proposed langua=
ge changes based on John's analysis below.

EH

> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Thursday, March 08, 2012 8:13 AM
> To: Eran Hammer
> Cc: Julian Reschke; ietf@ietf.org; The IESG; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Last Call:  (T=
he
> OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
>=20
> Thanks that is better.
>=20
> Without knowing the lifetime of the token these are per guess probabiliti=
es.
> Effectively 128bits for a random value and 256bits for a HMAC or other
> signature.
>=20
> For tokens intended for handling by end-users it may be useful to give so=
me
> advice.
> In general you don't want an attacker having more than a one in 2^14 chan=
ce
> of guessing a valid code for a AS during the lifetime of the code(NIST Lo=
A 2).
>=20
> For a code randomly generated from a 94 character code set 4 characters
> gets you 26.3 bits of entropy.
> 5 characters requires limiting an attacker to 2^12.3 (5,042) guesses per =
token
> lifetime.
>=20
> For a code randomly generated from a 94 character code set 5 characters
> gets you 32.9 bits of entropy.
> 5 characters requires limiting an attacker to 2^18.9 (489,178) guesses pe=
r
> token lifetime.
>=20
> If the token is single use and the client uses it right away that is easy=
,
> however in a worst case scenario the token might live 10min?
> That would be 8.4 attempts per second as a max for a 4 character code or =
815
> per second for 5 characters.
>=20
> That is all way too much to explain however I would recommend as a genera=
l
> rule:
>=20
> Credentials intended for handling by end users SHOULD be a minimum of 5
> randomly generated charters from a set of 94 or otherwise contain a
> minimum entropy of 2^32.9.
>=20
> That is probably high enough that the AS will notice an attack,  lower en=
tropy
> may pass under the radar.
> Also the chances of an attacker being successful go up proportionally to =
the
> number simultaneous codes in flight at any point (it becomes a non target=
ed
> attack).
>=20
> It isn't something that I will loose sleep over,  It gives me something e=
lse to
> profile:)
>=20
> Thanks
> John B.
>=20
> On 2012-03-07, at 8:18 PM, Eran Hammer wrote:
>=20
> > New text:
> >
> >          The probability of an attacker guessing generated tokens (and =
other
> credentials not
> >          intended for handling by end-users) MUST be less than or equal=
 to
> 2^(-128) and SHOULD be
> >          less than or equal to 2^(-160).
> >
> > Removed reference to RFC 1750.
> >
> > EH
> >
> >> -----Original Message-----
> >> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >> Sent: Monday, February 06, 2012 5:07 PM
> >> To: Eran Hammer
> >> Cc: Julian Reschke; ietf@ietf.org; The IESG; oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] Last Call: 
> (The
> >> OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
> >>
> >> RE new text in Draft 23
> >>
> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-10.10
> >>
> >> Generated tokens and other credentials not intended for handling by
> >>   end-users MUST be constructed from a cryptographically strong random
> >>   or pseudo-random number sequence ([RFC1750]) generated by the
> >>   authorization server.
> >>
> >> Given that many implementations may elect to use signed tokens, such a=
s
> >> SAML or JWT (JOSE) this should not be a MUST.
> >>
> >> Giving people sensible defaults such as the probability of an attacker
> >> guessing a valid access token for the protected resource should be les=
s
> than
> >> 2^(-128).
> >>
> >> The probability of generating hash colisions randomly is a odd metric,=
  2^(-
> >> 128) for a SHA256 as I recall.
> >> Many factors play into what is secure, token lifetime etc.
> >>
> >> I don't mind some reasonable defaults but adding a requirement for
> >> unstructured tokens is a bit much.
> >>
> >> Regards
> >> John B.
> >>
> >>
> >


From Michael.Jones@microsoft.com  Sat Mar 17 16:28:25 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B0F21F8609 for ; Sat, 17 Mar 2012 16:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.844
X-Spam-Level: 
X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmwY+zt+3PVc for ; Sat, 17 Mar 2012 16:28:24 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id A1A5C21F85FF for ; Sat, 17 Mar 2012 16:28:23 -0700 (PDT)
Received: from mail28-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Sat, 17 Mar 2012 23:28:20 +0000
Received: from mail28-va3 (localhost [127.0.0.1])	by mail28-va3-R.bigfish.com (Postfix) with ESMTP id 89C414807BC; Sat, 17 Mar 2012 23:28:20 +0000 (UTC)
X-SpamScore: -46
X-BigFish: VS-46(zzbb2dI9371I542M1432N98dK1419M148cMzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail28-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail28-va3 (localhost.localdomain [127.0.0.1]) by mail28-va3 (MessageSwitch) id 1332026897985595_25893; Sat, 17 Mar 2012 23:28:17 +0000 (UTC)
Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.251])	by mail28-va3.bigfish.com (Postfix) with ESMTP id E63C42200F0; Sat, 17 Mar 2012 23:28:17 +0000 (UTC)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 17 Mar 2012 23:28:14 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0283.004; Sat, 17 Mar 2012 23:28:14 +0000
From: Mike Jones 
To: Eran Hammer , "'Nat Sakimura (sakimura@gmail.com)'" 
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: AQHNAgMKtRI52qb7tE6+kmeeW24qnZZqBiQAgAACNICAAA7JAIAABA0AgAADMYCAAACtcIAABZMAgAAVJQCAAAHFAIAAAp4AgAAE2YCAAAAhgIAAzdQAgABfgQCAACSSgIAAGvAAgAAF/oCAAAVjgIAABKqAgAAMGYCAABBtAIAAGYqAgAADHgCAAq4fAIAAB7GAgAAwLgCAACq3gIAAHR5A
Date: Sat, 17 Mar 2012 23:28:13 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366422F55@TK5EX14MBXC284.redmond.corp.microsoft.com>
References:    <90C41DD21FB7C64BB94121FBBC2E723453AFF08AC2@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF08C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08C24@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08C24@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Mar 2012 23:28:25 -0000

Much better.  Thanks for working with Breno on the new wording.

				-- Mike

-----Original Message-----
From: Eran Hammer [mailto:eran@hueniverse.com]=20
Sent: Saturday, March 17, 2012 2:43 PM
To: Mike Jones; 'Nat Sakimura (sakimura@gmail.com)'
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

Mike, Nat,

Does the new text work for you?

EH

> -----Original Message-----
> From: breno.demedeiros@gmail.com
> [mailto:breno.demedeiros@gmail.com] On Behalf Of Breno
> Sent: Saturday, March 17, 2012 12:10 PM
> To: Eran Hammer
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>
> That is much clearer. Thank you.
>
> On Sat, Mar 17, 2012 at 9:17 AM, Eran Hammer 
> wrote:
> > How about we phrase it the other way:
> >
> > A clients may be implemented as a distributed set of components,=20
> > each with a different client type and security context (e.g. a=20
> > distributed client with both a confidential server-based component=20
> > and a public browser-based component). If the authorization  server=20
> > does not provide support for such clients, or does not provide=20
> > guidance with regard to their registration, the client SHOULD=20
> > register each
> component as a separate client.
> >
> > This does two thing: put the server's policy first instead of as the=20
> > exception,
> and uses SHOULD instead of MUST which seems to be too strong for many=20
> people.
> >
> > Better?
> >
> > EH
> >
> >
> >> -----Original Message-----
> >> From: breno.demedeiros@gmail.com
> >> [mailto:breno.demedeiros@gmail.com] On Behalf Of Breno
> >> Sent: Saturday, March 17, 2012 8:50 AM
> >> To: Eran Hammer
> >> Cc: OAuth WG
> >> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >>
> >> To summarize, I am weary of registration normative language that=20
> >> appears to disallow common practice implemented by servers to=20
> >> securely support multi- component applications. If these common=20
> >> practices will be non-compliant (or at least it appears to be so on=20
> >> first reading by many different people with detailed knowledge of=20
> >> the spec), isn't it incumbent on this spec to provide guidance on=20
> >> _how_ different components of an application will interoperate=20
> >> under different registration? At least for the very common case of=20
> >> a webserver + browser component, the importance of which is already
> enshrined in the spec by the definition of two response_types and flows?
> >>
> >> On Thu, Mar 15, 2012 at 3:54 PM, Breno de Medeiros
> 
> >> wrote:
> >> > On Thu, Mar 15, 2012 at 15:43, Eran Hammer 
> >> wrote:
> >> >> I don't know how to better explain myself. Forget about the text=20
> >> >> you
> >> have issue with. Just answer this:
> >> >>
> >> >> Reading the specification (with that text removed), what happens=20
> >> >> when a
> >> hybrid client wants to register? What client type does it provide?
> >> How should the server handle this case?
> >> >
> >> > In the example case of the webserver + browser-based client=20
> >> > components, I think the server should just allow it. The browser=20
> >> > does not need to expose the client_secret since it requires no=20
> >> > authentication credentials. The webserver should use the client=20
> >> > credentials acquired during registration to authenticate itself=20
> >> > when using the code flow.
> >> >
> >> > It's more interesting when mobile applications and webserver want=20
> >> > to share credentials. The mitigation strategy of limiting=20
> >> > lifetime of tokens may not work in this case. In general the=20
> >> > registration server should not allow the use of a single=20
> >> > registration in this case. This case is different from the above=20
> >> > in the sense that installed applications are typically _also_=20
> >> > using the 'code' flow, but from a different security context. A=20
> >> > server could allow both clients to share the same registration=20
> >> > information, but segregate the set of redirect URLs and tie the=20
> >> > code to each security context and apply different client=20
> >> > authentication requirements to each. Or the server could require=20
> >> > separate client registration for each
> component.
> >> >
> >> >>
> >> >> EH
> >> >>
> >> >>> -----Original Message-----
> >> >>> From: Breno de Medeiros [mailto:breno@google.com]
> >> >>> Sent: Thursday, March 15, 2012 2:12 PM
> >> >>> To: Eran Hammer
> >> >>> Cc: Nat Sakimura; OAuth WG
> >> >>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev.=20
> >> >>> 23
> >> >>>
> >> >>> On Thu, Mar 15, 2012 at 13:13, Eran Hammer
> 
> >> >>> wrote:
> >> >>> > Ok. That's much better than my guess that you wanted to drop=20
> >> >>> > all the registration text from the specification.
> >> >>> >
> >> >>> > What I'm looking for is a simple text that answers the question:
> >> >>> >
> >> >>> > "What to do if my client isn't simply public or confidential?"
> >> >>> >
> >> >>> > If we just drop the current text, the answer is implicitly=20
> >> >>> > "you can't have such a client" because there is no way to=20
> >> >>> > register a client of any other type.
> >> >>> >
> >> >>> > So let's try this again, and focus exclusively on answering=20
> >> >>> > this
> question.
> >> >>> > My text takes a position which is, "you can't - unless". Your=20
> >> >>> > suggestion is more of a vague discussion of the topic. I'd=20
> >> >>> > like to see clear, normative answer to this question.
> >> >>>
> >> >>> The current version is normative but far from clear. In fact,=20
> >> >>> the most natural interpretation is that it bans normal practice=20
> >> >>> and throws away the work that was done in defining different=20
> >> >>> flow types to
> >> support normal practice.
> >> >>>
> >> >>> 1. I don't see the need or desirability to put normative=20
> >> >>> language on registration practices.
> >> >>> 2. The contents of said normative language are harmful.
> >> >>>
> >> >>> I suggest two alternatives:
> >> >>>
> >> >>> 1. Remove the language.
> >> >>> 2. Substitute the language by non-normative informative discussion=
.
> >> >>>
> >> >>> You can also do other things, like introduce normative language=20
> >> >>> that makes sense. But I have not yet seen proposed language=20
> >> >>> that would be
> >> acceptable.
> >> >>>
> >> >>> >
> >> >>> > EH
> >> >>> >
> >> >>> >
> >> >>> > On 3/15/12 12:30 PM, "Breno de Medeiros" 
> >> wrote:
> >> >>> >
> >> >>> >>I am proposing the entire removal of:
> >> >>> >>
> >> >>> >>"A client application consisting of multiple components, each=20
> >> >>> >>with its own client type (e.g. a distributed client with both=20
> >> >>> >>a confidential server-based component and a public=20
> >> >>> >>browser-based component), MUST register each component=20
> >> >>> >>separately as a different client to ensure proper handling by=20
> >> >>> >>the authorization
> server."
> >> >>> >>
> >> >>> >>In particular the example of a server-side component versus=20
> >> >>> >>browser-based components is particularly unhelpful since it=20
> >> >>> >>violates the entire principle of why two response_type 'code'
> >> >>> >>and 'token' were defined, and how OAuth2 is typically
> implemented.
> >> >>> >>That's when I claim this normative language is redefining the
> protocol.
> >> >>> >>
> >> >>> >>
> >> >>> >>On Thu, Mar 15, 2012 at 12:13, Eran Hammer=20
> >> >>> >>
> >> >>> wrote:
> >> >>> >>> Which text in -25 are you proposing we remove exactly? I=20
> >> >>> >>>can't judge the  text below without the full context of=20
> >> >>> >>>where and how it is proposed in the  current document.
> >> >>> >>>
> >> >>> >>> Also, you are ignoring my detailed analysis of the current=20
> >> >>> >>>facts. We have  two client types and the issue here is what=20
> >> >>> >>>to do with other, undefined  types.
> >> >>> >>>
> >> >>> >>> EH
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> On 3/15/12 11:54 AM, "Breno de Medeiros"
> 
> >> >>> wrote:
> >> >>> >>>
> >> >>> >>>>My proposal is to remove any reference to registration=20
> >> >>> >>>>(which is a red herring and has raised all the problems we=20
> >> >>> >>>>refer
> >> >>> >>>>here) and refer to client authentication instead.
> >> >>> >>>>
> >> >>> >>>>Proposal:
> >> >>> >>>>
> >> >>> >>>>"Clients may be implemented as a distributed set of=20
> >> >>> >>>>components that run in different security contexts. For=20
> >> >>> >>>>instance, a single client may include a webserver component=20
> >> >>> >>>>and a script component in a browser. It is not appropriate=20
> >> >>> >>>>for the different components to utilize the same client=20
> >> >>> >>>>authentication mechanisms, since client authentication=20
> >> >>> >>>>credentials that are held securely in one context cannot be
> deployed securely in another.
> >> >>> >>>>
> >> >>> >>>>Servers MUST mitigate security threats from client=20
> >> >>> >>>>components that cannot hold client credentials as securely=20
> >> >>> >>>>by distinguishing them from client components that can.=20
> >> >>> >>>>Example of
> >> suitable measures are:
> >> >>> >>>>
> >> >>> >>>>- Requiring separate registration of components such as web=20
> >> >>> >>>>server and a mobile application.
> >> >>> >>>>- Restricting the time validity of tokens issued to clients=20
> >> >>> >>>>that hold no authentication credentials, such as browser=20
> >> >>> >>>>script-based components."
> >> >>> >>>>
> >> >>> >>>>Please don't truncate explanations in the interest of space=20
> >> >>> >>>>if the resulting text is confusing and possibly misleading.
> >> >>> >>>>Better to say nothing instead.
> >> >>> >>>>
> >> >>> >>>>On Thu, Mar 15, 2012 at 11:32, Eran Hammer
> >> 
> >> >>> wrote:
> >> >>> >>>>> Here are the facts:
> >> >>> >>>>>
> >> >>> >>>>> The authorization server must know the client type in=20
> >> >>> >>>>>order to enforce many  of the requirements in the specificati=
on.
> >> >>> >>>>> The requirement to provide a client type is not decorated=20
> >> >>> >>>>>with a MUST or  SHALL but that is implied.
> >> >>> >>>>> The specification only defines two client types: public=20
> >> >>> >>>>>and confidential.
> >> >>> >>>>> There is no client type defined for a hybrid client.
> >> >>> >>>>> The specification needs to address the very common use=20
> >> >>> >>>>>case of clients with  both public and private components.
> >> >>> >>>>>
> >> >>> >>>>> I don't want to discuss in the specification how client=20
> >> >>> >>>>>identifiers are  provisioned, nor do I want to discuss the=20
> >> >>> >>>>>potential binding of response  types to client types. But=20
> >> >>> >>>>>we do need to provide some guidance to clients  and=20
> >> >>> >>>>>authorization servers what to do with clients that do not=20
> >> >>> >>>>>fit the  current type definitions.
> >> >>> >>>>>
> >> >>> >>>>> It is far too late for us to define a new client type,=20
> >> >>> >>>>>along with all the  security considerations that such type=20
> >> >>> >>>>>imply. Our entire security  consideration section and=20
> >> >>> >>>>>protocol design are based on have a well defined  client type=
.
> >> >>> >>>>>
> >> >>> >>>>> Requiring separate registration for each component is the=20
> >> >>> >>>>> most straight-forward solution. Allowing the=20
> >> >>> >>>>> authorization server to offer alternatives is the=20
> >> >>> >>>>> backdoor to enable
> extensibility.
> >> >>> >>>>>
> >> >>> >>>>> Within these constraints, I am open to other prose or=20
> >> >>> >>>>>creative solutions.
> >> >>> >>>>> But the add-ons proposed are all ugly hacks. They clarify=20
> >> >>> >>>>>specific questions  raised which I do not believe=20
> >> >>> >>>>>represent the core confusion here which is  what is the=20
> >> >>> >>>>>right way to handle hybrid clients.
> >> >>> >>>>>
> >> >>> >>>>> The best way to move forward is to take a minute and ask=20
> >> >>> >>>>>the group to share  how they handle such cases or how they=20
> >> >>> >>>>>think they should be handled.
> >> >>> >>>>>Based
> >> >>> >>>>> on that we can come up with a clear solution.
> >> >>> >>>>>
> >> >>> >>>>> EH
> >> >>> >>>>>
> >> >>> >>>>> From: Breno de Medeiros 
> >> >>> >>>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
> >> >>> >>>>> To: Eran Hammer-Lahav 
> >> >>> >>>>> Cc: Nat Sakimura , OAuth WG
> >> >>> 
> >> >>> >>>>>
> >> >>> >>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
> rev.
> >> >>> >>>>> 23
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer=20
> >> >>> >>>>>
> >> >>> >>>>>wrote:
> >> >>> >>>>>>
> >> >>> >>>>>> This add-on is unnecessary. It already says the=20
> >> >>> >>>>>>authorization server can  handle it any way it wants. The=20
> >> >>> >>>>>>fact that other registration options are  possible=20
> >> >>> >>>>>>clearly covers the client identifier reuse case. As for=20
> >> >>> >>>>>>the response type, that=B9s not an issue but more of an
> optimization for an edge  case raised.
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>> It still feels like a horse by committee to me. "unless=20
> >> >>> >>>>>the authorization server provides other registration=20
> >> >>> >>>>>options to specify such  complex clients." seems a very=20
> >> >>> >>>>>round about way to say that the core spec  already=20
> >> >>> >>>>>provides for such arrangements in the most common=20
> >> >>> >>>>>scenario. It is a  bit of a stretch to say that the server=20
> >> >>> >>>>>provides "other registration options" by simply following=20
> >> >>> >>>>>strategy already laid out in the
> spec.
> >> >>> >>>>>
> >> >>> >>>>> In particular, I feel that this wording will be harmful=20
> >> >>> >>>>>to register extended  behavior, e.g., alternative=20
> >> >>> >>>>>response_types by leading to fruitless  conversations=20
> >> >>> >>>>>about spec compliance in the absence of real security risks.
> >> >>> >>>>>
> >> >>> >>>>> I do not believe the current text is the best=20
> >> >>> >>>>>representation of the spirit  in which the spec was=20
> >> >>> >>>>>written (in particular the effort to specify two flows  in=20
> >> >>> >>>>>detail to deal with precisely this issue) and possibly=20
> >> >>> >>>>>lead to
> harmful  future interpretation.
> >> >>> >>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> EH
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
> >> bounces@ietf.org]
> >> >>> >>>>>>On Behalf Of  Nat Sakimura
> >> >>> >>>>>> Sent: Thursday, March 15, 2012 2:04 AM
> >> >>> >>>>>> To: Breno de Medeiros; OAuth WG
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
> rev.
> >> >>> >>>>>> 23
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> So, Eran's first proposal:
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>   A client application consisting of multiple=20
> >> >>> >>>>>>components, each with its
> >> >>> >>>>>>   own client type (e.g. a distributed client with both a=20
> >> >>> >>>>>>confidential
> >> >>> >>>>>>   server-based component and a public browser-based=20
> >> >>> >>>>>>component), MUST
> >> >>> >>>>>>   register each component separately as a different=20
> >> >>> >>>>>>client to ensure
> >> >>> >>>>>>
> >> >>> >>>>>>   proper handling by the authorization server, unless=20
> >> >>> >>>>>>the authorization
> >> >>> >>>>>>   server provides other registration options to specify=20
> >> >>> >>>>>>such complex  clients.
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> kind of meets my concern. There seems to be another=20
> >> >>> >>>>>>issue around the  usefulness of return_type in such case=20
> >> >>> >>>>>>raised by Breno, and if I understand  it correctly,=20
> >> >>> >>>>>>Eran's answer was that these separate components may have=20
> >> >>> >>>>>>the  same client_id
> >> so
> >> >>> >>>>>>that return_type is a valid parameter to be sent at
> the  request.
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> So, to clarify these, perhaps changing the above text=20
> >> >>> >>>>>> slightly to the following solves the problem?
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>   A client application consisting of multiple=20
> >> >>> >>>>>>components, each with its
> >> >>> >>>>>>   own client type (e.g. a distributed client with both a=20
> >> >>> >>>>>>confidential
> >> >>> >>>>>>   server-based component and a public browser-based=20
> >> >>> >>>>>>component), MUST
> >> >>> >>>>>>   register each component separately as a different=20
> >> >>> >>>>>>client to ensure
> >> >>> >>>>>>
> >> >>> >>>>>>   proper handling by the authorization server, unless=20
> >> >>> >>>>>>the authorization
> >> >>> >>>>>>   server provides other registration options to specify=20
> >> >>> >>>>>>such complex  clients.
> >> >>> >>>>>>
> >> >>> >>>>>>   Each component MAY have the same client_id, in which=20
> >> >>> >>>>>>case the server
> >> >>> >>>>>>
> >> >>> >>>>>>   judges the client type and the associated security=20
> >> >>> >>>>>>context based on
> >> >>> >>>>>>   the response_type parameter in the request.
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> Would it solve your problem, Breno?
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> Best,
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> =3Dnat
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>> --
> >> >>> >>>>> --Breno
> >> >>> >>>>
> >> >>> >>>>
> >> >>> >>>>
> >> >>> >>>>--
> >> >>> >>>>--Breno
> >> >>> >>>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>--
> >> >>> >>--Breno
> >> >>> >
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> --Breno
> >> >
> >> >
> >> >
> >> > --
> >> > --Breno
> >> > _______________________________________________
> >> > OAuth mailing list
> >> > OAuth@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >>
> >> --
> >> Breno de Medeiros
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
> Breno de Medeiros



From sakimura@gmail.com  Sat Mar 17 16:31:22 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BDC21F867C for ; Sat, 17 Mar 2012 16:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.273
X-Spam-Level: 
X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEuhH6nZb+OJ for ; Sat, 17 Mar 2012 16:31:19 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20A9F21F8537 for ; Sat, 17 Mar 2012 16:31:18 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so4241626bku.31 for ; Sat, 17 Mar 2012 16:31:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KwmSImtRdOppzE3Rooj+Bw6revpxJT0kO+L1F1KW6qg=; b=fansGj3K72Nv70a61dxaH0ovudr0OonYnTnHYt2i2uNbNPwF1YH+FlC3RFe2mGShKY YbPf0IXPXELGOs7972Oqh59PdlDtRgVkt4KDGpHrJ3E0+UHv8X/FIipPB+jCehLo2HV3 D11aVuB1xAt/rtTkj92pXsshaSrkEcIgorrOvPODqCqFeREeHXYsn9XQBqlqWsfzyjrR KFBEoFwDDXlv6sdPywFhLT1++SGL/lOfO8QQIbeiSZVr39bj93bBKiv/SUz7XYAG/L+R M0EHOqRhftKmN5KE9Wp/ctvi1332I5uRJvLzgTFdTJ+3XP5QU+7Y1rFhSF/xCLNy380S PO2Q==
MIME-Version: 1.0
Received: by 10.204.154.144 with SMTP id o16mr2652778bkw.122.1332027077716; Sat, 17 Mar 2012 16:31:17 -0700 (PDT)
Received: by 10.204.185.196 with HTTP; Sat, 17 Mar 2012 16:31:17 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08C24@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:    <90C41DD21FB7C64BB94121FBBC2E723453AFF08AC2@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF08C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08C24@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Sun, 18 Mar 2012 08:31:17 +0900
Message-ID: 
From: Nat Sakimura 
To: Eran Hammer 
Content-Type: multipart/alternative; boundary=0015175cb40acc6cd404bb78b836
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Mar 2012 23:31:22 -0000

--0015175cb40acc6cd404bb78b836
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks Eran.

This is much better.

=3Dnat

On Sun, Mar 18, 2012 at 6:43 AM, Eran Hammer  wrote:

> Mike, Nat,
>
> Does the new text work for you?
>
> EH
>
> > -----Original Message-----
> > From: breno.demedeiros@gmail.com
> > [mailto:breno.demedeiros@gmail.com] On Behalf Of Breno
> > Sent: Saturday, March 17, 2012 12:10 PM
> > To: Eran Hammer
> > Cc: OAuth WG
> > Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >
> > That is much clearer. Thank you.
> >
> > On Sat, Mar 17, 2012 at 9:17 AM, Eran Hammer 
> > wrote:
> > > How about we phrase it the other way:
> > >
> > > A clients may be implemented as a distributed set of components, each
> > > with a different client type and security context (e.g. a distributed
> > > client with both a confidential server-based component and a public
> > > browser-based component). If the authorization
> > >  server does not provide support for such clients, or does not provid=
e
> > > guidance with regard to their registration, the client SHOULD registe=
r
> each
> > component as a separate client.
> > >
> > > This does two thing: put the server's policy first instead of as the
> exception,
> > and uses SHOULD instead of MUST which seems to be too strong for many
> > people.
> > >
> > > Better?
> > >
> > > EH
> > >
> > >
> > >> -----Original Message-----
> > >> From: breno.demedeiros@gmail.com
> > >> [mailto:breno.demedeiros@gmail.com] On Behalf Of Breno
> > >> Sent: Saturday, March 17, 2012 8:50 AM
> > >> To: Eran Hammer
> > >> Cc: OAuth WG
> > >> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> > >>
> > >> To summarize, I am weary of registration normative language that
> > >> appears to disallow common practice implemented by servers to
> > >> securely support multi- component applications. If these common
> > >> practices will be non-compliant (or at least it appears to be so on
> > >> first reading by many different people with detailed knowledge of th=
e
> > >> spec), isn't it incumbent on this spec to provide guidance on _how_
> > >> different components of an application will interoperate under
> > >> different registration? At least for the very common case of a
> > >> webserver + browser component, the importance of which is already
> > enshrined in the spec by the definition of two response_types and flows=
?
> > >>
> > >> On Thu, Mar 15, 2012 at 3:54 PM, Breno de Medeiros
> > 
> > >> wrote:
> > >> > On Thu, Mar 15, 2012 at 15:43, Eran Hammer 
> > >> wrote:
> > >> >> I don't know how to better explain myself. Forget about the text
> > >> >> you
> > >> have issue with. Just answer this:
> > >> >>
> > >> >> Reading the specification (with that text removed), what happens
> > >> >> when a
> > >> hybrid client wants to register? What client type does it provide?
> > >> How should the server handle this case?
> > >> >
> > >> > In the example case of the webserver + browser-based client
> > >> > components, I think the server should just allow it. The browser
> > >> > does not need to expose the client_secret since it requires no
> > >> > authentication credentials. The webserver should use the client
> > >> > credentials acquired during registration to authenticate itself
> > >> > when using the code flow.
> > >> >
> > >> > It's more interesting when mobile applications and webserver want
> > >> > to share credentials. The mitigation strategy of limiting lifetime
> > >> > of tokens may not work in this case. In general the registration
> > >> > server should not allow the use of a single registration in this
> > >> > case. This case is different from the above in the sense that
> > >> > installed applications are typically _also_ using the 'code' flow,
> > >> > but from a different security context. A server could allow both
> > >> > clients to share the same registration information, but segregate
> > >> > the set of redirect URLs and tie the code to each security context
> > >> > and apply different client authentication requirements to each. Or
> > >> > the server could require separate client registration for each
> > component.
> > >> >
> > >> >>
> > >> >> EH
> > >> >>
> > >> >>> -----Original Message-----
> > >> >>> From: Breno de Medeiros [mailto:breno@google.com]
> > >> >>> Sent: Thursday, March 15, 2012 2:12 PM
> > >> >>> To: Eran Hammer
> > >> >>> Cc: Nat Sakimura; OAuth WG
> > >> >>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> > >> >>>
> > >> >>> On Thu, Mar 15, 2012 at 13:13, Eran Hammer
> > 
> > >> >>> wrote:
> > >> >>> > Ok. That's much better than my guess that you wanted to drop
> > >> >>> > all the registration text from the specification.
> > >> >>> >
> > >> >>> > What I'm looking for is a simple text that answers the questio=
n:
> > >> >>> >
> > >> >>> > "What to do if my client isn't simply public or confidential?"
> > >> >>> >
> > >> >>> > If we just drop the current text, the answer is implicitly "yo=
u
> > >> >>> > can't have such a client" because there is no way to register =
a
> > >> >>> > client of any other type.
> > >> >>> >
> > >> >>> > So let's try this again, and focus exclusively on answering th=
is
> > question.
> > >> >>> > My text takes a position which is, "you can't - unless". Your
> > >> >>> > suggestion is more of a vague discussion of the topic. I'd lik=
e
> > >> >>> > to see clear, normative answer to this question.
> > >> >>>
> > >> >>> The current version is normative but far from clear. In fact, th=
e
> > >> >>> most natural interpretation is that it bans normal practice and
> > >> >>> throws away the work that was done in defining different flow
> > >> >>> types to
> > >> support normal practice.
> > >> >>>
> > >> >>> 1. I don't see the need or desirability to put normative languag=
e
> > >> >>> on registration practices.
> > >> >>> 2. The contents of said normative language are harmful.
> > >> >>>
> > >> >>> I suggest two alternatives:
> > >> >>>
> > >> >>> 1. Remove the language.
> > >> >>> 2. Substitute the language by non-normative informative
> discussion.
> > >> >>>
> > >> >>> You can also do other things, like introduce normative language
> > >> >>> that makes sense. But I have not yet seen proposed language that
> > >> >>> would be
> > >> acceptable.
> > >> >>>
> > >> >>> >
> > >> >>> > EH
> > >> >>> >
> > >> >>> >
> > >> >>> > On 3/15/12 12:30 PM, "Breno de Medeiros" 
> > >> wrote:
> > >> >>> >
> > >> >>> >>I am proposing the entire removal of:
> > >> >>> >>
> > >> >>> >>"A client application consisting of multiple components, each
> > >> >>> >>with its own client type (e.g. a distributed client with both =
a
> > >> >>> >>confidential server-based component and a public browser-based
> > >> >>> >>component), MUST register each component separately as a
> > >> >>> >>different client to ensure proper handling by the authorizatio=
n
> > server."
> > >> >>> >>
> > >> >>> >>In particular the example of a server-side component versus
> > >> >>> >>browser-based components is particularly unhelpful since it
> > >> >>> >>violates the entire principle of why two response_type 'code'
> > >> >>> >>and 'token' were defined, and how OAuth2 is typically
> > implemented.
> > >> >>> >>That's when I claim this normative language is redefining the
> > protocol.
> > >> >>> >>
> > >> >>> >>
> > >> >>> >>On Thu, Mar 15, 2012 at 12:13, Eran Hammer
> > >> >>> >>
> > >> >>> wrote:
> > >> >>> >>> Which text in -25 are you proposing we remove exactly? I
> > >> >>> >>>can't judge the  text below without the full context of where
> > >> >>> >>>and how it is proposed in the  current document.
> > >> >>> >>>
> > >> >>> >>> Also, you are ignoring my detailed analysis of the current
> > >> >>> >>>facts. We have  two client types and the issue here is what t=
o
> > >> >>> >>>do with other, undefined  types.
> > >> >>> >>>
> > >> >>> >>> EH
> > >> >>> >>>
> > >> >>> >>>
> > >> >>> >>> On 3/15/12 11:54 AM, "Breno de Medeiros"
> > 
> > >> >>> wrote:
> > >> >>> >>>
> > >> >>> >>>>My proposal is to remove any reference to registration (whic=
h
> > >> >>> >>>>is a red herring and has raised all the problems we refer
> > >> >>> >>>>here) and refer to client authentication instead.
> > >> >>> >>>>
> > >> >>> >>>>Proposal:
> > >> >>> >>>>
> > >> >>> >>>>"Clients may be implemented as a distributed set of
> > >> >>> >>>>components that run in different security contexts. For
> > >> >>> >>>>instance, a single client may include a webserver component
> > >> >>> >>>>and a script component in a browser. It is not appropriate
> > >> >>> >>>>for the different components to utilize the same client
> > >> >>> >>>>authentication mechanisms, since client authentication
> > >> >>> >>>>credentials that are held securely in one context cannot be
> > deployed securely in another.
> > >> >>> >>>>
> > >> >>> >>>>Servers MUST mitigate security threats from client component=
s
> > >> >>> >>>>that cannot hold client credentials as securely by
> > >> >>> >>>>distinguishing them from client components that can. Example
> > >> >>> >>>>of
> > >> suitable measures are:
> > >> >>> >>>>
> > >> >>> >>>>- Requiring separate registration of components such as web
> > >> >>> >>>>server and a mobile application.
> > >> >>> >>>>- Restricting the time validity of tokens issued to clients
> > >> >>> >>>>that hold no authentication credentials, such as browser
> > >> >>> >>>>script-based components."
> > >> >>> >>>>
> > >> >>> >>>>Please don't truncate explanations in the interest of space
> > >> >>> >>>>if the resulting text is confusing and possibly misleading.
> > >> >>> >>>>Better to say nothing instead.
> > >> >>> >>>>
> > >> >>> >>>>On Thu, Mar 15, 2012 at 11:32, Eran Hammer
> > >> 
> > >> >>> wrote:
> > >> >>> >>>>> Here are the facts:
> > >> >>> >>>>>
> > >> >>> >>>>> The authorization server must know the client type in orde=
r
> > >> >>> >>>>>to enforce many  of the requirements in the specification.
> > >> >>> >>>>> The requirement to provide a client type is not decorated
> > >> >>> >>>>>with a MUST or  SHALL but that is implied.
> > >> >>> >>>>> The specification only defines two client types: public an=
d
> > >> >>> >>>>>confidential.
> > >> >>> >>>>> There is no client type defined for a hybrid client.
> > >> >>> >>>>> The specification needs to address the very common use cas=
e
> > >> >>> >>>>>of clients with  both public and private components.
> > >> >>> >>>>>
> > >> >>> >>>>> I don't want to discuss in the specification how client
> > >> >>> >>>>>identifiers are  provisioned, nor do I want to discuss the
> > >> >>> >>>>>potential binding of response  types to client types. But w=
e
> > >> >>> >>>>>do need to provide some guidance to clients  and
> > >> >>> >>>>>authorization servers what to do with clients that do not
> > >> >>> >>>>>fit the  current type definitions.
> > >> >>> >>>>>
> > >> >>> >>>>> It is far too late for us to define a new client type,
> > >> >>> >>>>>along with all the  security considerations that such type
> > >> >>> >>>>>imply. Our entire security  consideration section and
> > >> >>> >>>>>protocol design are based on have a well defined  client
> type.
> > >> >>> >>>>>
> > >> >>> >>>>> Requiring separate registration for each component is the
> > >> >>> >>>>> most straight-forward solution. Allowing the authorization
> > >> >>> >>>>> server to offer alternatives is the backdoor to enable
> > extensibility.
> > >> >>> >>>>>
> > >> >>> >>>>> Within these constraints, I am open to other prose or
> > >> >>> >>>>>creative solutions.
> > >> >>> >>>>> But the add-ons proposed are all ugly hacks. They clarify
> > >> >>> >>>>>specific questions  raised which I do not believe represent
> > >> >>> >>>>>the core confusion here which is  what is the right way to
> > >> >>> >>>>>handle hybrid clients.
> > >> >>> >>>>>
> > >> >>> >>>>> The best way to move forward is to take a minute and ask
> > >> >>> >>>>>the group to share  how they handle such cases or how they
> > >> >>> >>>>>think they should be handled.
> > >> >>> >>>>>Based
> > >> >>> >>>>> on that we can come up with a clear solution.
> > >> >>> >>>>>
> > >> >>> >>>>> EH
> > >> >>> >>>>>
> > >> >>> >>>>> From: Breno de Medeiros 
> > >> >>> >>>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
> > >> >>> >>>>> To: Eran Hammer-Lahav 
> > >> >>> >>>>> Cc: Nat Sakimura , OAuth WG
> > >> >>> 
> > >> >>> >>>>>
> > >> >>> >>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
> > rev.
> > >> >>> >>>>> 23
> > >> >>> >>>>>
> > >> >>> >>>>>
> > >> >>> >>>>>
> > >> >>> >>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer
> > >> >>> >>>>>
> > >> >>> >>>>>wrote:
> > >> >>> >>>>>>
> > >> >>> >>>>>> This add-on is unnecessary. It already says the
> > >> >>> >>>>>>authorization server can  handle it any way it wants. The
> > >> >>> >>>>>>fact that other registration options are  possible clearly
> > >> >>> >>>>>>covers the client identifier reuse case. As for the
> > >> >>> >>>>>>response type, that=B9s not an issue but more of an
> > optimization for an edge  case raised.
> > >> >>> >>>>>
> > >> >>> >>>>>
> > >> >>> >>>>> It still feels like a horse by committee to me. "unless th=
e
> > >> >>> >>>>>authorization server provides other registration options to
> > >> >>> >>>>>specify such  complex clients." seems a very round about wa=
y
> > >> >>> >>>>>to say that the core spec  already provides for such
> > >> >>> >>>>>arrangements in the most common scenario. It is a  bit of a
> > >> >>> >>>>>stretch to say that the server provides "other registration
> > >> >>> >>>>>options" by simply following strategy already laid out in t=
he
> > spec.
> > >> >>> >>>>>
> > >> >>> >>>>> In particular, I feel that this wording will be harmful to
> > >> >>> >>>>>register extended  behavior, e.g., alternative
> > >> >>> >>>>>response_types by leading to fruitless  conversations about
> > >> >>> >>>>>spec compliance in the absence of real security risks.
> > >> >>> >>>>>
> > >> >>> >>>>> I do not believe the current text is the best
> > >> >>> >>>>>representation of the spirit  in which the spec was written
> > >> >>> >>>>>(in particular the effort to specify two flows  in detail t=
o
> > >> >>> >>>>>deal with precisely this issue) and possibly lead to
> > harmful  future interpretation.
> > >> >>> >>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>> EH
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
> > >> bounces@ietf.org]
> > >> >>> >>>>>>On Behalf Of  Nat Sakimura
> > >> >>> >>>>>> Sent: Thursday, March 15, 2012 2:04 AM
> > >> >>> >>>>>> To: Breno de Medeiros; OAuth WG
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
> > rev.
> > >> >>> >>>>>> 23
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>> So, Eran's first proposal:
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>   A client application consisting of multiple components,
> > >> >>> >>>>>>each with its
> > >> >>> >>>>>>   own client type (e.g. a distributed client with both a
> > >> >>> >>>>>>confidential
> > >> >>> >>>>>>   server-based component and a public browser-based
> > >> >>> >>>>>>component), MUST
> > >> >>> >>>>>>   register each component separately as a different clien=
t
> > >> >>> >>>>>>to ensure
> > >> >>> >>>>>>
> > >> >>> >>>>>>   proper handling by the authorization server, unless the
> > >> >>> >>>>>>authorization
> > >> >>> >>>>>>   server provides other registration options to specify
> > >> >>> >>>>>>such complex  clients.
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>> kind of meets my concern. There seems to be another issue
> > >> >>> >>>>>>around the  usefulness of return_type in such case raised
> > >> >>> >>>>>>by Breno, and if I understand  it correctly, Eran's answer
> > >> >>> >>>>>>was that these separate components may have the  same
> > >> >>> >>>>>>client_id
> > >> so
> > >> >>> >>>>>>that return_type is a valid parameter to be sent at
> > the  request.
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>> So, to clarify these, perhaps changing the above text
> > >> >>> >>>>>> slightly to the following solves the problem?
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>   A client application consisting of multiple components,
> > >> >>> >>>>>>each with its
> > >> >>> >>>>>>   own client type (e.g. a distributed client with both a
> > >> >>> >>>>>>confidential
> > >> >>> >>>>>>   server-based component and a public browser-based
> > >> >>> >>>>>>component), MUST
> > >> >>> >>>>>>   register each component separately as a different clien=
t
> > >> >>> >>>>>>to ensure
> > >> >>> >>>>>>
> > >> >>> >>>>>>   proper handling by the authorization server, unless the
> > >> >>> >>>>>>authorization
> > >> >>> >>>>>>   server provides other registration options to specify
> > >> >>> >>>>>>such complex  clients.
> > >> >>> >>>>>>
> > >> >>> >>>>>>   Each component MAY have the same client_id, in which
> > >> >>> >>>>>>case the server
> > >> >>> >>>>>>
> > >> >>> >>>>>>   judges the client type and the associated security
> > >> >>> >>>>>>context based on
> > >> >>> >>>>>>   the response_type parameter in the request.
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>> Would it solve your problem, Breno?
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>> Best,
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>> =3Dnat
> > >> >>> >>>>>>
> > >> >>> >>>>>>
> > >> >>> >>>>>
> > >> >>> >>>>>
> > >> >>> >>>>>
> > >> >>> >>>>>
> > >> >>> >>>>> --
> > >> >>> >>>>> --Breno
> > >> >>> >>>>
> > >> >>> >>>>
> > >> >>> >>>>
> > >> >>> >>>>--
> > >> >>> >>>>--Breno
> > >> >>> >>>
> > >> >>> >>
> > >> >>> >>
> > >> >>> >>
> > >> >>> >>--
> > >> >>> >>--Breno
> > >> >>> >
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> --
> > >> >>> --Breno
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > --Breno
> > >> > _______________________________________________
> > >> > OAuth mailing list
> > >> > OAuth@ietf.org
> > >> > https://www.ietf.org/mailman/listinfo/oauth
> > >>
> > >>
> > >>
> > >> --
> > >> Breno de Medeiros
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> > --
> > Breno de Medeiros
>



--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--0015175cb40acc6cd404bb78b836
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks Eran.=A0

This is much better.=A0

=3Dnat

On Sun, Mar 18, 2012 at 6:43 AM=
, Eran Hammer <=
eran@hueniverse.com> wrote:


Mike, Nat,



Does the new text work for you?




EH



> -----Original Message-----

> From: breno.demedeiros@g=
mail.com

> [mailto:breno.demedeiros=
@gmail.com] On Behalf Of Breno


> Sent: Saturday, March 17, 2012 12:10 PM=


> To: Eran Hammer


> Cc: OAuth WG

> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

>

> That is much clearer. Thank you.

>

> On Sat, Mar 17, 2012 at 9:17 AM, Eran Hammer <eran@hueniverse.com>

> wrote:

> > How about we phrase it the other way:

> >

> > A clients may be implemented as a distributed set of components, =
each

> > with a different client type and security context (e.g. a distrib=
uted

> > client with both a confidential server-based component and a publ=
ic

> > browser-based component). If the authorization

> > =A0server does not provide support for such clients, or does not =
provide

> > guidance with regard to their registration, the client SHOULD reg=
ister each

> component as a separate client.

> >

> > This does two thing: put the server's policy first instead of=
 as the exception,

> and uses SHOULD instead of MUST which seems to be too strong for many<=
br>
> people.

> >

> > Better?

> >

> > EH

> >

> >

> >> -----Original Message-----

> >> From: breno.dem=
edeiros@gmail.com

> >> [mailto:breno.d=
emedeiros@gmail.com] On Behalf Of Breno

> >> Sent: Saturday, March 17, 2012 8:50 AM

> >> To: Eran Hammer

> >> Cc: OAuth WG

> >> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev.=
 23

> >>

> >> To summarize, I am weary of registration normative language t=
hat

> >> appears to disallow common practice implemented by servers to=


> >> securely support multi- component applications. If these comm=
on

> >> practices will be non-compliant (or at least it appears to be=
 so on

> >> first reading by many different people with detailed knowledg=
e of the

> >> spec), isn't it incumbent on this spec to provide guidanc=
e on _how_

> >> different components of an application will interoperate unde=
r

> >> different registration? At least for the very common case of =
a

> >> webserver + browser component, the importance of which is alr=
eady

> enshrined in the spec by the definition of two response_types and flow=
s?

> >>

> >> On Thu, Mar 15, 2012 at 3:54 PM, Breno de Medeiros

> <breno@google.com>

> >> wrote:

> >> > On Thu, Mar 15, 2012 at 15:43, Eran Hammer <eran@hueniverse.com>

> >> wrote:

> >> >> I don't know how to better explain myself. Forge=
t about the text

> >> >> you

> >> have issue with. Just answer this:

> >> >>

> >> >> Reading the specification (with that text removed), =
what happens

> >> >> when a

> >> hybrid client wants to register? What client type does it pro=
vide?

> >> How should the server handle this case?

> >> >

> >> > In the example case of the webserver + browser-based cli=
ent

> >> > components, I think the server should just allow it. The=
 browser

> >> > does not need to expose the client_secret since it requi=
res no

> >> > authentication credentials. The webserver should use the=
 client

> >> > credentials acquired during registration to authenticate=
 itself

> >> > when using the code flow.

> >> >

> >> > It's more interesting when mobile applications and w=
ebserver want

> >> > to share credentials. The mitigation strategy of limitin=
g lifetime

> >> > of tokens may not work in this case. In general the regi=
stration

> >> > server should not allow the use of a single registration=
 in this

> >> > case. This case is different from the above in the sense=
 that

> >> > installed applications are typically _also_ using the &#=
39;code' flow,

> >> > but from a different security context. A server could al=
low both

> >> > clients to share the same registration information, but =
segregate

> >> > the set of redirect URLs and tie the code to each securi=
ty context

> >> > and apply different client authentication requirements t=
o each. Or

> >> > the server could require separate client registration fo=
r each

> component.

> >> >

> >> >>

> >> >> EH

> >> >>

> >> >>> -----Original Message-----

> >> >>> From: Breno de Medeiros [mailto:breno@google.com]

> >> >>> Sent: Thursday, March 15, 2012 2:12 PM

> >> >>> To: Eran Hammer

> >> >>> Cc: Nat Sakimura; OAuth WG

> >> >>> Subject: Re: [OAUTH-WG] Fw: Breaking change in O=
Auth 2.0 rev. 23

> >> >>>

> >> >>> On Thu, Mar 15, 2012 at 13:13, Eran Hammer

> <eran@hueniverse.com>=


> >> >>> wrote:

> >> >>> > Ok. That's much better than my guess th=
at you wanted to drop

> >> >>> > all the registration text from the specific=
ation.

> >> >>> >

> >> >>> > What I'm looking for is a simple text t=
hat answers the question:

> >> >>> >

> >> >>> > "What to do if my client isn't sim=
ply public or confidential?"

> >> >>> >

> >> >>> > If we just drop the current text, the answe=
r is implicitly "you

> >> >>> > can't have such a client" because =
there is no way to register a

> >> >>> > client of any other type.

> >> >>> >

> >> >>> > So let's try this again, and focus excl=
usively on answering this

> question.

> >> >>> > My text takes a position which is, "yo=
u can't - unless". Your

> >> >>> > suggestion is more of a vague discussion of=
 the topic. I'd like

> >> >>> > to see clear, normative answer to this ques=
tion.

> >> >>>

> >> >>> The current version is normative but far from cl=
ear. In fact, the

> >> >>> most natural interpretation is that it bans norm=
al practice and

> >> >>> throws away the work that was done in defining d=
ifferent flow

> >> >>> types to

> >> support normal practice.

> >> >>>

> >> >>> 1. I don't see the need or desirability to p=
ut normative language

> >> >>> on registration practices.

> >> >>> 2. The contents of said normative language are h=
armful.

> >> >>>

> >> >>> I suggest two alternatives:

> >> >>>

> >> >>> 1. Remove the language.

> >> >>> 2. Substitute the language by non-normative info=
rmative discussion.

> >> >>>

> >> >>> You can also do other things, like introduce nor=
mative language

> >> >>> that makes sense. But I have not yet seen propos=
ed language that

> >> >>> would be

> >> acceptable.

> >> >>>

> >> >>> >

> >> >>> > EH

> >> >>> >

> >> >>> >

> >> >>> > On 3/15/12 12:30 PM, "Breno de Medeiro=
s" <breno@google.com>
> >> wrote:

> >> >>> >

> >> >>> >>I am proposing the entire removal of:
> >> >>> >>

> >> >>> >>"A client application consisting of=
 multiple components, each

> >> >>> >>with its own client type (e.g. a distrib=
uted client with both a

> >> >>> >>confidential server-based component and =
a public browser-based

> >> >>> >>component), MUST register each component=
 separately as a

> >> >>> >>different client to ensure proper handli=
ng by the authorization

> server."

> >> >>> >>

> >> >>> >>In particular the example of a server-si=
de component versus

> >> >>> >>browser-based components is particularly=
 unhelpful since it

> >> >>> >>violates the entire principle of why two=
 response_type 'code'

> >> >>> >>and 'token' were defined, and ho=
w OAuth2 is typically

> implemented.

> >> >>> >>That's when I claim this normative l=
anguage is redefining the

> protocol.

> >> >>> >>

> >> >>> >>

> >> >>> >>On Thu, Mar 15, 2012 at 12:13, Eran Hamm=
er

> >> >>> >><eran@hueniverse.com>

> >> >>> wrote:

> >> >>> >>> Which text in -25 are you proposing=
 we remove exactly? I

> >> >>> >>>can't judge the =A0text below wi=
thout the full context of where

> >> >>> >>>and how it is proposed in the =A0cur=
rent document.

> >> >>> >>>

> >> >>> >>> Also, you are ignoring my detailed =
analysis of the current

> >> >>> >>>facts. We have =A0two client types a=
nd the issue here is what to

> >> >>> >>>do with other, undefined =A0types.
> >> >>> >>>

> >> >>> >>> EH

> >> >>> >>>

> >> >>> >>>

> >> >>> >>> On 3/15/12 11:54 AM, "Breno de=
 Medeiros"

> <breno@google.com>

> >> >>> wrote:

> >> >>> >>>

> >> >>> >>>>My proposal is to remove any ref=
erence to registration (which

> >> >>> >>>>is a red herring and has raised =
all the problems we refer

> >> >>> >>>>here) and refer to client authen=
tication instead.

> >> >>> >>>>

> >> >>> >>>>Proposal:

> >> >>> >>>>

> >> >>> >>>>"Clients may be implemented=
 as a distributed set of

> >> >>> >>>>components that run in different=
 security contexts. For

> >> >>> >>>>instance, a single client may in=
clude a webserver component

> >> >>> >>>>and a script component in a brow=
ser. It is not appropriate

> >> >>> >>>>for the different components to =
utilize the same client

> >> >>> >>>>authentication mechanisms, since=
 client authentication

> >> >>> >>>>credentials that are held secure=
ly in one context cannot be

> deployed securely in another.

> >> >>> >>>>

> >> >>> >>>>Servers MUST mitigate security t=
hreats from client components

> >> >>> >>>>that cannot hold client credenti=
als as securely by

> >> >>> >>>>distinguishing them from client =
components that can. Example

> >> >>> >>>>of

> >> suitable measures are:

> >> >>> >>>>

> >> >>> >>>>- Requiring separate registratio=
n of components such as web

> >> >>> >>>>server and a mobile application.=


> >> >>> >>>>- Restricting the time validity =
of tokens issued to clients

> >> >>> >>>>that hold no authentication cred=
entials, such as browser

> >> >>> >>>>script-based components."
> >> >>> >>>>

> >> >>> >>>>Please don't truncate explan=
ations in the interest of space

> >> >>> >>>>if the resulting text is confusi=
ng and possibly misleading.

> >> >>> >>>>Better to say nothing instead.
> >> >>> >>>>

> >> >>> >>>>On Thu, Mar 15, 2012 at 11:32, E=
ran Hammer

> >> <eran@hueniverse.co=
m>

> >> >>> wrote:

> >> >>> >>>>> Here are the facts:

> >> >>> >>>>>

> >> >>> >>>>> The authorization server mu=
st know the client type in order

> >> >>> >>>>>to enforce many =A0of the re=
quirements in the specification.

> >> >>> >>>>> The requirement to provide =
a client type is not decorated

> >> >>> >>>>>with a MUST or =A0SHALL but =
that is implied.

> >> >>> >>>>> The specification only defi=
nes two client types: public and

> >> >>> >>>>>confidential.

> >> >>> >>>>> There is no client type def=
ined for a hybrid client.

> >> >>> >>>>> The specification needs to =
address the very common use case

> >> >>> >>>>>of clients with =A0both publ=
ic and private components.

> >> >>> >>>>>

> >> >>> >>>>> I don't want to discuss=
 in the specification how client

> >> >>> >>>>>identifiers are =A0provision=
ed, nor do I want to discuss the

> >> >>> >>>>>potential binding of respons=
e =A0types to client types. But we

> >> >>> >>>>>do need to provide some guid=
ance to clients =A0and

> >> >>> >>>>>authorization servers what t=
o do with clients that do not

> >> >>> >>>>>fit the =A0current type defi=
nitions.

> >> >>> >>>>>

> >> >>> >>>>> It is far too late for us t=
o define a new client type,

> >> >>> >>>>>along with all the =A0securi=
ty considerations that such type

> >> >>> >>>>>imply. Our entire security =
=A0consideration section and

> >> >>> >>>>>protocol design are based on=
 have a well defined =A0client type.

> >> >>> >>>>>

> >> >>> >>>>> Requiring separate registra=
tion for each component is the

> >> >>> >>>>> most straight-forward solut=
ion. Allowing the authorization

> >> >>> >>>>> server to offer alternative=
s is the backdoor to enable

> extensibility.

> >> >>> >>>>>

> >> >>> >>>>> Within these constraints, I=
 am open to other prose or

> >> >>> >>>>>creative solutions.

> >> >>> >>>>> But the add-ons proposed ar=
e all ugly hacks. They clarify

> >> >>> >>>>>specific questions =A0raised=
 which I do not believe represent

> >> >>> >>>>>the core confusion here whic=
h is =A0what is the right way to

> >> >>> >>>>>handle hybrid clients.

> >> >>> >>>>>

> >> >>> >>>>> The best way to move forwar=
d is to take a minute and ask

> >> >>> >>>>>the group to share =A0how th=
ey handle such cases or how they

> >> >>> >>>>>think they should be handled=
.

> >> >>> >>>>>Based

> >> >>> >>>>> on that we can come up with=
 a clear solution.

> >> >>> >>>>>

> >> >>> >>>>> EH

> >> >>> >>>>>

> >> >>> >>>>> From: Breno de Medeiros <=
;breno@google.com>

> >> >>> >>>>> Date: Thu, 15 Mar 2012 09:5=
6:13 -0700

> >> >>> >>>>> To: Eran Hammer-Lahav <<=
a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com>

> >> >>> >>>>> Cc: Nat Sakimura <sakimura@gmail.com>, OAuth WG

> >> >>> <oauth@ietf=
.org>

> >> >>> >>>>>

> >> >>> >>>>> Subject: Re: [OAUTH-WG] Fw:=
 Breaking change in OAuth 2.0

> rev.

> >> >>> >>>>> 23

> >> >>> >>>>>

> >> >>> >>>>>

> >> >>> >>>>>

> >> >>> >>>>> On Thu, Mar 15, 2012 at 07:=
45, Eran Hammer

> >> >>> >>>>><eran@hueniverse.com>

> >> >>> >>>>>wrote:

> >> >>> >>>>>>

> >> >>> >>>>>> This add-on is unnecess=
ary. It already says the

> >> >>> >>>>>>authorization server can=
 =A0handle it any way it wants. The

> >> >>> >>>>>>fact that other registra=
tion options are =A0possible clearly

> >> >>> >>>>>>covers the client identi=
fier reuse case. As for the

> >> >>> >>>>>>response type, that=B9s =
not an issue but more of an

> optimization for an edge =A0case raised.

> >> >>> >>>>>

> >> >>> >>>>>

> >> >>> >>>>> It still feels like a horse=
 by committee to me. "unless the

> >> >>> >>>>>authorization server provide=
s other registration options to

> >> >>> >>>>>specify such =A0complex clie=
nts." seems a very round about way

> >> >>> >>>>>to say that the core spec =
=A0already provides for such

> >> >>> >>>>>arrangements in the most com=
mon scenario. It is a =A0bit of a

> >> >>> >>>>>stretch to say that the serv=
er provides "other registration

> >> >>> >>>>>options" by simply foll=
owing strategy already laid out in the

> spec.

> >> >>> >>>>>

> >> >>> >>>>> In particular, I feel that =
this wording will be harmful to

> >> >>> >>>>>register extended =A0behavio=
r, e.g., alternative

> >> >>> >>>>>response_types by leading to=
 fruitless =A0conversations about

> >> >>> >>>>>spec compliance in the absen=
ce of real security risks.

> >> >>> >>>>>

> >> >>> >>>>> I do not believe the curren=
t text is the best

> >> >>> >>>>>representation of the spirit=
 =A0in which the spec was written

> >> >>> >>>>>(in particular the effort to=
 specify two flows =A0in detail to

> >> >>> >>>>>deal with precisely this iss=
ue) and possibly lead to

> harmful =A0future interpretation.

> >> >>> >>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>> EH

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-

> >> bounces@ietf.org]

> >> >>> >>>>>>On Behalf Of =A0Nat Saki=
mura

> >> >>> >>>>>> Sent: Thursday, March 1=
5, 2012 2:04 AM

> >> >>> >>>>>> To: Breno de Medeiros; =
OAuth WG

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>> Subject: Re: [OAUTH-WG]=
 Fw: Breaking change in OAuth 2.0

> rev.

> >> >>> >>>>>> 23

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>> So, Eran's first pr=
oposal:

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>> =A0 A client applicatio=
n consisting of multiple components,

> >> >>> >>>>>>each with its

> >> >>> >>>>>> =A0 own client type (e.=
g. a distributed client with both a

> >> >>> >>>>>>confidential

> >> >>> >>>>>> =A0 server-based compon=
ent and a public browser-based

> >> >>> >>>>>>component), MUST

> >> >>> >>>>>> =A0 register each compo=
nent separately as a different client

> >> >>> >>>>>>to ensure

> >> >>> >>>>>>

> >> >>> >>>>>> =A0 proper handling by =
the authorization server, unless the

> >> >>> >>>>>>authorization

> >> >>> >>>>>> =A0 server provides oth=
er registration options to specify

> >> >>> >>>>>>such complex =A0clients.=


> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>> kind of meets my concer=
n. There seems to be another issue

> >> >>> >>>>>>around the =A0usefulness=
 of return_type in such case raised

> >> >>> >>>>>>by Breno, and if I under=
stand =A0it correctly, Eran's answer

> >> >>> >>>>>>was that these separate =
components may have the =A0same

> >> >>> >>>>>>client_id

> >> so

> >> >>> >>>>>>that return_type is a va=
lid parameter to be sent at

> the =A0request.

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>> So, to clarify these, p=
erhaps changing the above text

> >> >>> >>>>>> slightly to the followi=
ng solves the problem?

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>> =A0 A client applicatio=
n consisting of multiple components,

> >> >>> >>>>>>each with its

> >> >>> >>>>>> =A0 own client type (e.=
g. a distributed client with both a

> >> >>> >>>>>>confidential

> >> >>> >>>>>> =A0 server-based compon=
ent and a public browser-based

> >> >>> >>>>>>component), MUST

> >> >>> >>>>>> =A0 register each compo=
nent separately as a different client

> >> >>> >>>>>>to ensure

> >> >>> >>>>>>

> >> >>> >>>>>> =A0 proper handling by =
the authorization server, unless the

> >> >>> >>>>>>authorization

> >> >>> >>>>>> =A0 server provides oth=
er registration options to specify

> >> >>> >>>>>>such complex =A0clients.=


> >> >>> >>>>>>

> >> >>> >>>>>> =A0 Each component MAY =
have the same client_id, in which

> >> >>> >>>>>>case the server

> >> >>> >>>>>>

> >> >>> >>>>>> =A0 judges the client t=
ype and the associated security

> >> >>> >>>>>>context based on

> >> >>> >>>>>> =A0 the response_type p=
arameter in the request.

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>> Would it solve your pro=
blem, Breno?

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>> Best,

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>> =3Dnat

> >> >>> >>>>>>

> >> >>> >>>>>>

> >> >>> >>>>>

> >> >>> >>>>>

> >> >>> >>>>>

> >> >>> >>>>>

> >> >>> >>>>> --

> >> >>> >>>>> --Breno

> >> >>> >>>>

> >> >>> >>>>

> >> >>> >>>>

> >> >>> >>>>--

> >> >>> >>>>--Breno

> >> >>> >>>

> >> >>> >>

> >> >>> >>

> >> >>> >>

> >> >>> >>--

> >> >>> >>--Breno

> >> >>> >

> >> >>>

> >> >>>

> >> >>>

> >> >>> --

> >> >>> --Breno

> >> >

> >> >

> >> >

> >> > --

> >> > --Breno

> >> > _______________________________________________

> >> > OAuth mailing list

> >> > OAuth@ietf.org

> >> > https://www.ietf.org/mailman/listinfo/oauth

> >>

> >>

> >>

> >> --

> >> Breno de Medeiros

> > _______________________________________________

> > OAuth mailing list

> > OAuth@ietf.org

> > https://www.ietf.org/mailman/listinfo/oauth

>

>

>

> --

> Breno de Medeiros





-- 
=
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_=
en






--0015175cb40acc6cd404bb78b836--

From ve7jtb@ve7jtb.com  Sat Mar 17 22:08:03 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D0111E8075 for ; Sat, 17 Mar 2012 22:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level: 
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-NrQijVIzwX for ; Sat, 17 Mar 2012 22:08:02 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 282CD11E8072 for ; Sat, 17 Mar 2012 22:08:02 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so5687394ggm.31 for ; Sat, 17 Mar 2012 22:08:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=IvrnfvZllW/jaM+j4iS0+QXQhjHTjHa+oYt7L6l8PA4=; b=fsVaFgDII9KHXkcY1qcNrQmcfGR7gr0GXzCld/+g4h2tnbOnhytzgbf2Qakm/HjUgM GOeCbOms3/CWUD15t3tf8iSoleiOwvjmB36ekOLUykiPdLm/zXYdxmJfwtwJfaKUsfQz RMkhignDnUXjST61ri7kerHlf05GSQ+vCyJHbZS3JnQWp/thcKKXA9kwPXmNwnxE9Nxv jXp/Qe+aG17mi2CqsAwF77R3acEwoz9j9ysod5zK/FMRAVOhZ6WBaDieIcXpnTBtPNr7 ZeBtCOMovvnbw5kHhjwreNbP7CSlflqOMQhjjjHXt5xCvTplOPZh5H1ERGeIusGD40rn m4Cg==
Received: by 10.236.153.70 with SMTP id e46mr8050018yhk.29.1332047281608; Sat, 17 Mar 2012 22:08:01 -0700 (PDT)
Received: from [192.168.1.202] (190-20-44-71.baf.movistar.cl. [190.20.44.71]) by mx.google.com with ESMTPS id n35sm27084039yhh.19.2012.03.17.22.07.51 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Mar 2012 22:08:00 -0700 (PDT)
References:    <90C41DD21FB7C64BB94121FBBC2E723453AFF08AC2@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <90C41DD21FB7C64BB94121FBBC2E723453AFF08C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723453AFF08C24@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08C24@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Message-Id: 
X-Mailer: iPad Mail (9B176)
From: John Bradley 
Date: Sun, 18 Mar 2012 01:09:23 -0400
To: Eran Hammer 
X-Gm-Message-State: ALoCoQkm1l6wKR+VARk83FxKGQgIQhdjkR2VzH9PAVY+Xkw28/yfpm7lezU4Ho0YUyD01d/EbBbn
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Mar 2012 05:08:03 -0000

OK with me.=20

John B=20

Sent from my iPad

On 2012-03-17, at 5:43 PM, Eran Hammer  wrote:

> Mike, Nat,
>=20
> Does the new text work for you?
>=20
> EH
>=20
>> -----Original Message-----
>> From: breno.demedeiros@gmail.com
>> [mailto:breno.demedeiros@gmail.com] On Behalf Of Breno
>> Sent: Saturday, March 17, 2012 12:10 PM
>> To: Eran Hammer
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>=20
>> That is much clearer. Thank you.
>>=20
>> On Sat, Mar 17, 2012 at 9:17 AM, Eran Hammer 
>> wrote:
>>> How about we phrase it the other way:
>>>=20
>>> A clients may be implemented as a distributed set of components, each
>>> with a different client type and security context (e.g. a distributed
>>> client with both a confidential server-based component and a public
>>> browser-based component). If the authorization
>>> server does not provide support for such clients, or does not provide
>>> guidance with regard to their registration, the client SHOULD register e=
ach
>> component as a separate client.
>>>=20
>>> This does two thing: put the server's policy first instead of as the exc=
eption,
>> and uses SHOULD instead of MUST which seems to be too strong for many
>> people.
>>>=20
>>> Better?
>>>=20
>>> EH
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: breno.demedeiros@gmail.com
>>>> [mailto:breno.demedeiros@gmail.com] On Behalf Of Breno
>>>> Sent: Saturday, March 17, 2012 8:50 AM
>>>> To: Eran Hammer
>>>> Cc: OAuth WG
>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>>>=20
>>>> To summarize, I am weary of registration normative language that
>>>> appears to disallow common practice implemented by servers to
>>>> securely support multi- component applications. If these common
>>>> practices will be non-compliant (or at least it appears to be so on
>>>> first reading by many different people with detailed knowledge of the
>>>> spec), isn't it incumbent on this spec to provide guidance on _how_
>>>> different components of an application will interoperate under
>>>> different registration? At least for the very common case of a
>>>> webserver + browser component, the importance of which is already
>> enshrined in the spec by the definition of two response_types and flows?
>>>>=20
>>>> On Thu, Mar 15, 2012 at 3:54 PM, Breno de Medeiros
>> 
>>>> wrote:
>>>>> On Thu, Mar 15, 2012 at 15:43, Eran Hammer 
>>>> wrote:
>>>>>> I don't know how to better explain myself. Forget about the text
>>>>>> you
>>>> have issue with. Just answer this:
>>>>>>=20
>>>>>> Reading the specification (with that text removed), what happens
>>>>>> when a
>>>> hybrid client wants to register? What client type does it provide?
>>>> How should the server handle this case?
>>>>>=20
>>>>> In the example case of the webserver + browser-based client
>>>>> components, I think the server should just allow it. The browser
>>>>> does not need to expose the client_secret since it requires no
>>>>> authentication credentials. The webserver should use the client
>>>>> credentials acquired during registration to authenticate itself
>>>>> when using the code flow.
>>>>>=20
>>>>> It's more interesting when mobile applications and webserver want
>>>>> to share credentials. The mitigation strategy of limiting lifetime
>>>>> of tokens may not work in this case. In general the registration
>>>>> server should not allow the use of a single registration in this
>>>>> case. This case is different from the above in the sense that
>>>>> installed applications are typically _also_ using the 'code' flow,
>>>>> but from a different security context. A server could allow both
>>>>> clients to share the same registration information, but segregate
>>>>> the set of redirect URLs and tie the code to each security context
>>>>> and apply different client authentication requirements to each. Or
>>>>> the server could require separate client registration for each
>> component.
>>>>>=20
>>>>>>=20
>>>>>> EH
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Breno de Medeiros [mailto:breno@google.com]
>>>>>>> Sent: Thursday, March 15, 2012 2:12 PM
>>>>>>> To: Eran Hammer
>>>>>>> Cc: Nat Sakimura; OAuth WG
>>>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>>>>>>=20
>>>>>>> On Thu, Mar 15, 2012 at 13:13, Eran Hammer
>> 
>>>>>>> wrote:
>>>>>>>> Ok. That's much better than my guess that you wanted to drop
>>>>>>>> all the registration text from the specification.
>>>>>>>>=20
>>>>>>>> What I'm looking for is a simple text that answers the question:
>>>>>>>>=20
>>>>>>>> "What to do if my client isn't simply public or confidential?"
>>>>>>>>=20
>>>>>>>> If we just drop the current text, the answer is implicitly "you
>>>>>>>> can't have such a client" because there is no way to register a
>>>>>>>> client of any other type.
>>>>>>>>=20
>>>>>>>> So let's try this again, and focus exclusively on answering this
>> question.
>>>>>>>> My text takes a position which is, "you can't - unless". Your
>>>>>>>> suggestion is more of a vague discussion of the topic. I'd like
>>>>>>>> to see clear, normative answer to this question.
>>>>>>>=20
>>>>>>> The current version is normative but far from clear. In fact, the
>>>>>>> most natural interpretation is that it bans normal practice and
>>>>>>> throws away the work that was done in defining different flow
>>>>>>> types to
>>>> support normal practice.
>>>>>>>=20
>>>>>>> 1. I don't see the need or desirability to put normative language
>>>>>>> on registration practices.
>>>>>>> 2. The contents of said normative language are harmful.
>>>>>>>=20
>>>>>>> I suggest two alternatives:
>>>>>>>=20
>>>>>>> 1. Remove the language.
>>>>>>> 2. Substitute the language by non-normative informative discussion.
>>>>>>>=20
>>>>>>> You can also do other things, like introduce normative language
>>>>>>> that makes sense. But I have not yet seen proposed language that
>>>>>>> would be
>>>> acceptable.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> EH
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 3/15/12 12:30 PM, "Breno de Medeiros" 
>>>> wrote:
>>>>>>>>=20
>>>>>>>>> I am proposing the entire removal of:
>>>>>>>>>=20
>>>>>>>>> "A client application consisting of multiple components, each
>>>>>>>>> with its own client type (e.g. a distributed client with both a
>>>>>>>>> confidential server-based component and a public browser-based
>>>>>>>>> component), MUST register each component separately as a
>>>>>>>>> different client to ensure proper handling by the authorization
>> server."
>>>>>>>>>=20
>>>>>>>>> In particular the example of a server-side component versus
>>>>>>>>> browser-based components is particularly unhelpful since it
>>>>>>>>> violates the entire principle of why two response_type 'code'
>>>>>>>>> and 'token' were defined, and how OAuth2 is typically
>> implemented.
>>>>>>>>> That's when I claim this normative language is redefining the
>> protocol.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On Thu, Mar 15, 2012 at 12:13, Eran Hammer
>>>>>>>>> 
>>>>>>> wrote:
>>>>>>>>>> Which text in -25 are you proposing we remove exactly? I
>>>>>>>>>> can't judge the  text below without the full context of where
>>>>>>>>>> and how it is proposed in the  current document.
>>>>>>>>>>=20
>>>>>>>>>> Also, you are ignoring my detailed analysis of the current
>>>>>>>>>> facts. We have  two client types and the issue here is what to
>>>>>>>>>> do with other, undefined  types.
>>>>>>>>>>=20
>>>>>>>>>> EH
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On 3/15/12 11:54 AM, "Breno de Medeiros"
>> 
>>>>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> My proposal is to remove any reference to registration (which
>>>>>>>>>>> is a red herring and has raised all the problems we refer
>>>>>>>>>>> here) and refer to client authentication instead.
>>>>>>>>>>>=20
>>>>>>>>>>> Proposal:
>>>>>>>>>>>=20
>>>>>>>>>>> "Clients may be implemented as a distributed set of
>>>>>>>>>>> components that run in different security contexts. For
>>>>>>>>>>> instance, a single client may include a webserver component
>>>>>>>>>>> and a script component in a browser. It is not appropriate
>>>>>>>>>>> for the different components to utilize the same client
>>>>>>>>>>> authentication mechanisms, since client authentication
>>>>>>>>>>> credentials that are held securely in one context cannot be
>> deployed securely in another.
>>>>>>>>>>>=20
>>>>>>>>>>> Servers MUST mitigate security threats from client components
>>>>>>>>>>> that cannot hold client credentials as securely by
>>>>>>>>>>> distinguishing them from client components that can. Example
>>>>>>>>>>> of
>>>> suitable measures are:
>>>>>>>>>>>=20
>>>>>>>>>>> - Requiring separate registration of components such as web
>>>>>>>>>>> server and a mobile application.
>>>>>>>>>>> - Restricting the time validity of tokens issued to clients
>>>>>>>>>>> that hold no authentication credentials, such as browser
>>>>>>>>>>> script-based components."
>>>>>>>>>>>=20
>>>>>>>>>>> Please don't truncate explanations in the interest of space
>>>>>>>>>>> if the resulting text is confusing and possibly misleading.
>>>>>>>>>>> Better to say nothing instead.
>>>>>>>>>>>=20
>>>>>>>>>>> On Thu, Mar 15, 2012 at 11:32, Eran Hammer
>>>> 
>>>>>>> wrote:
>>>>>>>>>>>> Here are the facts:
>>>>>>>>>>>>=20
>>>>>>>>>>>> The authorization server must know the client type in order
>>>>>>>>>>>> to enforce many  of the requirements in the specification.
>>>>>>>>>>>> The requirement to provide a client type is not decorated
>>>>>>>>>>>> with a MUST or  SHALL but that is implied.
>>>>>>>>>>>> The specification only defines two client types: public and
>>>>>>>>>>>> confidential.
>>>>>>>>>>>> There is no client type defined for a hybrid client.
>>>>>>>>>>>> The specification needs to address the very common use case
>>>>>>>>>>>> of clients with  both public and private components.
>>>>>>>>>>>>=20
>>>>>>>>>>>> I don't want to discuss in the specification how client
>>>>>>>>>>>> identifiers are  provisioned, nor do I want to discuss the
>>>>>>>>>>>> potential binding of response  types to client types. But we
>>>>>>>>>>>> do need to provide some guidance to clients  and
>>>>>>>>>>>> authorization servers what to do with clients that do not
>>>>>>>>>>>> fit the  current type definitions.
>>>>>>>>>>>>=20
>>>>>>>>>>>> It is far too late for us to define a new client type,
>>>>>>>>>>>> along with all the  security considerations that such type
>>>>>>>>>>>> imply. Our entire security  consideration section and
>>>>>>>>>>>> protocol design are based on have a well defined  client type.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Requiring separate registration for each component is the
>>>>>>>>>>>> most straight-forward solution. Allowing the authorization
>>>>>>>>>>>> server to offer alternatives is the backdoor to enable
>> extensibility.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Within these constraints, I am open to other prose or
>>>>>>>>>>>> creative solutions.
>>>>>>>>>>>> But the add-ons proposed are all ugly hacks. They clarify
>>>>>>>>>>>> specific questions  raised which I do not believe represent
>>>>>>>>>>>> the core confusion here which is  what is the right way to
>>>>>>>>>>>> handle hybrid clients.
>>>>>>>>>>>>=20
>>>>>>>>>>>> The best way to move forward is to take a minute and ask
>>>>>>>>>>>> the group to share  how they handle such cases or how they
>>>>>>>>>>>> think they should be handled.
>>>>>>>>>>>> Based
>>>>>>>>>>>> on that we can come up with a clear solution.
>>>>>>>>>>>>=20
>>>>>>>>>>>> EH
>>>>>>>>>>>>=20
>>>>>>>>>>>> From: Breno de Medeiros 
>>>>>>>>>>>> Date: Thu, 15 Mar 2012 09:56:13 -0700
>>>>>>>>>>>> To: Eran Hammer-Lahav 
>>>>>>>>>>>> Cc: Nat Sakimura , OAuth WG
>>>>>>> 
>>>>>>>>>>>>=20
>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
>> rev.
>>>>>>>>>>>> 23
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer
>>>>>>>>>>>> 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> This add-on is unnecessary. It already says the
>>>>>>>>>>>>> authorization server can  handle it any way it wants. The
>>>>>>>>>>>>> fact that other registration options are  possible clearly
>>>>>>>>>>>>> covers the client identifier reuse case. As for the
>>>>>>>>>>>>> response type, that=C2=B9s not an issue but more of an
>> optimization for an edge  case raised.
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> It still feels like a horse by committee to me. "unless the
>>>>>>>>>>>> authorization server provides other registration options to
>>>>>>>>>>>> specify such  complex clients." seems a very round about way
>>>>>>>>>>>> to say that the core spec  already provides for such
>>>>>>>>>>>> arrangements in the most common scenario. It is a  bit of a
>>>>>>>>>>>> stretch to say that the server provides "other registration
>>>>>>>>>>>> options" by simply following strategy already laid out in the
>> spec.
>>>>>>>>>>>>=20
>>>>>>>>>>>> In particular, I feel that this wording will be harmful to
>>>>>>>>>>>> register extended  behavior, e.g., alternative
>>>>>>>>>>>> response_types by leading to fruitless  conversations about
>>>>>>>>>>>> spec compliance in the absence of real security risks.
>>>>>>>>>>>>=20
>>>>>>>>>>>> I do not believe the current text is the best
>>>>>>>>>>>> representation of the spirit  in which the spec was written
>>>>>>>>>>>> (in particular the effort to specify two flows  in detail to
>>>>>>>>>>>> deal with precisely this issue) and possibly lead to
>> harmful  future interpretation.
>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> EH
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
>>>> bounces@ietf.org]
>>>>>>>>>>>>> On Behalf Of  Nat Sakimura
>>>>>>>>>>>>> Sent: Thursday, March 15, 2012 2:04 AM
>>>>>>>>>>>>> To: Breno de Medeiros; OAuth WG
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
>> rev.
>>>>>>>>>>>>> 23
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> So, Eran's first proposal:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>  A client application consisting of multiple components,
>>>>>>>>>>>>> each with its
>>>>>>>>>>>>>  own client type (e.g. a distributed client with both a
>>>>>>>>>>>>> confidential
>>>>>>>>>>>>>  server-based component and a public browser-based
>>>>>>>>>>>>> component), MUST
>>>>>>>>>>>>>  register each component separately as a different client
>>>>>>>>>>>>> to ensure
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>  proper handling by the authorization server, unless the
>>>>>>>>>>>>> authorization
>>>>>>>>>>>>>  server provides other registration options to specify
>>>>>>>>>>>>> such complex  clients.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> kind of meets my concern. There seems to be another issue
>>>>>>>>>>>>> around the  usefulness of return_type in such case raised
>>>>>>>>>>>>> by Breno, and if I understand  it correctly, Eran's answer
>>>>>>>>>>>>> was that these separate components may have the  same
>>>>>>>>>>>>> client_id
>>>> so
>>>>>>>>>>>>> that return_type is a valid parameter to be sent at
>> the  request.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> So, to clarify these, perhaps changing the above text
>>>>>>>>>>>>> slightly to the following solves the problem?
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>  A client application consisting of multiple components,
>>>>>>>>>>>>> each with its
>>>>>>>>>>>>>  own client type (e.g. a distributed client with both a
>>>>>>>>>>>>> confidential
>>>>>>>>>>>>>  server-based component and a public browser-based
>>>>>>>>>>>>> component), MUST
>>>>>>>>>>>>>  register each component separately as a different client
>>>>>>>>>>>>> to ensure
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>  proper handling by the authorization server, unless the
>>>>>>>>>>>>> authorization
>>>>>>>>>>>>>  server provides other registration options to specify
>>>>>>>>>>>>> such complex  clients.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>  Each component MAY have the same client_id, in which
>>>>>>>>>>>>> case the server
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>  judges the client type and the associated security
>>>>>>>>>>>>> context based on
>>>>>>>>>>>>>  the response_type parameter in the request.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Would it solve your problem, Breno?
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> =3Dnat
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> --
>>>>>>>>>>>> --Breno
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> --
>>>>>>>>>>> --Breno
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> --
>>>>>>>>> --Breno
>>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>> --Breno
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> --
>>>>> --Breno
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Breno de Medeiros
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>> --
>> Breno de Medeiros
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From guang.g.yang@oracle.com  Sun Mar 18 21:15:51 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF96821F851B for ; Sun, 18 Mar 2012 21:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5V1mVZNnR6G for ; Sun, 18 Mar 2012 21:15:48 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7846121F8598 for ; Sun, 18 Mar 2012 21:15:48 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2J4Fk4k006609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Mar 2012 04:15:47 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2J4FkC5024601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Mar 2012 04:15:46 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2J4Fko0031578 for ; Sun, 18 Mar 2012 23:15:46 -0500
MIME-Version: 1.0
Message-ID: <12509c43-163e-43a6-bbf3-60d6daa1db43@default>
Date: Sun, 18 Mar 2012 21:15:45 -0700 (PDT)
From: Grant Yang 
Sender: Grant Yang 
To: Phil Hunt 
References: <1db661c5-2e54-470e-8104-ee8e7ae10e86@default> 
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL 12.0.6607.1000 (x86)]
Content-Type: multipart/alternative; boundary="__1332130545952224456abhmt117.oracle.com"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090205.4F66B2F3.00E1,ss=1,re=-2.300,fgs=0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 04:15:51 -0000

--__1332130545952224456abhmt117.oracle.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thank you very much Phil!=20

=C2=A0

The thing is, the Oauth spec just mentioned putting the Access Token into H=
TTP header =E2=80=9CAuthorization=E2=80=9D. I don=E2=80=99t think it applie=
s to SOAP as this header is not visible from SOAP stack perspective.

=C2=A0

So, when we talking about the soap header, are we talking about the header =
used by WS-Security? Could you please be kindly providing me one example on=
 putting the Access Token into SOAP header and let me know which product is=
 currently using this mechanism?=20

=C2=A0

Thanks a lot,
Grant.

=C2=A0

From: Phil Hunt=20
Sent: Thursday, March 15, 2012 11:53 PM
To: Grant Yang
Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services

=C2=A0

Grant,

=C2=A0

You put it in the soap header of course in the same spot as any other crede=
ntial. =C2=A0:-)

=C2=A0

Phil

=C2=A0

@independentid

HYPERLINK "http://www.independentid.com"www.independentid.com

HYPERLINK "mailto:phil.hunt@oracle.com"phil.hunt@oracle.com

=C2=A0





=C2=A0

On 2012-03-14, at 10:41 PM, Grant Yang wrote:





Hi all,

=C2=A0

We were discussing the possibility to use Oauth2 token on SOAP in our produ=
ct.

=C2=A0

The preferred way in mentioned in RFC is of course to put it to HTTP Author=
ization header, but in this case it will beyond the scope of SOAP stack and=
 I am not sure it shall be the correct way to go. It is also recognized tha=
t there is some implementation (such as salesforce) is using some SOAP head=
er (=E2=80=9CsessionId=E2=80=9D) to put this token, but it looks like a pri=
vate implementation and I did not find any specification supporting it.

=C2=A0

Could any experts here illustrate any organization or forum is working on u=
sing Oauth2 token for SOAP request? As there are quite some legacy SOAP bas=
ed web services, hopefully it is a question makes sense for you as well.

=C2=A0

Thoughts?

=C2=A0

Grant Yang

Architect, SDP of ORACLE Communications

=C2=A0

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

=C2=A0

--__1332130545952224456abhmt117.oracle.com
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Thank you very much Phil! 
 
The thing is, the Oauth spec just mentioned putting the Access =
Token into HTTP header “Authorization”. I don’t think it =
applies to SOAP as this header is not visible from SOAP stack perspective.<=
o:p>
 
So, when we talking=
 about the soap header, are we talking about the header used by WS-Security=
? Could you please be kindly providing me one example on putting the Access=
 Token into SOAP header and let me know which product is currently using th=
is mechanism? 
 
Than=
ks a lot,
Grant.
 
From: Phil Hunt 
Sent: Thursday, March 15, 201=
2 11:53 PM
To: Grant Yang
Subject: Re: [OAUTH-WG] Using=
 Oauth2 token to SOAP web services
 
Grant,
 
You put it in the soap header of course in the =
same spot as any other credential.  :-)
 
=

 


=

 <=
/span>
On 2012-03-14, =
at 10:41 PM, Grant Yang wrote:


Hi all,=

 
We w=
ere discussing the possibility to use Oauth2 token on SOAP in our product.<=
o:p>
 
The =
preferred way in mentioned in RFC is of course to put it to HTTP Authorizat=
ion header, but in this case it will beyond the scope of SOAP stack and I a=
m not sure it shall be the correct way to go. It is also recognized that th=
ere is some implementation (such as salesforce) is using some SOAP header (=
“sessionId”) to put this token, but it looks like a private imp=
lementation and I did not find any specification supporting it.<=
/span>
 
Could any expert=
s here illustrate any organization or forum is working on using Oauth2 toke=
n for SOAP request? As there are quite some legacy SOAP based web services,=
 hopefully it is a question makes sense for you as well.<=
/p>
 
Thoughts?
 
Grant Yang
Architect, SDP of ORACLE Communications<=
/span>
 
_______________________________________________
OAuth mailing list
=
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/=
oauth
 

--__1332130545952224456abhmt117.oracle.com--

From hannes.tschofenig@gmx.net  Mon Mar 19 00:05:45 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3AD21F84F5 for ; Mon, 19 Mar 2012 00:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.54
X-Spam-Level: 
X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk+zmIWRnCRc for ; Mon, 19 Mar 2012 00:05:44 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7403921F84F2 for ; Mon, 19 Mar 2012 00:05:44 -0700 (PDT)
Received: (qmail invoked by alias); 19 Mar 2012 07:05:42 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp019) with SMTP; 19 Mar 2012 08:05:42 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18UyncJ3T0UJlcDOUvSbr1xCPobEvM437BeUEKsmy xVnuRyPqNfLJxN
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Hannes Tschofenig 
X-Priority: 3
In-Reply-To: <12509c43-163e-43a6-bbf3-60d6daa1db43@default>
Date: Mon, 19 Mar 2012 09:05:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1db661c5-2e54-470e-8104-ee8e7ae10e86@default>  <12509c43-163e-43a6-bbf3-60d6daa1db43@default>
To: Grant Yang 
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 07:05:46 -0000

Hi Grant,=20

IMHO the main reason why the OAuth specification does not standardize =
OAuth usage specially for SOAP is because most people by now realized =
that SOAP, as another layer of encapsulation, does not add a lot of =
value.=20

Ciao
Hannes

On Mar 19, 2012, at 6:15 AM, Grant Yang wrote:

> Thank you very much Phil!
> =20
> The thing is, the Oauth spec just mentioned putting the Access Token =
into HTTP header =93Authorization=94. I don=92t think it applies to SOAP =
as this header is not visible from SOAP stack perspective.
> =20
> So, when we talking about the soap header, are we talking about the =
header used by WS-Security? Could you please be kindly providing me one =
example on putting the Access Token into SOAP header and let me know =
which product is currently using this mechanism?
> =20
> Thanks a lot,
> Grant.
> =20
> From: Phil Hunt=20
> Sent: Thursday, March 15, 2012 11:53 PM
> To: Grant Yang
> Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services
> =20
> Grant,
> =20
> You put it in the soap header of course in the same spot as any other =
credential.  :-)
> =20
> Phil
> =20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> =20
>=20
>=20
> =20
> On 2012-03-14, at 10:41 PM, Grant Yang wrote:
>=20
>=20
> Hi all,
> =20
> We were discussing the possibility to use Oauth2 token on SOAP in our =
product.
> =20
> The preferred way in mentioned in RFC is of course to put it to HTTP =
Authorization header, but in this case it will beyond the scope of SOAP =
stack and I am not sure it shall be the correct way to go. It is also =
recognized that there is some implementation (such as salesforce) is =
using some SOAP header (=93sessionId=94) to put this token, but it looks =
like a private implementation and I did not find any specification =
supporting it.
> =20
> Could any experts here illustrate any organization or forum is working =
on using Oauth2 token for SOAP request? As there are quite some legacy =
SOAP based web services, hopefully it is a question makes sense for you =
as well.
> =20
> Thoughts?
> =20
> Grant Yang
> Architect, SDP of ORACLE Communications
> =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 buhake@googlemail.com  Mon Mar 19 05:10:28 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637BA21F86A2 for ; Mon, 19 Mar 2012 05:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.752
X-Spam-Level: 
X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0R8jTqkPQJF for ; Mon, 19 Mar 2012 05:10:27 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 426BD21F869E for ; Mon, 19 Mar 2012 05:10:27 -0700 (PDT)
Received: by lagj5 with SMTP id j5so5506078lag.31 for ; Mon, 19 Mar 2012 05:10:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Xx57EHYYtvV+G6/BHZ5nDE5SUsQiSU5TLqSdJKiG/Ns=; b=Fz/NpJQbnv1zrnIEBbsEgQ5sf13Dch1jrXUuw2MoKGupWR2Vccvm2oOaQ+Z/eRTRGb 1kxT96W7vS2ExI1AldkPz53EK7uGDPD1oKQPCU0jeARMJ/4lbat5gj5mMFOZHZZpFmFM 48DSV8bzmkRi2Vmo4RStR4iUpH8ceaWCr5TRpyJapUDl1mX9EnxyRKqrgXRvqnjZv6Om iUOeHvKo44WOzcbuV03u4jnx98QnUi2eJYUL9jf0EzjCiSpGuc0ZmOoMfo4oOmpWmyOq TBuSJ9euaIAkS+agXOfrgu+ASOPXs6lwn3k8VfB9HqphRHSnZQQx0wlMkJj8oKLk7n76 h6cg==
Received: by 10.152.102.173 with SMTP id fp13mr8971165lab.38.1332159026181; Mon, 19 Mar 2012 05:10:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.128.200 with HTTP; Mon, 19 Mar 2012 05:10:06 -0700 (PDT)
From: Buhake Sindi 
Date: Mon, 19 Mar 2012 14:10:06 +0200
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=f46d040716c78a378204bb977179
Subject: [OAUTH-WG] Error in draft-ietf-oauth-v2-http-mac-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 12:10:28 -0000

--f46d040716c78a378204bb977179
Content-Type: text/plain; charset=UTF-8

Hi guys,

In the above mentioned draft, the example on chapter 1.1 shows a timestamp
as date long, like:

GET /resource/1?b=1&a=2 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
*ts="1336363200"*,
nonce="dj83hs9s",
mac="bhCQXTVyfj5cmA9uKkPFx1zeOXM="

In chapter 3.2.1, it states:

"using *timestamp 264095:7d8f3e4a*, nonce 7d8f3e4a, and extension string
a,b,c is ..." (where timestamp is a concatenation of ts + ":" + nonce).

Is this an error or what is the correct way to populate ts (timestamp) for
MAC header attributes?


Regards,



Buhake Sindi

-- 
The Elite Gentleman

--f46d040716c78a378204bb977179
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi guys,

In the above mentioned draft, the example on chapter 1.1 sh=
ows a timestamp as date long, like:

GET /resource/1?b=3D1&a=3D2 =
HTTP/1.1
Host: example.com
Authori=
zation: MAC id=3D"h480djs93hd8",


ts=3D"1336363200",
nonce=3D"dj83hs9s",
mac=
=3D"bhCQXTVyfj5cmA9uKkPFx1zeOXM=3D"

In chapter 3.2.1, it s=
tates:

"using timestamp 264095:7d8f3e4a, nonce 7d8f3e4a,=
 and extension string a,b,c is ..." (where timestamp is a concatenatio=
n of ts + ":" + nonce).



Is this an error or what is the correct way to populate ts (timestamp) =
for MAC header attributes?


Regards,



Buhake Sindi<=
br clear=3D"all">
-- 
The Elite Gentleman


--f46d040716c78a378204bb977179--

From phil.hunt@oracle.com  Mon Mar 19 06:23:56 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD93F21F84DA for ; Mon, 19 Mar 2012 06:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.673
X-Spam-Level: 
X-Spam-Status: No, score=-9.673 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhIGmotpy-eE for ; Mon, 19 Mar 2012 06:23:55 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1446121F84C5 for ; Mon, 19 Mar 2012 06:23:55 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2JDNq8W013153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Mar 2012 13:23:53 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2JDNp9b027343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2012 13:23:52 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2JDNpMi014327; Mon, 19 Mar 2012 08:23:51 -0500
Received: from [192.168.1.125] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Mar 2012 06:23:51 -0700
References: <1db661c5-2e54-470e-8104-ee8e7ae10e86@default>  <12509c43-163e-43a6-bbf3-60d6daa1db43@default> 
In-Reply-To: 
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Message-Id: <835C2B6E-3A48-4894-A75E-B802FB12DD1C@oracle.com>
X-Mailer: iPhone Mail (9B179)
From: Phil Hunt 
Date: Mon, 19 Mar 2012 06:23:50 -0700
To: Hannes Tschofenig 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F673369.0077,ss=1,re=0.000,fgs=0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 13:23:56 -0000

There's going to be a lot of mixed environments for some time. Particularly a=
n issue at the boundaries between classic soap services and new restful serv=
ices. =20

Phil

On 2012-03-19, at 0:05, Hannes Tschofenig  wrote:=


> Hi Grant,=20
>=20
> IMHO the main reason why the OAuth specification does not standardize OAut=
h usage specially for SOAP is because most people by now realized that SOAP,=
 as another layer of encapsulation, does not add a lot of value.=20
>=20
> Ciao
> Hannes
>=20
> On Mar 19, 2012, at 6:15 AM, Grant Yang wrote:
>=20
>> Thank you very much Phil!
>>=20
>> The thing is, the Oauth spec just mentioned putting the Access Token into=
 HTTP header =E2=80=9CAuthorization=E2=80=9D. I don=E2=80=99t think it appli=
es to SOAP as this header is not visible from SOAP stack perspective.
>>=20
>> So, when we talking about the soap header, are we talking about the heade=
r used by WS-Security? Could you please be kindly providing me one example o=
n putting the Access Token into SOAP header and let me know which product is=
 currently using this mechanism?
>>=20
>> Thanks a lot,
>> Grant.
>>=20
>> From: Phil Hunt=20
>> Sent: Thursday, March 15, 2012 11:53 PM
>> To: Grant Yang
>> Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services
>>=20
>> Grant,
>>=20
>> You put it in the soap header of course in the same spot as any other cre=
dential.  :-)
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2012-03-14, at 10:41 PM, Grant Yang wrote:
>>=20
>>=20
>> Hi all,
>>=20
>> We were discussing the possibility to use Oauth2 token on SOAP in our pro=
duct.
>>=20
>> The preferred way in mentioned in RFC is of course to put it to HTTP Auth=
orization header, but in this case it will beyond the scope of SOAP stack an=
d I am not sure it shall be the correct way to go. It is also recognized tha=
t there is some implementation (such as salesforce) is using some SOAP heade=
r (=E2=80=9CsessionId=E2=80=9D) to put this token, but it looks like a priva=
te implementation and I did not find any specification supporting it.
>>=20
>> Could any experts here illustrate any organization or forum is working on=
 using Oauth2 token for SOAP request? As there are quite some legacy SOAP ba=
sed web services, hopefully it is a question makes sense for you as well.
>>=20
>> Thoughts?
>>=20
>> Grant Yang
>> Architect, SDP of ORACLE Communications
>>=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 paul.madsen@gmail.com  Mon Mar 19 06:29:07 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AAB21F850C for ; Mon, 19 Mar 2012 06:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWaimPxI2E5E for ; Mon, 19 Mar 2012 06:29:05 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A60B321F84F8 for ; Mon, 19 Mar 2012 06:29:05 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so6138030ggm.31 for ; Mon, 19 Mar 2012 06:29:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=K8bHnumFu9hrnsmJZa4NEbRszSeWxR1OTdl5kWOJEOI=; b=GtWOPZdCgO5KIi3nw5UNUJxn8CxIb/e9NbOhuVtkQ7AfFHknHk5QC1pQFjhzkbvFTv uDGiWmUX7rwr7x3KoXzEaoJul1sP6hsABHRVa1LOkg+qxtcnfborZxGcIt/dXEGADSWd 4KPBRWU2OY81WOn16c2+GS1WrAW2D+2M7E9Drw+joDeAP7QXtL56bqF7dbSO+4CDuoSY H32BaTx/c79ci6oB2sOVs3Meb9LcRD63IM0mW5Wfke34RimYP/6ylTzGSwQwY4rsJ0De l4MaEFRc4TEcZi7ZNgkIU6o7qxGub3CyiQ8IUfCMhWTa82K5AUT3YSFu2j++PXuRJaLf clYA==
Received: by 10.50.45.229 with SMTP id q5mr5828298igm.62.1332163744676; Mon, 19 Mar 2012 06:29:04 -0700 (PDT)
Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.162.33]) by mx.google.com with ESMTPS id ez5sm5578053igb.17.2012.03.19.06.29.02 (version=SSLv3 cipher=OTHER); Mon, 19 Mar 2012 06:29:03 -0700 (PDT)
Message-ID: <4F67349E.107@gmail.com>
Date: Mon, 19 Mar 2012 09:29:02 -0400
From: Paul Madsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Phil Hunt 
References: <1db661c5-2e54-470e-8104-ee8e7ae10e86@default>  <12509c43-163e-43a6-bbf3-60d6daa1db43@default>  <835C2B6E-3A48-4894-A75E-B802FB12DD1C@oracle.com>
In-Reply-To: <835C2B6E-3A48-4894-A75E-B802FB12DD1C@oracle.com>
Content-Type: multipart/alternative; boundary="------------060404010400070307040500"
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 13:29:07 -0000

This is a multi-part message in MIME format.
--------------060404010400070307040500
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

mixed REST & SOAP environments dont necessarily require using OAuth 
tokens directly in SOAP headers  - you can exchange the token for an 
equivalent SAML assertion (for which we already have a profile 
stipulating how to use in SOAP headers)

We see alot of this - people leveraging existing SOAP backends but 
opening up REST APIs to partners & mobile

On 3/19/12 9:23 AM, Phil Hunt wrote:
> There's going to be a lot of mixed environments for some time. Particularly an issue at the boundaries between classic soap services and new restful services.
>
> Phil
>
> On 2012-03-19, at 0:05, Hannes Tschofenig  wrote:
>
>> Hi Grant,
>>
>> IMHO the main reason why the OAuth specification does not standardize OAuth usage specially for SOAP is because most people by now realized that SOAP, as another layer of encapsulation, does not add a lot of value.
>>
>> Ciao
>> Hannes
>>
>> On Mar 19, 2012, at 6:15 AM, Grant Yang wrote:
>>
>>> Thank you very much Phil!
>>>
>>> The thing is, the Oauth spec just mentioned putting the Access Token into HTTP header “Authorizationâ€. I don’t think it applies to SOAP as this header is not visible from SOAP stack perspective.
>>>
>>> So, when we talking about the soap header, are we talking about the header used by WS-Security? Could you please be kindly providing me one example on putting the Access Token into SOAP header and let me know which product is currently using this mechanism?
>>>
>>> Thanks a lot,
>>> Grant.
>>>
>>> From: Phil Hunt
>>> Sent: Thursday, March 15, 2012 11:53 PM
>>> To: Grant Yang
>>> Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services
>>>
>>> Grant,
>>>
>>> You put it in the soap header of course in the same spot as any other credential.  :-)
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>
>>>
>>>
>>>
>>>
>>> On 2012-03-14, at 10:41 PM, Grant Yang wrote:
>>>
>>>
>>> Hi all,
>>>
>>> We were discussing the possibility to use Oauth2 token on SOAP in our product.
>>>
>>> The preferred way in mentioned in RFC is of course to put it to HTTP Authorization header, but in this case it will beyond the scope of SOAP stack and I am not sure it shall be the correct way to go. It is also recognized that there is some implementation (such as salesforce) is using some SOAP header (“sessionIdâ€) to put this token, but it looks like a private implementation and I did not find any specification supporting it.
>>>
>>> Could any experts here illustrate any organization or forum is working on using Oauth2 token for SOAP request? As there are quite some legacy SOAP based web services, hopefully it is a question makes sense for you as well.
>>>
>>> Thoughts?
>>>
>>> Grant Yang
>>> Architect, SDP of ORACLE Communications
>>>
>>> _______________________________________________
>>> 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

--------------060404010400070307040500
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    mixed REST & SOAP environments dont
      necessarily require using OAuth tokens directly in SOAP
    headers  - you can exchange the token for an equivalent SAML
    assertion (for which we already have a profile stipulating how to
    use in SOAP headers)

    

    We see alot of this - people leveraging existing SOAP backends but
    opening up REST APIs to partners & mobile

    

    On 3/19/12 9:23 AM, Phil Hunt wrote:
    

      
There's going to be a lot of mixed environments for some time. Particularly an issue at the boundaries between classic soap services and new restful services.  

Phil

On 2012-03-19, at 0:05, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:



      

        
Hi Grant, 

IMHO the main reason why the OAuth specification does not standardize OAuth usage specially for SOAP is because most people by now realized that SOAP, as another layer of encapsulation, does not add a lot of value. 

Ciao
Hannes

On Mar 19, 2012, at 6:15 AM, Grant Yang wrote:



        

          
Thank you very much Phil!

The thing is, the Oauth spec just mentioned putting the Access Token into HTTP header “Authorizationâ€. I don’t think it applies to SOAP as this header is not visible from SOAP stack perspective.

So, when we talking about the soap header, are we talking about the header used by WS-Security? Could you please be kindly providing me one example on putting the Access Token into SOAP header and let me know which product is currently using this mechanism?

Thanks a lot,
Grant.

From: Phil Hunt 
Sent: Thursday, March 15, 2012 11:53 PM
To: Grant Yang
Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services

Grant,

You put it in the soap header of course in the same spot as any other credential.  :-)

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-03-14, at 10:41 PM, Grant Yang wrote:


Hi all,

We were discussing the possibility to use Oauth2 token on SOAP in our product.

The preferred way in mentioned in RFC is of course to put it to HTTP Authorization header, but in this case it will beyond the scope of SOAP stack and I am not sure it shall be the correct way to go. It is also recognized that there is some implementation (such as salesforce) is using some SOAP header (“sessionIdâ€) to put this token, but it looks like a private implementation and I did not find any specification supporting it.

Could any experts here illustrate any organization or forum is working on using Oauth2 token for SOAP request? As there are quite some legacy SOAP based web services, hopefully it is a question makes sense for you as well.

Thoughts?

Grant Yang
Architect, SDP of ORACLE Communications

_______________________________________________
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


    

  


--------------060404010400070307040500--

From romeda@gmail.com  Mon Mar 19 08:24:47 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9434921F8811 for ; Mon, 19 Mar 2012 08:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I69nrr3NhOxJ for ; Mon, 19 Mar 2012 08:24:45 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E18C21F87F8 for ; Mon, 19 Mar 2012 08:24:44 -0700 (PDT)
Received: by lagj5 with SMTP id j5so5688712lag.31 for ; Mon, 19 Mar 2012 08:24:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=zx03ml/4Dyu3QqObb3PnxLtrxGWC2rv53k13/vy5GmE=; b=uyEx0nE/SAyTzjTgk64aRSIOnK84vQ9ouI3MQLIWszjHQOc/FuYILiFYpI0y4eBwAE 7YrnosX159EIY9NlV2gbzpwLfE2FwuwluSaBUru7FIuOne7FIV6gehz2kTLEsNOf0dpm kNOQUeJXq5sssihNWXcWroSUuWg2U05qOUUfMc9YjEvM5phauVqWJl/k8hBuTlPOVfeZ ZekV0JMBhpN6KkpY2x2ov7QNHexvxM/PMfJgN0W2VlxuPaN9X1/EXsB1O+d37RD7NTqf +quQ5+CBrKJGahxVf7Xp8bV6UXc54hYHuaG9/33IskeBE99TMOwBSqODQrVpMbtC96s8 2pAg==
Received: by 10.112.38.195 with SMTP id i3mr4874410lbk.21.1332170683351; Mon, 19 Mar 2012 08:24:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.4.166 with HTTP; Mon, 19 Mar 2012 08:24:23 -0700 (PDT)
In-Reply-To: <5710F82C0E73B04FA559560098BF95B1250DCE94E0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References:  <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com> <5710F82C0E73B04FA559560098BF95B1250DCE94E0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
From: Blaine Cook 
Date: Mon, 19 Mar 2012 15:24:23 +0000
Message-ID: 
To: "Zeltsan, Zachary (Zachary)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 15:24:47 -0000

On 15 March 2012 17:31, Zeltsan, Zachary (Zachary)
 wrote:
> ...=C2=A0 Considering OpenID Connect as a motivating use case for OAuth, =
SWD is
> the one spec that would then be missing for this OAuth use case.

I worry that bringing OpenID Connect into OAuth (rather than building
upon OAuth) will have detrimental effects for both efforts. OAuth is
successful in part because we chose not to push OAuth-like
functionality into the OpenID umbrella (which at the time was focused
on shipping OpenID 2.0).

It seems prudent to learn from the experience of WS-*, where
everything was combined into one huge ball of standards-wax. The
result was both impenetrable and not fit for purpose due to the many
interdependencies (both social and technical) involved.

Composition has served the IETF and the internet well, and nothing
prevents the OpenID standards from being created in the context of a
new working group, or from within the OpenID foundation. Indeed, it's
been working quite well, and projects like the Account Chooser are
showing great promise and focusing on the important things (UX) rather
than specifications-for-specification's sake.

b.

From ve7jtb@ve7jtb.com  Mon Mar 19 09:31:57 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7F621F8865 for ; Mon, 19 Mar 2012 09:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level: 
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIFSO+HS7Uuw for ; Mon, 19 Mar 2012 09:31:57 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 018B721F885E for ; Mon, 19 Mar 2012 09:31:56 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so6372788ghb.31 for ; Mon, 19 Mar 2012 09:31:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=RRX4DneZALRoV5r4wjpi4+FBs8KFCa1Vl33YyeZhd1Q=; b=AMQqpNy7VX4FNA6HeQgYEggH28LpV+TDG2SNYJogjN0/tZBbmJsoLg+Gynyni7SldU 12V0d6MLS/8x5QJQNaQnoKvvr5J4lieS3uRSamT3pAnmiGJz1FrKzn2sMa17gZyxfcKc awqFn+DJ0r98xZWdG9xLF8KBHyhrqq4WN43xLaI/m+Y4LBwM5B9Y0tMjqGaILREZo3iJ NzorD7BLeGeVdSHmJccCfwqw2WtF9dA5x18qtHkG9WSghj0BAm9OUOIT+F7FPjBcQDTW i4aQFxRCUazy25BakVXsypN42MtPdFG4hh8hVpOYES9ZvYPUrSXE84lcq+GhsT1GPsS9 uO8Q==
Received: by 10.236.187.6 with SMTP id x6mr1070640yhm.12.1332174716322; Mon, 19 Mar 2012 09:31:56 -0700 (PDT)
Received: from [192.168.1.213] ([190.20.24.135]) by mx.google.com with ESMTPS id 2sm9373968ane.12.2012.03.19.09.31.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 09:31:54 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_A677CF77-976E-4CDE-B5CD-7EF1E1624137"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: 
Date: Mon, 19 Mar 2012 13:31:26 -0300
Message-Id: 
References:  <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com> <5710F82C0E73B04FA559560098BF95B1250DCE94E0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 
To: Blaine Cook 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQlJap4Uvuv7QpJ2ajXmQKzgBmOgqZWnjENkV9yyBQLdEatWk5GrTPmg1AWT+lKbTr03irC5
Cc: "oauth@ietf.org WG" , jose@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 16:31:57 -0000

--Apple-Mail=_A677CF77-976E-4CDE-B5CD-7EF1E1624137
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

There is not intention to bring the openID Connect work to the OAuth WG.
It like many other protocols rely on OAuth 2.0 but are not part of it.

However if there are some things that we are doing as OAuth 2.0 =
extensions
that are more general and can be standardized in the IETF, we should =
understand=20
what they are. =20

We are having a openID Connect meeting on Sunday prior to IETF.
People are encouraged to attend and refine opinions about the =
appropriate homes
for some of this new(to IETF) work.

Registration is at:
http://www.eventbrite.com/event/3064019565

The account chooser WG that Blaine mentioned at OIDF is up and running =
now, with a online meeting happening=20
Thursday for those that are interested.
https://sites.google.com/site/oidfacwg/
http://acwg2012march-estw.eventbrite.com

So +1 for composition.

John B.

On 2012-03-19, at 12:24 PM, Blaine Cook wrote:

> On 15 March 2012 17:31, Zeltsan, Zachary (Zachary)
>  wrote:
>> ...  Considering OpenID Connect as a motivating use case for OAuth, =
SWD is
>> the one spec that would then be missing for this OAuth use case.
>=20
> I worry that bringing OpenID Connect into OAuth (rather than building
> upon OAuth) will have detrimental effects for both efforts. OAuth is
> successful in part because we chose not to push OAuth-like
> functionality into the OpenID umbrella (which at the time was focused
> on shipping OpenID 2.0).
>=20
> It seems prudent to learn from the experience of WS-*, where
> everything was combined into one huge ball of standards-wax. The
> result was both impenetrable and not fit for purpose due to the many
> interdependencies (both social and technical) involved.
>=20
> Composition has served the IETF and the internet well, and nothing
> prevents the OpenID standards from being created in the context of a
> new working group, or from within the OpenID foundation. Indeed, it's
> been working quite well, and projects like the Account Chooser are
> showing great promise and focusing on the important things (UX) rather
> than specifications-for-specification's sake.
>=20
> b.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_A677CF77-976E-4CDE-B5CD-7EF1E1624137
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMx
OTE2MzEyN1owIwYJKoZIhvcNAQkEMRYEFHEfHWmqJnI7Ax/bczahliVelMFhMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AJYXS0V2mZ2WM+H7mmO5McQJTCRgFF5+D6yfdb1orqujSme7oBs2RFePqyk/lRVMqEXPn9XVC4gJ
636WGghYY1rBm9qLmEjBMfEbF2O0CO2Ycb1qGAuXqHAhn43AA+A/ta1DY0FBfEpWYdwOuTmJEGXD
y4t9h1lD7c9SNN3TsAsfYMuyljxaABPr4DMagEIln6nKLCnUBeKc43uUa14W3Au08qiKRCcT4yBM
YdxJtT0eL7jawl/qmhmsyl4kn2r3Cgw+Z9G2o9rKgyYBRPLvmmt1Sksq6izpxVppLY4rmv9l2Y7q
lN0drF22h7i/5+v3cp7f7gHTFbVNm4oab6ImHGQAAAAAAAA=

--Apple-Mail=_A677CF77-976E-4CDE-B5CD-7EF1E1624137--

From phil.hunt@oracle.com  Mon Mar 19 10:31:01 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE5421F8843; Mon, 19 Mar 2012 10:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.353
X-Spam-Level: 
X-Spam-Status: No, score=-9.353 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FprBtnhFpvqF; Mon, 19 Mar 2012 10:31:00 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id C344521F8839; Mon, 19 Mar 2012 10:31:00 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2JHUw32006964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Mar 2012 17:30:59 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2JHUunD009381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2012 17:30:57 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2JHUuqp012593; Mon, 19 Mar 2012 12:30:56 -0500
Received: from [192.168.1.19] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Mar 2012 10:30:56 -0700
References:  <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com> <5710F82C0E73B04FA559560098BF95B1250DCE94E0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>  
In-Reply-To: 
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: 
X-Mailer: iPhone Mail (9B179)
From: Phil Hunt 
Date: Mon, 19 Mar 2012 10:30:51 -0700
To: John Bradley 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F676D53.0079,ss=1,re=0.000,fgs=0
Cc: "oauth@ietf.org WG" , "jose@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 17:31:01 -0000

I would support those features of connect that are more general being part o=
f the general spec family under the WG.=20

Phil

On 2012-03-19, at 9:31, John Bradley  wrote:

> There is not intention to bring the openID Connect work to the OAuth WG.
> It like many other protocols rely on OAuth 2.0 but are not part of it.
>=20
> However if there are some things that we are doing as OAuth 2.0 extensions=

> that are more general and can be standardized in the IETF, we should under=
stand=20
> what they are. =20
>=20
> We are having a openID Connect meeting on Sunday prior to IETF.
> People are encouraged to attend and refine opinions about the appropriate h=
omes
> for some of this new(to IETF) work.
>=20
> Registration is at:
> http://www.eventbrite.com/event/3064019565
>=20
> The account chooser WG that Blaine mentioned at OIDF is up and running now=
, with a online meeting happening=20
> Thursday for those that are interested.
> https://sites.google.com/site/oidfacwg/
> http://acwg2012march-estw.eventbrite.com
>=20
> So +1 for composition.
>=20
> John B.
>=20
> On 2012-03-19, at 12:24 PM, Blaine Cook wrote:
>=20
>> On 15 March 2012 17:31, Zeltsan, Zachary (Zachary)
>>  wrote:
>>> ...  Considering OpenID Connect as a motivating use case for OAuth, SWD i=
s
>>> the one spec that would then be missing for this OAuth use case.
>>=20
>> I worry that bringing OpenID Connect into OAuth (rather than building
>> upon OAuth) will have detrimental effects for both efforts. OAuth is
>> successful in part because we chose not to push OAuth-like
>> functionality into the OpenID umbrella (which at the time was focused
>> on shipping OpenID 2.0).
>>=20
>> It seems prudent to learn from the experience of WS-*, where
>> everything was combined into one huge ball of standards-wax. The
>> result was both impenetrable and not fit for purpose due to the many
>> interdependencies (both social and technical) involved.
>>=20
>> Composition has served the IETF and the internet well, and nothing
>> prevents the OpenID standards from being created in the context of a
>> new working group, or from within the OpenID foundation. Indeed, it's
>> been working quite well, and projects like the Account Chooser are
>> showing great promise and focusing on the important things (UX) rather
>> than specifications-for-specification's sake.
>>=20
>> b.
>> _______________________________________________
>> 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 ve7jtb@ve7jtb.com  Mon Mar 19 10:53:02 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A6821F88B5 for ; Mon, 19 Mar 2012 10:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Level: 
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=-0.130,  BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHJyzmL1PpDf for ; Mon, 19 Mar 2012 10:53:01 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F44021F889A for ; Mon, 19 Mar 2012 10:53:01 -0700 (PDT)
Received: by yenm5 with SMTP id m5so6462202yen.31 for ; Mon, 19 Mar 2012 10:53:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=4YSzAb9FvkzWPNqAazFIeJBaqi5hOrRWSe834t5VarI=; b=QucIygrAYssbNdnnhAe12p/rH63skRQnT9JRAnD3xUQABEdIlMinK1qp32gmTahJit RSzl89I65BnVhMb3ifGTWCn1GnHdscSMlOREP/XqLJ0yiCUdR/EyKZDoSKI/jLCtsT0O urZVgHqKz6cxsKGqOfRo4buroS/IZZWAu5+etDat86YKN0R1OEiYqHkvdxAGlmXx8fTA NU0aMZqSelbAdl5jn8nSCzRZIKqyB3bqJgQEGLgLYr6jSWeM030MnZapdVX81wDSTW3r 8THqiVR7P+BmKP2gA2p4xKErDlc5WNiyC3lxt1Xt6cI9r5Oc+gsYCSX7ibLe/TQegP+0 rsCA==
Received: by 10.101.129.7 with SMTP id g7mr4432048ann.12.1332179580901; Mon, 19 Mar 2012 10:53:00 -0700 (PDT)
Received: from [192.168.1.213] ([190.20.24.135]) by mx.google.com with ESMTPS id g21sm17581997ani.13.2012.03.19.10.52.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 10:52:57 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_356BE533-FE10-4347-BB29-1E367C53F098"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: 
Date: Mon, 19 Mar 2012 14:52:25 -0300
Message-Id: <0A63B04E-D572-4111-B412-DB0B281E3088@ve7jtb.com>
References:  <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com> <5710F82C0E73B04FA559560098BF95B1250DCE94E0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>   
To: Phil Hunt 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQk33E+5SSkKa/KJLXqAMYWiaapwoT9Oa/bLTjjzKrD7X5Bp8I+b5Acg9IDC1deBo4NGuQjr
Cc: "oauth@ietf.org WG" , "jose@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 17:53:02 -0000

--Apple-Mail=_356BE533-FE10-4347-BB29-1E367C53F098
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

JWT and SWD are the highest priority to find a home.  =20

We are doing token introspection and dynamic registration.
Those are larger tasks to generalize, though probably worthwhile.

John B.
On 2012-03-19, at 2:30 PM, Phil Hunt wrote:

> I would support those features of connect that are more general being =
part of the general spec family under the WG.=20
>=20
> Phil
>=20
> On 2012-03-19, at 9:31, John Bradley  wrote:
>=20
>> There is not intention to bring the openID Connect work to the OAuth =
WG.
>> It like many other protocols rely on OAuth 2.0 but are not part of =
it.
>>=20
>> However if there are some things that we are doing as OAuth 2.0 =
extensions
>> that are more general and can be standardized in the IETF, we should =
understand=20
>> what they are. =20
>>=20
>> We are having a openID Connect meeting on Sunday prior to IETF.
>> People are encouraged to attend and refine opinions about the =
appropriate homes
>> for some of this new(to IETF) work.
>>=20
>> Registration is at:
>> http://www.eventbrite.com/event/3064019565
>>=20
>> The account chooser WG that Blaine mentioned at OIDF is up and =
running now, with a online meeting happening=20
>> Thursday for those that are interested.
>> https://sites.google.com/site/oidfacwg/
>> http://acwg2012march-estw.eventbrite.com
>>=20
>> So +1 for composition.
>>=20
>> John B.
>>=20
>> On 2012-03-19, at 12:24 PM, Blaine Cook wrote:
>>=20
>>> On 15 March 2012 17:31, Zeltsan, Zachary (Zachary)
>>>  wrote:
>>>> ...  Considering OpenID Connect as a motivating use case for OAuth, =
SWD is
>>>> the one spec that would then be missing for this OAuth use case.
>>>=20
>>> I worry that bringing OpenID Connect into OAuth (rather than =
building
>>> upon OAuth) will have detrimental effects for both efforts. OAuth is
>>> successful in part because we chose not to push OAuth-like
>>> functionality into the OpenID umbrella (which at the time was =
focused
>>> on shipping OpenID 2.0).
>>>=20
>>> It seems prudent to learn from the experience of WS-*, where
>>> everything was combined into one huge ball of standards-wax. The
>>> result was both impenetrable and not fit for purpose due to the many
>>> interdependencies (both social and technical) involved.
>>>=20
>>> Composition has served the IETF and the internet well, and nothing
>>> prevents the OpenID standards from being created in the context of a
>>> new working group, or from within the OpenID foundation. Indeed, =
it's
>>> been working quite well, and projects like the Account Chooser are
>>> showing great promise and focusing on the important things (UX) =
rather
>>> than specifications-for-specification's sake.
>>>=20
>>> b.
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_356BE533-FE10-4347-BB29-1E367C53F098
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMx
OTE3NTIyNlowIwYJKoZIhvcNAQkEMRYEFG9qdwnQTrUwgLdgx9h1paBLSjmXMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AD0NO319OL8XzpLryAw7qPK8/bgji0bFOcOl0iJ6snQdj0ZPDv0VmKwNZ2WTkJnH22RywNpizpSn
kcw9Rh923yTa6H2U1EIP5PHcfLaVV2V8r/KL2E6CAvfUmZUBzVUsCSZSHFmeNIcnGYTkSg0LAWq+
VAAMjqpBCsp/8LbSuvIGOdwVWxwV+C6x+4/m1SoANq77chIiwvkhhkOr5AzRUBFqhQ8unyXNTNvJ
bCbyNSuFwz9s2xhIPJb4TyT5Nz/1oMAPRxK3CAhe1AOlZHyu0t3//3J4Ia2VuE2L5b7R00vglm+y
ChUCRNFO29NDX8dB8O77ndegx3TQC+AVwyzS97wAAAAAAAA=

--Apple-Mail=_356BE533-FE10-4347-BB29-1E367C53F098--

From igor.faynberg@alcatel-lucent.com  Mon Mar 19 11:11:31 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9419721F87B0 for ; Mon, 19 Mar 2012 11:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.562
X-Spam-Level: 
X-Spam-Status: No, score=-7.562 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSIuPFQZmz91 for ; Mon, 19 Mar 2012 11:11:30 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 064BD21F8489 for ; Mon, 19 Mar 2012 11:11:29 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q2JIBRUX013099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Mar 2012 13:11:27 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2JIBRma015551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Mar 2012 13:11:27 -0500
Received: from [135.222.232.245] (USMUYN0L055118.mh.lucent.com [135.222.232.245]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2JIBQaT017162; Mon, 19 Mar 2012 13:11:27 -0500 (CDT)
Message-ID: <4F6776E9.2000902@alcatel-lucent.com>
Date: Mon, 19 Mar 2012 14:11:53 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: oauth@ietf.org
References: <1db661c5-2e54-470e-8104-ee8e7ae10e86@default>		<12509c43-163e-43a6-bbf3-60d6daa1db43@default>	 <835C2B6E-3A48-4894-A75E-B802FB12DD1C@oracle.com>
In-Reply-To: <835C2B6E-3A48-4894-A75E-B802FB12DD1C@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 18:11:31 -0000

Phil is right!  I observe the same thing: the frond-end is RESTful; the 
back-end is mixed.  Personally, I think it would be good for OAuth to be 
deployed as wide as possible.  (The SAML/OAuth  ideas I think are 
working the same problem.)

Igor

On 3/19/2012 9:23 AM, Phil Hunt wrote:
> There's going to be a lot of mixed environments for some time. Particularly an issue at the boundaries between classic soap services and new restful services.
>
> Phil
>
> On 2012-03-19, at 0:05, Hannes Tschofenig  wrote:
>
>> Hi Grant,
>>
>> IMHO the main reason why the OAuth specification does not standardize OAuth usage specially for SOAP is because most people by now realized that SOAP, as another layer of encapsulation, does not add a lot of value.
>>
>> Ciao
>> Hannes
>>
>> On Mar 19, 2012, at 6:15 AM, Grant Yang wrote:
>>
>>> Thank you very much Phil!
>>>
>>> The thing is, the Oauth spec just mentioned putting the Access Token into HTTP header “Authorizationâ€. I don’t think it applies to SOAP as this header is not visible from SOAP stack perspective.
>>>
>>> So, when we talking about the soap header, are we talking about the header used by WS-Security? Could you please be kindly providing me one example on putting the Access Token into SOAP header and let me know which product is currently using this mechanism?
>>>
>>> Thanks a lot,
>>> Grant.
>>>
>>> From: Phil Hunt
>>> Sent: Thursday, March 15, 2012 11:53 PM
>>> To: Grant Yang
>>> Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services
>>>
>>> Grant,
>>>
>>> You put it in the soap header of course in the same spot as any other credential.  :-)
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>
>>>
>>>
>>>
>>>
>>> On 2012-03-14, at 10:41 PM, Grant Yang wrote:
>>>
>>>
>>> Hi all,
>>>
>>> We were discussing the possibility to use Oauth2 token on SOAP in our product.
>>>
>>> The preferred way in mentioned in RFC is of course to put it to HTTP Authorization header, but in this case it will beyond the scope of SOAP stack and I am not sure it shall be the correct way to go. It is also recognized that there is some implementation (such as salesforce) is using some SOAP header (“sessionIdâ€) to put this token, but it looks like a private implementation and I did not find any specification supporting it.
>>>
>>> Could any experts here illustrate any organization or forum is working on using Oauth2 token for SOAP request? As there are quite some legacy SOAP based web services, hopefully it is a question makes sense for you as well.
>>>
>>> Thoughts?
>>>
>>> Grant Yang
>>> Architect, SDP of ORACLE Communications
>>>
>>> _______________________________________________
>>> 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

From hannes.tschofenig@nsn.com  Tue Mar 20 08:34:41 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AC821F856D for ; Tue, 20 Mar 2012 08:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.425
X-Spam-Level: 
X-Spam-Status: No, score=-106.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1APl2QnHis8W for ; Tue, 20 Mar 2012 08:34:40 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DA1DF21F8594 for ; Tue, 20 Mar 2012 08:34:37 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2KFYaeT003299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 Mar 2012 16:34:36 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2KFYZSE031389 for ; Tue, 20 Mar 2012 16:34:36 +0100
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 20 Mar 2012 16:34:30 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 20 Mar 2012 17:36:08 +0200
Message-ID: <999913AB42CC9341B05A99BBF358718D013CAC26@FIESEXC035.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OAuth: Events next week
Thread-Index: Ac0GryvF84SpnrGNRV6n/94HuQYgNA==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" 
To: 
X-OriginalArrivalTime: 20 Mar 2012 15:34:30.0999 (UTC) FILETIME=[F1893670:01CD06AE]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1120
X-purgate-ID: 151667::1332257676-00007415-11966D46/0-0/0-0
Subject: [OAUTH-WG] OAuth: Events next week
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Mar 2012 15:34:41 -0000

Hi all,=20

you may have noticed that a number of events take place next week
related to OAuth:

Sunday: OpenID Connect Workshop=20
https://oic-workshop-ietf-83.eventbrite.com

Tuesday: ISOC lunch event with the title "Authentication and
Authorization: Next steps for OpenID and OAuth"
http://www.internetsociety.org/events/isoc-panel-openid-and-oauth-ietf-8
3

Thursday: Harry's lunch event with the title "Beyond HTTP
Authentication: OAuth, OpenID, and BrowserID"=20
http://www.ietf.org/mail-archive/web/http-auth/current/msg00991.html

Thursday: OAuth working group meeting
https://datatracker.ietf.org/meeting/83/agenda.html

In addition to these events there are related activities you may also
find useful, such as
=20
 - WEBSEC WG meeting on Monday afternoon
 - IAB Technical Plenary on Monday evening about "Implementation
Challenges with Browser Security"
 - JOSE WG meeting on Tuesday (for the JSON specs)
 - KITTEN WG meeting on Tuesday (SASL OAuth stuff)
 - Simple Cloud Identity Management (SCIM) BOF on Thursday=20
 - RTCWEB WG meeting on Wednesday/Thursday

Ciao
Hannes


From igor.faynberg@alcatel-lucent.com  Tue Mar 20 08:57:29 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65DC21F8609 for ; Tue, 20 Mar 2012 08:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.355
X-Spam-Level: 
X-Spam-Status: No, score=-7.355 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akUZUOHHpLwe for ; Tue, 20 Mar 2012 08:57:29 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCA721F8604 for ; Tue, 20 Mar 2012 08:57:29 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q2KFvS07013943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 Mar 2012 10:57:28 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2KFvRME014474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 20 Mar 2012 10:57:28 -0500
Received: from [135.244.33.178] (faynberg.lra.lucent.com [135.244.33.178]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2KFvRVf019057; Tue, 20 Mar 2012 10:57:27 -0500 (CDT)
Message-ID: <4F68A8E6.3030501@alcatel-lucent.com>
Date: Tue, 20 Mar 2012 11:57:26 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: oauth@ietf.org
References: <999913AB42CC9341B05A99BBF358718D013CAC26@FIESEXC035.nsn-intra.net>
In-Reply-To: <999913AB42CC9341B05A99BBF358718D013CAC26@FIESEXC035.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [OAUTH-WG] OAuth: Events next week
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Mar 2012 15:57:29 -0000

Hannes,

Thanks!  It is excellent to have a summary like that. (I myself missed a 
few event, like Harry's lunch.)

Igor

On 3/20/2012 11:36 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Hi all,
>
> you may have noticed that a number of events take place next week
> related to OAuth:
>
> Sunday: OpenID Connect Workshop
> https://oic-workshop-ietf-83.eventbrite.com
>
> Tuesday: ISOC lunch event with the title "Authentication and
> Authorization: Next steps for OpenID and OAuth"
> http://www.internetsociety.org/events/isoc-panel-openid-and-oauth-ietf-8
> 3
>
> Thursday: Harry's lunch event with the title "Beyond HTTP
> Authentication: OAuth, OpenID, and BrowserID"
> http://www.ietf.org/mail-archive/web/http-auth/current/msg00991.html
>
> Thursday: OAuth working group meeting
> https://datatracker.ietf.org/meeting/83/agenda.html
>
> In addition to these events there are related activities you may also
> find useful, such as
>
>   - WEBSEC WG meeting on Monday afternoon
>   - IAB Technical Plenary on Monday evening about "Implementation
> Challenges with Browser Security"
>   - JOSE WG meeting on Tuesday (for the JSON specs)
>   - KITTEN WG meeting on Tuesday (SASL OAuth stuff)
>   - Simple Cloud Identity Management (SCIM) BOF on Thursday
>   - RTCWEB WG meeting on Wednesday/Thursday
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From derek@ihtfp.com  Wed Mar 21 12:15:31 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF6721E80B6 for ; Wed, 21 Mar 2012 12:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.616
X-Spam-Level: 
X-Spam-Status: No, score=-101.616 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAbXNbyQ2ALY for ; Wed, 21 Mar 2012 12:15:30 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 4704E21E80B7 for ; Wed, 21 Mar 2012 12:15:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 7F23626023A; Wed, 21 Mar 2012 15:15:29 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 10990-09; Wed, 21 Mar 2012 15:15:27 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id ADD8A260268; Wed, 21 Mar 2012 15:15:26 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q2LJFNnN023570; Wed, 21 Mar 2012 15:15:23 -0400
From: Derek Atkins 
To: ht@inf.ed.ac.uk (Henry S. Thompson)
References:  <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET>      
Date: Wed, 21 Mar 2012 15:15:21 -0400
In-Reply-To:  (Henry S. Thompson's message of "Thu, 08 Mar 2012 15:13:12 +0000")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.2a
X-Mailman-Approved-At: Wed, 21 Mar 2012 12:22:50 -0700
Cc: Barry Leiba , "oauth@ietf.org" , "dr@fb.com" 
Subject: Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 19:15:31 -0000

ht@inf.ed.ac.uk (Henry S. Thompson) writes:

> Barry Leiba writes:
>
>>> OK, I now recognise a culture clash as the underlying point at issue,
>>> so this spec. is the wrong place to address it.
>>
>> Ah... so if the issue is how IANA makes registry information
>> available
>
> Precisely.
>
>> then please go to the "happiana" mailing list (
>> https://www.ietf.org/mailman/listinfo/happiana ) and see if you can
>> work with Michelle and the other IANA folks on it.
>
> Indeed.  I should have realised that that was the right level sooner:
> as I said, thanks for your patience.

If you need help coordinating with Michelle @ IANA I can help coordinate
a meeting in Paris next week (assuming you are attending).

> ht

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From torsten@lodderstedt.net  Wed Mar 21 12:33:45 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE4821F858D for ; Wed, 21 Mar 2012 12:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.472
X-Spam-Level: 
X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=0.776,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4rvJEbhGggk for ; Wed, 21 Mar 2012 12:33:44 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by ietfa.amsl.com (Postfix) with ESMTP id BFEB021F8582 for ; Wed, 21 Mar 2012 12:33:43 -0700 (PDT)
Received: from [79.253.8.52] (helo=[192.168.71.36]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SARHx-0003wQ-Ec; Wed, 21 Mar 2012 20:33:41 +0100
Message-ID: <4F6A2D14.2000303@lodderstedt.net>
Date: Wed, 21 Mar 2012 20:33:40 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Paul Madsen 
References:  <2560E47E-655A-4048-AE5D-70EFF171D816@mitre.org> <4F61C5D6.40106@gmail.com>
In-Reply-To: <4F61C5D6.40106@gmail.com>
Content-Type: multipart/alternative; boundary="------------000207090808070005000200"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 19:33:45 -0000

This is a multi-part message in MIME format.
--------------000207090808070005000200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Paul,

for me, your proposal looks like the natural counterpart of JWT, as it 
standardizes the way to implement handle-based token designs (in 
contrast to self-contained tokens).

therefore +1 from my side.

regards,
Torsten.

Am 15.03.2012 11:35, schrieb Paul Madsen:
> +1 to defining RS-AS interactions. We've implemented such a 'token 
> introspection' endpoint in our AS and I'm be happy to no longer need 
> to explain to customers/partners why it's not part of the standard.
>
> As input, an (incomplete) spec for our endpoint enclosed. (we modeled 
> the verification as a new grant type, leveraging as much as possible 
> the existing token endpoint API)
>
> Wrt the 5 item limit
>
> 1) is this an arbitrary #? if people sign up to work on more items, 
> could it be extended?
> 2) the use cases document seems already well progressed (and 
> informational). Need it count against the 5?
>
> paul
>
> On 3/14/12 5:53 PM, Richer, Justin P. wrote:
>> Methods of connecting the PR to the AS are something that several groups have invented outside of the OAuth WG, and I think we should try to pull some of this work together. OAuth2 gives us a logical separation of the concerns but not a way to knit them back together.
>>
>> Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID, and several "token introspection" endpoints in various implementations.
>>
>>   -- Justin
>>
>> On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:
>>
>>> So, here is a proposal:
>>>
>>> -------
>>>
>>> Web Authorization Protocol (oauth)
>>>
>>> Description of Working Group
>>>
>>> The Web Authorization (OAuth) protocol allows a user to grant
>>> a third-party Web site or application access to the user's protected
>>> resources, without necessarily revealing their long-term credentials,
>>> or even their identity. For example, a photo-sharing site that supports
>>> OAuth could allow its users to use a third-party printing Web site to
>>> print their private pictures, without allowing the printing site to
>>> gain full control of the user's account and without having the user
>>> sharing his or her photo-sharing sites' long-term credential with the
>>> printing site.
>>>
>>> The OAuth protocol suite encompasses
>>> * a procedure for allowing a client to discover a resource server,
>>> * a protocol for obtaining authorization tokens from an authorization
>>> server with the resource owner's consent,
>>> * protocols for presenting these authorization tokens to protected
>>> resources for access to a resource, and
>>> * consequently for sharing data in a security and privacy respective way.
>>>
>>> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
>>> was published as an informational document (RFC 5849). With the
>>> completion of OAuth 1.0 the working group started their work on OAuth 2.0
>>> to incorporate implementation experience with version 1.0, additional
>>> use cases, and various other security, readability, and interoperability
>>> improvements. An extensive security analysis was conducted and the result
>>> is available as a stand-alone document offering guidance for audiences
>>> beyond the community of protocol implementers.
>>>
>>> The working group also developed security schemes for presenting authorization
>>> tokens to access a protected resource. This led to the publication of
>>> the bearer token as well as the message authentication code (MAC) access
>>> authentication specification.
>>>
>>> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with
>>> the SAML 2.0 bearer assertion profile.  This offers interworking with existing
>>> identity management solutions, in particular SAML based deployments.
>>>
>>> OAuth has enjoyed widespread adoption by the Internet application service provider
>>> community. To build on this success we aim for nothing more than to make OAuth the
>>> authorization framework of choice for any Internet protocol. Consequently, the
>>> ongoing standardization effort within the OAuth working group is focused on
>>> enhancing interoperability of OAuth deployments. While the core OAuth specification
>>> truly is an important building block it relies on other specifications in order to
>>> claim completeness. Luckily, these components already exist and have been deployed
>>> on the Internet. Through the IETF standards process they will be improved in
>>> quality and will undergo a rigorous review process.
>>>
>>> Goals and Milestones
>>>
>>> [Editor's Note: Here are the completed items.]
>>>
>>> Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item
>>> Done 	Submit 'HTTP Authentication: MAC Authentication' as a working group item
>>> Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard
>>> Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard
>>>
>>> [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?]
>>>
>>> Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard
>>> Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
>>> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard
>>> Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard
>>> May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC
>>>
>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>>
>>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard
>>>
>>> [Starting point for the work will behttp://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
>>>
>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard
>>>
>>> [Starting point for the work will behttp://tools.ietf.org/html/draft-jones-json-web-token]
>>>
>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
>>>
>>> [Starting point for the work will behttp://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
>>>
>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
>>>
>>> [Starting point for the work will behttp://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
>>>
>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC
>>>
>>> [Starting point for the work will behttp://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

--------------000207090808070005000200
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Paul,

    

    for me, your proposal looks like the natural counterpart of JWT, as
    it standardizes the way to implement handle-based token designs (in
    contrast to self-contained tokens).

    

    therefore +1 from my side.

    

    regards,

    Torsten.

    

    Am 15.03.2012 11:35, schrieb Paul Madsen:
    

      
      +1 to defining RS-AS interactions. We've
        implemented such a 'token introspection' endpoint in our AS and
        I'm be happy to no longer need to explain to customers/partners
        why it's not part of the standard.

        

        As input, an (incomplete) spec for our endpoint enclosed. (we
        modeled the verification as a new grant type, leveraging as much
        as possible the existing token endpoint API)

        

        Wrt the 5 item limit

        

        1) is this an arbitrary #? if people sign up to work on more
        items, could it be extended?

        2) the use cases document seems already well progressed (and
        informational). Need it count against the 5?

        

        paul

      

      On 3/14/12 5:53 PM, Richer, Justin P. wrote:
      

        
Methods of connecting the PR to the AS are something that several groups have invented outside of the OAuth WG, and I think we should try to pull some of this work together. OAuth2 gives us a logical separation of the concerns but not a way to knit them back together. 

Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID, and several "token introspection" endpoints in various implementations.

 -- Justin

On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:



        

          
So, here is a proposal:

-------

Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user 
sharing his or her photo-sharing sites' long-term credential with the 
printing site. 

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server, 
* a protocol for obtaining authorization tokens from an authorization 
server with the resource owner's consent, 
* protocols for presenting these authorization tokens to protected 
resources for access to a resource, and 
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the 
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result 
is available as a stand-alone document offering guidance for audiences 
beyond the community of protocol implementers.

The working group also developed security schemes for presenting authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access 
authentication specification. 

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with 
the SAML 2.0 bearer assertion profile.  This offers interworking with existing 
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application service provider 
community. To build on this success we aim for nothing more than to make OAuth the 
authorization framework of choice for any Internet protocol. Consequently, the 
ongoing standardization effort within the OAuth working group is focused on 
enhancing interoperability of OAuth deployments. While the core OAuth specification 
truly is an important building block it relies on other specifications in order to 
claim completeness. Luckily, these components already exist and have been deployed 
on the Internet. Through the IETF standards process they will be improved in 
quality and will undergo a rigorous review process. 

Goals and Milestones

[Editor's Note: Here are the completed items.] 

Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item
Done 	Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard
Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] 

Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard
Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard 
Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard 
May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC

[Editor's Note: New work for the group. 5 items maximum! ]

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]

Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] 

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC

[Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] 



_______________________________________________
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


    

  


--------------000207090808070005000200--

From torsten@lodderstedt.net  Wed Mar 21 12:36:06 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF0421E80E3 for ; Wed, 21 Mar 2012 12:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.584
X-Spam-Level: 
X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=0.665,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLVImtKQH098 for ; Wed, 21 Mar 2012 12:36:05 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by ietfa.amsl.com (Postfix) with ESMTP id 41C7921E80DC for ; Wed, 21 Mar 2012 12:36:01 -0700 (PDT)
Received: from [79.253.8.52] (helo=[192.168.71.36]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SARKB-0007Bk-De; Wed, 21 Mar 2012 20:35:59 +0100
Message-ID: <4F6A2D9E.3050503@lodderstedt.net>
Date: Wed, 21 Mar 2012 20:35:58 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Eran Hammer 
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 19:36:07 -0000

In my opinion, dynamic client registration would allow us to drop public 
client thus simplifying the core spec.

regards,
Torsten.

Am 15.03.2012 16:00, schrieb Eran Hammer:
> I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS->RS work is probably simpler and more useful at this point.
>
> EH
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Tschofenig, Hannes (NSN - FI/Espoo)
>> Sent: Thursday, March 15, 2012 4:47 AM
>> To: ext Blaine Cook; Hannes Tschofenig
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>
>> Hi Blaine,
>>
>> These are indeed good requirements you stated below.
>>
>> When you look at the list of topics do you think that the proposed items
>> indeed fulfill them?
>>
>> Ciao
>> Hannes
>>
>>
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>> Of ext Blaine Cook
>>> Sent: Thursday, March 15, 2012 1:31 PM
>>> To: Hannes Tschofenig
>>> Cc: oauth@ietf.org WG
>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>
>>> On 14 March 2012 20:21, Hannes Tschofenig
>> 
>>> wrote:
>>>> So, here is a proposal:
>>>>
>>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>>>
>>>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration
>>> as a Proposed Standard
>>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
>>> consideration as a Proposed Standard
>>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
>>> OAuth 2.0' to the IESG for consideration
>>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to
>>> the IESG for consideration as a Proposed Standard
>>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration
>>> as an Informational RFC
>>>
>>> This looks great to me.
>>>
>>> I have serious concerns about feature-creep, and think that the OAuth
>>> WG should strongly limit its purview to these issues. In general, I
>>> think it prudent for this working group in particular to consider
>>> standardisation of work only under the following criteria:
>>>
>>> 1. Proposals must have a direct relationship to the mechanism of OAuth
>>> (and not, specifically, bound to an application-level protocol).
>>> 2. Proposals must have significant adoption in both enterprise and
>>> startup environments.
>>> 3. Any proposal must be driven based on a consideration of the
>>> different approaches, as adopted in the wild, and strive to be a
>>> better synthesis of those approaches, not a means to an end.
>>>
>>> These are the constraints with which I started the OAuth project, and
>>> they're more relevant than ever. I'd hate to see OAuth fail in the end
>>> because of a WS-*-like death by standards-pile-on.
>>>
>>> b.
>>> _______________________________________________
>>> 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

From torsten@lodderstedt.net  Wed Mar 21 12:40:47 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E50921E80E8 for ; Wed, 21 Mar 2012 12:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.582,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YD+g765QtXqS for ; Wed, 21 Mar 2012 12:40:46 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by ietfa.amsl.com (Postfix) with ESMTP id D378021E80E6 for ; Wed, 21 Mar 2012 12:40:45 -0700 (PDT)
Received: from [79.253.8.52] (helo=[192.168.71.36]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SAROm-0006QD-1I; Wed, 21 Mar 2012 20:40:44 +0100
Message-ID: <4F6A2EBB.4000308@lodderstedt.net>
Date: Wed, 21 Mar 2012 20:40:43 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Hannes Tschofenig 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 19:40:47 -0000

Hi Hannes,

+1

You have compiled a list of meaningful and feasible objectives.

regards,
Torsten.

Am 14.03.2012 21:21, schrieb Hannes Tschofenig:
> So, here is a proposal:
>
> -------
>
> Web Authorization Protocol (oauth)
>
> Description of Working Group
>
> The Web Authorization (OAuth) protocol allows a user to grant
> a third-party Web site or application access to the user's protected
> resources, without necessarily revealing their long-term credentials,
> or even their identity. For example, a photo-sharing site that supports
> OAuth could allow its users to use a third-party printing Web site to
> print their private pictures, without allowing the printing site to
> gain full control of the user's account and without having the user
> sharing his or her photo-sharing sites' long-term credential with the
> printing site.
>
> The OAuth protocol suite encompasses
> * a procedure for allowing a client to discover a resource server,
> * a protocol for obtaining authorization tokens from an authorization
> server with the resource owner's consent,
> * protocols for presenting these authorization tokens to protected
> resources for access to a resource, and
> * consequently for sharing data in a security and privacy respective way.
>
> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
> was published as an informational document (RFC 5849). With the
> completion of OAuth 1.0 the working group started their work on OAuth 2.0
> to incorporate implementation experience with version 1.0, additional
> use cases, and various other security, readability, and interoperability
> improvements. An extensive security analysis was conducted and the result
> is available as a stand-alone document offering guidance for audiences
> beyond the community of protocol implementers.
>
> The working group also developed security schemes for presenting authorization
> tokens to access a protected resource. This led to the publication of
> the bearer token as well as the message authentication code (MAC) access
> authentication specification.
>
> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with
> the SAML 2.0 bearer assertion profile.  This offers interworking with existing
> identity management solutions, in particular SAML based deployments.
>
> OAuth has enjoyed widespread adoption by the Internet application service provider
> community. To build on this success we aim for nothing more than to make OAuth the
> authorization framework of choice for any Internet protocol. Consequently, the
> ongoing standardization effort within the OAuth working group is focused on
> enhancing interoperability of OAuth deployments. While the core OAuth specification
> truly is an important building block it relies on other specifications in order to
> claim completeness. Luckily, these components already exist and have been deployed
> on the Internet. Through the IETF standards process they will be improved in
> quality and will undergo a rigorous review process.
>
> Goals and Milestones
>
> [Editor's Note: Here are the completed items.]
>
> Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item
> Done 	Submit 'HTTP Authentication: MAC Authentication' as a working group item
> Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard
> Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard
>
> [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?]
>
> Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard
> Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
> Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard
> Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard
> May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC
>
> [Editor's Note: New work for the group. 5 items maximum! ]
>
> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard
>
> [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
>
> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]
>
> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
>
> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
>
> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC
>
> [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From ve7jtb@ve7jtb.com  Wed Mar 21 12:53:17 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D986221E80F3 for ; Wed, 21 Mar 2012 12:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.207
X-Spam-Level: 
X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=0.392,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTvo4A+uN3SV for ; Wed, 21 Mar 2012 12:53:16 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB4C021E80F0 for ; Wed, 21 Mar 2012 12:53:15 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so1437645ghb.31 for ; Wed, 21 Mar 2012 12:53:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=YQxPbFvXBneHXskrOC1au4DDpHSAdg9RtANGd4sy0y8=; b=aC+vv1TFUUMubkcisDfG5KN8FK99cL4NyIP+R8AkR57LLUIpk8XAhZn2845LrVLjdk 9Snz8vvzbIPL4Inn0FJXV875gDAuPVJHdQ526m+1Um9KMd0xVEjlYdqKxJVloQ6/XdlF 5Pyp99HKA2q/Pu693R7X4q0lL+xXs5oVLfpyElhV9C3rF4rcFdx4DqskC0Y6a2PGmClG t9CGOqCy8gx4dJdWTcj8WOFdR6rP4n8zS2xOljvyDS67J0sySK1LY6DtNE7qmkQCtZgJ P3EpYoNrmQZkpvY6N+LeNTwQA5rbM1zx77wR0rNu+GN2bWW5pTeAywr2nS/QnXGBI6nQ dcTQ==
Received: by 10.236.153.104 with SMTP id e68mr5255080yhk.74.1332359594013; Wed, 21 Mar 2012 12:53:14 -0700 (PDT)
Received: from [192.168.1.213] (190-20-62-179.baf.movistar.cl. [190.20.62.179]) by mx.google.com with ESMTPS id d25sm6998311yhe.4.2012.03.21.12.52.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Mar 2012 12:53:12 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_AC7EC563-3C6C-445B-BE61-9667F6FB26CA"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <4F6A2D9E.3050503@lodderstedt.net>
Date: Wed, 21 Mar 2012 16:52:34 -0300
Message-Id: <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net>
To: Torsten Lodderstedt 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnWhqcTx2JzPt7WLH49V1Okl7Wz0W0Em70hKJ5VE4yHT1STeW0fcaexjSG1EmivKNF++HUO
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 19:53:17 -0000

--Apple-Mail=_AC7EC563-3C6C-445B-BE61-9667F6FB26CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I don't think dynamic registration completely removes the need for a =
public client, that can't keep secrets.

While we did do dynamic client registration for Connect that is a more =
constrained use case.
I would put JWT and AS-RS communication as higher priorities than =
dynamic registration.
Partially because they are more self contained issues.

John B.
On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:

> In my opinion, dynamic client registration would allow us to drop =
public client thus simplifying the core spec.
>=20
> regards,
> Torsten.
>=20
> Am 15.03.2012 16:00, schrieb Eran Hammer:
>> I believe most do, except for the dynamic client registration. I =
don't have strong objections to it, but it is the least important and =
least defined / deployed proposal on the list. The AS->RS work is =
probably simpler and more useful at this point.
>>=20
>> EH
>>=20
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>> Of Tschofenig, Hannes (NSN - FI/Espoo)
>>> Sent: Thursday, March 15, 2012 4:47 AM
>>> To: ext Blaine Cook; Hannes Tschofenig
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>=20
>>> Hi Blaine,
>>>=20
>>> These are indeed good requirements you stated below.
>>>=20
>>> When you look at the list of topics do you think that the proposed =
items
>>> indeed fulfill them?
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>>> Of ext Blaine Cook
>>>> Sent: Thursday, March 15, 2012 1:31 PM
>>>> To: Hannes Tschofenig
>>>> Cc: oauth@ietf.org WG
>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>=20
>>>> On 14 March 2012 20:21, Hannes Tschofenig
>>> 
>>>> wrote:
>>>>> So, here is a proposal:
>>>>>=20
>>>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>>>>=20
>>>>> Aug. 2012    Submit 'Token Revocation' to the IESG for =
consideration
>>>> as a Proposed Standard
>>>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
>>>> consideration as a Proposed Standard
>>>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles =
for
>>>> OAuth 2.0' to the IESG for consideration
>>>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' =
to
>>>> the IESG for consideration as a Proposed Standard
>>>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for =
consideration
>>>> as an Informational RFC
>>>>=20
>>>> This looks great to me.
>>>>=20
>>>> I have serious concerns about feature-creep, and think that the =
OAuth
>>>> WG should strongly limit its purview to these issues. In general, I
>>>> think it prudent for this working group in particular to consider
>>>> standardisation of work only under the following criteria:
>>>>=20
>>>> 1. Proposals must have a direct relationship to the mechanism of =
OAuth
>>>> (and not, specifically, bound to an application-level protocol).
>>>> 2. Proposals must have significant adoption in both enterprise and
>>>> startup environments.
>>>> 3. Any proposal must be driven based on a consideration of the
>>>> different approaches, as adopted in the wild, and strive to be a
>>>> better synthesis of those approaches, not a means to an end.
>>>>=20
>>>> These are the constraints with which I started the OAuth project, =
and
>>>> they're more relevant than ever. I'd hate to see OAuth fail in the =
end
>>>> because of a WS-*-like death by standards-pile-on.
>>>>=20
>>>> b.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_AC7EC563-3C6C-445B-BE61-9667F6FB26CA
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMy
MTE5NTIzNVowIwYJKoZIhvcNAQkEMRYEFFgAxdzFGk5Bg2uP8zjysBywGolxMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
ABBRhVBTwkdRx9NiTd58fhRWu+v4lifIkBAqk1ufbWHWh7Jp9VfdFfydvZ6U+MXS2ygmW7Gnyrtu
hlTNif3T3mVKoCIwSrOJrSW2Nd2ZydJ07Tths4W8Gihf4w3HatFqKyVCFc1Z9Ua9VaumypV34Eww
oT9VvkSB1+ZKM78bvaeGrzaMZWiiqn/5zU+0a4zABGmln1Dho3eFfUlQn686C2/1wi52HYFV+cKC
i39HTbVriN9EzUx0d4x49S9jcpDaERo42msDp7swRiizpqVOpMp/CcEBV5SkjSLuUNRMd26jjIod
quVKz58WbjATwj9Y60CNS8Rzj/Ey3fQgTDSh2bEAAAAAAAA=

--Apple-Mail=_AC7EC563-3C6C-445B-BE61-9667F6FB26CA--

From eran@hueniverse.com  Wed Mar 21 13:37:02 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1261F21E812D for ; Wed, 21 Mar 2012 13:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level: 
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re762I9dMUbz for ; Wed, 21 Mar 2012 13:37:01 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id D6C8321E8129 for ; Wed, 21 Mar 2012 13:37:00 -0700 (PDT)
Received: (qmail 11034 invoked from network); 21 Mar 2012 20:36:57 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Mar 2012 20:36:57 -0000
Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id oLcK1i00110TkE001LcxUP; Wed, 21 Mar 2012 13:36:57 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 21 Mar 2012 13:35:32 -0700
From: Eran Hammer 
To: John Bradley , Torsten Lodderstedt 
Date: Wed, 21 Mar 2012 13:35:24 -0700
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: Ac0HnyBv3UQ8vwznThKhS+qrQhGj4wAAuWVA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08FD3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net> <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>
In-Reply-To: <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 20:37:02 -0000

As a general rule, we should not add any item to the charter unless there i=
s a well-reviewed (and well-received) draft available as the basis for futu=
re work, as well as at least one editor for the task.

EH

> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Wednesday, March 21, 2012 12:53 PM
> To: Torsten Lodderstedt
> Cc: Eran Hammer; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>=20
> I don't think dynamic registration completely removes the need for a publ=
ic
> client, that can't keep secrets.
>=20
> While we did do dynamic client registration for Connect that is a more
> constrained use case.
> I would put JWT and AS-RS communication as higher priorities than dynamic
> registration.
> Partially because they are more self contained issues.
>=20
> John B.
> On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
>=20
> > In my opinion, dynamic client registration would allow us to drop publi=
c
> client thus simplifying the core spec.
> >
> > regards,
> > Torsten.
> >
> > Am 15.03.2012 16:00, schrieb Eran Hammer:
> >> I believe most do, except for the dynamic client registration. I don't=
 have
> strong objections to it, but it is the least important and least defined =
/
> deployed proposal on the list. The AS->RS work is probably simpler and mo=
re
> useful at this point.
> >>
> >> EH
> >>
> >>> -----Original Message-----
> >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> Behalf
> >>> Of Tschofenig, Hannes (NSN - FI/Espoo)
> >>> Sent: Thursday, March 15, 2012 4:47 AM
> >>> To: ext Blaine Cook; Hannes Tschofenig
> >>> Cc: oauth@ietf.org
> >>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
> >>>
> >>> Hi Blaine,
> >>>
> >>> These are indeed good requirements you stated below.
> >>>
> >>> When you look at the list of topics do you think that the proposed it=
ems
> >>> indeed fulfill them?
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> Behalf
> >>>> Of ext Blaine Cook
> >>>> Sent: Thursday, March 15, 2012 1:31 PM
> >>>> To: Hannes Tschofenig
> >>>> Cc: oauth@ietf.org WG
> >>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
> >>>>
> >>>> On 14 March 2012 20:21, Hannes Tschofenig
> >>> 
> >>>> wrote:
> >>>>> So, here is a proposal:
> >>>>>
> >>>>> [Editor's Note: New work for the group. 5 items maximum! ]
> >>>>>
> >>>>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideratio=
n
> >>>> as a Proposed Standard
> >>>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
> >>>> consideration as a Proposed Standard
> >>>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
> >>>> OAuth 2.0' to the IESG for consideration
> >>>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to
> >>>> the IESG for consideration as a Proposed Standard
> >>>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration
> >>>> as an Informational RFC
> >>>>
> >>>> This looks great to me.
> >>>>
> >>>> I have serious concerns about feature-creep, and think that the OAut=
h
> >>>> WG should strongly limit its purview to these issues. In general, I
> >>>> think it prudent for this working group in particular to consider
> >>>> standardisation of work only under the following criteria:
> >>>>
> >>>> 1. Proposals must have a direct relationship to the mechanism of OAu=
th
> >>>> (and not, specifically, bound to an application-level protocol).
> >>>> 2. Proposals must have significant adoption in both enterprise and
> >>>> startup environments.
> >>>> 3. Any proposal must be driven based on a consideration of the
> >>>> different approaches, as adopted in the wild, and strive to be a
> >>>> better synthesis of those approaches, not a means to an end.
> >>>>
> >>>> These are the constraints with which I started the OAuth project, an=
d
> >>>> they're more relevant than ever. I'd hate to see OAuth fail in the e=
nd
> >>>> because of a WS-*-like death by standards-pile-on.
> >>>>
> >>>> b.
> >>>> _______________________________________________
> >>>> 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


From gffletch@aol.com  Wed Mar 21 13:50:49 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9DF21F85B6 for ; Wed, 21 Mar 2012 13:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vJvXtKYGuC7 for ; Wed, 21 Mar 2012 13:50:48 -0700 (PDT)
Received: from imr-ma04.mx.aol.com (imr-ma04.mx.aol.com [64.12.206.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1A38921F855D for ; Wed, 21 Mar 2012 13:50:48 -0700 (PDT)
Received: from mtaout-db06.r1000.mx.aol.com (mtaout-db06.r1000.mx.aol.com [172.29.51.198]) by imr-ma04.mx.aol.com (8.14.1/8.14.1) with ESMTP id q2LKoYCf011006; Wed, 21 Mar 2012 16:50:34 -0400
Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 8E7EAE0000D4; Wed, 21 Mar 2012 16:50:34 -0400 (EDT)
Message-ID: <4F6A3F22.6060809@aol.com>
Date: Wed, 21 Mar 2012 16:50:42 -0400
From: George Fletcher 
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net> <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>
In-Reply-To: <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------010701050101070003030507"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1332363034; bh=GUqsvWn8/hSpO6PH9wK9hksv3oc0iPe1a12V7ekPJxU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=nrGYN8J3v5l3F/Y85bxdL4fSb81Xkx6UzWrm1SZzAVyOMBeWzVVCv2m5Po2qerMBW Y+4QPYWnxXuDTzcdApaH0lbqsiKozLFoE6LFIcSzsM2LgNTe9bNnZ60dW0Bn/RAZr9 Zt6UjSokf8TRzhcvHzAAqvwBbLL4vPbAeUJclYMA=
X-AOL-SCOLL-SCORE: 0:2:427461120:93952408  
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d33c64f6a3f1a77aa
X-AOL-IP: 10.181.186.254
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 20:50:49 -0000

This is a multi-part message in MIME format.
--------------010701050101070003030507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

+1 to JWT and AS-RS communication over dynamic registration

On 3/21/12 3:52 PM, John Bradley wrote:
> I don't think dynamic registration completely removes the need for a public client, that can't keep secrets.
>
> While we did do dynamic client registration for Connect that is a more constrained use case.
> I would put JWT and AS-RS communication as higher priorities than dynamic registration.
> Partially because they are more self contained issues.
>
> John B.
> On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
>
>> In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec.
>>
>> regards,
>> Torsten.
>>
>> Am 15.03.2012 16:00, schrieb Eran Hammer:
>>> I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS->RS work is probably simpler and more useful at this point.
>>>
>>> EH
>>>
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>>> Of Tschofenig, Hannes (NSN - FI/Espoo)
>>>> Sent: Thursday, March 15, 2012 4:47 AM
>>>> To: ext Blaine Cook; Hannes Tschofenig
>>>> Cc: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>
>>>> Hi Blaine,
>>>>
>>>> These are indeed good requirements you stated below.
>>>>
>>>> When you look at the list of topics do you think that the proposed items
>>>> indeed fulfill them?
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>>>> Of ext Blaine Cook
>>>>> Sent: Thursday, March 15, 2012 1:31 PM
>>>>> To: Hannes Tschofenig
>>>>> Cc: oauth@ietf.org WG
>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>>
>>>>> On 14 March 2012 20:21, Hannes Tschofenig
>>>> 
>>>>> wrote:
>>>>>> So, here is a proposal:
>>>>>>
>>>>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>>>>>
>>>>>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration
>>>>> as a Proposed Standard
>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
>>>>> consideration as a Proposed Standard
>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
>>>>> OAuth 2.0' to the IESG for consideration
>>>>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to
>>>>> the IESG for consideration as a Proposed Standard
>>>>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration
>>>>> as an Informational RFC
>>>>>
>>>>> This looks great to me.
>>>>>
>>>>> I have serious concerns about feature-creep, and think that the OAuth
>>>>> WG should strongly limit its purview to these issues. In general, I
>>>>> think it prudent for this working group in particular to consider
>>>>> standardisation of work only under the following criteria:
>>>>>
>>>>> 1. Proposals must have a direct relationship to the mechanism of OAuth
>>>>> (and not, specifically, bound to an application-level protocol).
>>>>> 2. Proposals must have significant adoption in both enterprise and
>>>>> startup environments.
>>>>> 3. Any proposal must be driven based on a consideration of the
>>>>> different approaches, as adopted in the wild, and strive to be a
>>>>> better synthesis of those approaches, not a means to an end.
>>>>>
>>>>> These are the constraints with which I started the OAuth project, and
>>>>> they're more relevant than ever. I'd hate to see OAuth fail in the end
>>>>> because of a WS-*-like death by standards-pile-on.
>>>>>
>>>>> b.
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------010701050101070003030507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1 to JWT and AS-RS
      communication over dynamic registration

    

    On 3/21/12 3:52 PM, John Bradley wrote:
    

      
I don't think dynamic registration completely removes the need for a public client, that can't keep secrets.

While we did do dynamic client registration for Connect that is a more constrained use case.
I would put JWT and AS-RS communication as higher priorities than dynamic registration.
Partially because they are more self contained issues.

John B.
On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:



      

        
In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec.

regards,
Torsten.

Am 15.03.2012 16:00, schrieb Eran Hammer:


        

          
I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS->RS work is probably simpler and more useful at this point.

EH



          

            
-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, March 15, 2012 4:47 AM
To: ext Blaine Cook; Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Hi Blaine,

These are indeed good requirements you stated below.

When you look at the list of topics do you think that the proposed items
indeed fulfill them?

Ciao
Hannes




            

              
-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of ext Blaine Cook
Sent: Thursday, March 15, 2012 1:31 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

On 14 March 2012 20:21, Hannes Tschofenig


            

            
<hannes.tschofenig@gmx.net>


            

              
wrote:


              

                
So, here is a proposal:

[Editor's Note: New work for the group. 5 items maximum! ]

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration


              

              
as a Proposed Standard


              

                
Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for


              

              
consideration as a Proposed Standard


              

                
Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for


              

              
OAuth 2.0' to the IESG for consideration


              

                
Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to


              

              
the IESG for consideration as a Proposed Standard


              

                
Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration


              

              
as an Informational RFC

This looks great to me.

I have serious concerns about feature-creep, and think that the OAuth
WG should strongly limit its purview to these issues. In general, I
think it prudent for this working group in particular to consider
standardisation of work only under the following criteria:

1. Proposals must have a direct relationship to the mechanism of OAuth
(and not, specifically, bound to an application-level protocol).
2. Proposals must have significant adoption in both enterprise and
startup environments.
3. Any proposal must be driven based on a consideration of the
different approaches, as adopted in the wild, and strive to be a
better synthesis of those approaches, not a means to an end.

These are the constraints with which I started the OAuth project, and
they're more relevant than ever. I'd hate to see OAuth fail in the end
because of a WS-*-like death by standards-pile-on.

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


            

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


          

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


        

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


      

      

      

      

      

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


    

    

  


--------------010701050101070003030507--

From bcampbell@pingidentity.com  Wed Mar 21 15:23:52 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB8A21E804E for ; Wed, 21 Mar 2012 15:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.662
X-Spam-Level: 
X-Spam-Status: No, score=-5.662 tagged_above=-999 required=5 tests=[AWL=0.315,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1mnyQroT6sS for ; Wed, 21 Mar 2012 15:23:52 -0700 (PDT)
Received: from psmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) by ietfa.amsl.com (Postfix) with ESMTP id C03F221E813D for ; Wed, 21 Mar 2012 15:23:49 -0700 (PDT)
Received: from mail-vb0-f50.google.com ([209.85.212.50]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKT2pU9ffy2mL7UY7c8oDLuTtSeUQfvmeJ@postini.com; Wed, 21 Mar 2012 15:23:51 PDT
Received: by mail-vb0-f50.google.com with SMTP id l22so794444vbn.9 for ; Wed, 21 Mar 2012 15:23:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=CY5obwB0bfdjR/XvDGmw4XiHUM5lii4kC/lRGAVwtfw=; b=CRer80CmR3/XR+QyDfrmA5Qyz7DdKTyJ95QnuNVrkO+4v+GZDulLiVgpO9dt+JnHVe FIpzAVupM3yCuSUTEFlP6dlVas6JpvufMI8itaiEDNMiOVK0hh0bbX4Sr/FzGPkhmwp3 Df40MSSb5R0/U1AYrkxUbqerROhmbbtxNpLZIEbRKEPQYmsq/9jbFaiu3PJQIbjBUOk5 qzPG4y3UcLptlr2c4W7t4kcmkTU6PSqMC9MXu840nXYYvq+8S+PMMPD6F6Ssq80Kyo1A fNh/t297akf7qs62vU8SkYM3c9jKxbmxPdAtEbyUmoUu66278dF37YwNhpU5ATraph5a 2Q/g==
Received: by 10.220.116.10 with SMTP id k10mr2710999vcq.25.1332368629167; Wed, 21 Mar 2012 15:23:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.171.172 with HTTP; Wed, 21 Mar 2012 15:23:18 -0700 (PDT)
From: Brian Campbell 
Date: Wed, 21 Mar 2012 16:23:18 -0600
Message-ID: 
To: oauth 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkX8DwI16oYTso2ezXZlN8x6BX/79//CZybUWNQWoiCS+ClvrSAaQKsTTgQBXquxTBtxD+I
Subject: [OAUTH-WG] Google using JTW assertions?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 22:23:52 -0000

I noticed this post
http://googledevelopers.blogspot.se/2012/03/service-accounts-have-arrived.h=
tml,
via a tweet from a colleague, that mentions sending a "JWT to Google=92s
OAuth 2.0 Authorization Server in exchange for an access token."  The
post mentions compliance of draft 25 of OAuth v2 but doesn't give much
more detail. I'm wondering if any Google folks on this list know if it
was implemented to the
http://tools.ietf.org/html/draft-ietf-oauth-assertions &
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer specs?  It
would be great to have some feedback one way or the other on the
applicability of those documents from a real world deployment.

From torsten@lodderstedt.net  Thu Mar 22 01:29:47 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BFB21F8657 for ; Thu, 22 Mar 2012 01:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NrMSccTU6UZ for ; Thu, 22 Mar 2012 01:29:47 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) by ietfa.amsl.com (Postfix) with ESMTP id D519421F8646 for ; Thu, 22 Mar 2012 01:29:46 -0700 (PDT)
Received: from [80.67.16.117] (helo=webmail.df.eu) by smtprelay06.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1SAdOx-0007HW-U2; Thu, 22 Mar 2012 09:29:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 22 Mar 2012 09:29:43 +0100
From: Torsten Lodderstedt 
To: John Bradley 
In-Reply-To: <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net> <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>
Message-ID: <4bec89cc2d73c8814b94c8cfeb3e9776@lodderstedt-online.de>
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail/0.6
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 08:29:48 -0000

Hi John,

> I don't think dynamic registration completely removes the need for a
> public client, that can't keep secrets.

I don't get this argument. In my opinion, there are two use cases, 
which currently motivate usage of public clients and none of them is 
about "keeping secrets".

1) native apps - There is no mechanism for securely _provisioning_ 
those clients with client secrets. So it does not make sense to use 
secrets for authenticating them. Dynamic client registration would allow 
them to obtain client id and secret on activation/installation. The 
security of the respective secret is the same as for refresh tokens. So 
either both can be protected appropriately or none of them. Please note: 
I'm not talking about trust in the identity/authenticity of the 
particular app installation. I'm just talking about simplifying the 
OAuth flows and description. Today an AS needs to support the refresh 
tokens or resource owner grant type for both confidential and public 
clients in order to also support native apps.
2) implicit grant - here, public clients are used because the protocol 
design itself does not allows for validating client secrets. Obviously, 
digital signature would help but make the protocol more difficult to 
use.

Basically, dynamic client registration allows a client to bind to an AS 
at runtime. That's what it makes so valuable with respect to 
interoperatibility. Whether the client just registers meta data or also 
obtains a secret is another aspect but not the only one.

regards,
Torsten.

>
> While we did do dynamic client registration for Connect that is a
> more constrained use case.
> I would put JWT and AS-RS communication as higher priorities than
> dynamic registration.
> Partially because they are more self contained issues.
>
> John B.
> On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
>
>> In my opinion, dynamic client registration would allow us to drop 
>> public client thus simplifying the core spec.
>>
>> regards,
>> Torsten.
>>
>> Am 15.03.2012 16:00, schrieb Eran Hammer:
>>> I believe most do, except for the dynamic client registration. I 
>>> don't have strong objections to it, but it is the least important and 
>>> least defined / deployed proposal on the list. The AS->RS work is 
>>> probably simpler and more useful at this point.
>>>
>>> EH
>>>
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On 
>>>> Behalf
>>>> Of Tschofenig, Hannes (NSN - FI/Espoo)
>>>> Sent: Thursday, March 15, 2012 4:47 AM
>>>> To: ext Blaine Cook; Hannes Tschofenig
>>>> Cc: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>
>>>> Hi Blaine,
>>>>
>>>> These are indeed good requirements you stated below.
>>>>
>>>> When you look at the list of topics do you think that the proposed 
>>>> items
>>>> indeed fulfill them?
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On 
>>>>> Behalf
>>>>> Of ext Blaine Cook
>>>>> Sent: Thursday, March 15, 2012 1:31 PM
>>>>> To: Hannes Tschofenig
>>>>> Cc: oauth@ietf.org WG
>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>>
>>>>> On 14 March 2012 20:21, Hannes Tschofenig
>>>> 
>>>>> wrote:
>>>>>> So, here is a proposal:
>>>>>>
>>>>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>>>>>
>>>>>> Aug. 2012    Submit 'Token Revocation' to the IESG for 
>>>>>> consideration
>>>>> as a Proposed Standard
>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
>>>>> consideration as a Proposed Standard
>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles 
>>>>>> for
>>>>> OAuth 2.0' to the IESG for consideration
>>>>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' 
>>>>>> to
>>>>> the IESG for consideration as a Proposed Standard
>>>>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for 
>>>>>> consideration
>>>>> as an Informational RFC
>>>>>
>>>>> This looks great to me.
>>>>>
>>>>> I have serious concerns about feature-creep, and think that the 
>>>>> OAuth
>>>>> WG should strongly limit its purview to these issues. In general, 
>>>>> I
>>>>> think it prudent for this working group in particular to consider
>>>>> standardisation of work only under the following criteria:
>>>>>
>>>>> 1. Proposals must have a direct relationship to the mechanism of 
>>>>> OAuth
>>>>> (and not, specifically, bound to an application-level protocol).
>>>>> 2. Proposals must have significant adoption in both enterprise 
>>>>> and
>>>>> startup environments.
>>>>> 3. Any proposal must be driven based on a consideration of the
>>>>> different approaches, as adopted in the wild, and strive to be a
>>>>> better synthesis of those approaches, not a means to an end.
>>>>>
>>>>> These are the constraints with which I started the OAuth project, 
>>>>> and
>>>>> they're more relevant than ever. I'd hate to see OAuth fail in 
>>>>> the end
>>>>> because of a WS-*-like death by standards-pile-on.
>>>>>
>>>>> b.
>>>>> _______________________________________________
>>>>> 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

From torsten@lodderstedt.net  Thu Mar 22 01:40:13 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132C921F85D2 for ; Thu, 22 Mar 2012 01:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzxv+QeWpxdH for ; Thu, 22 Mar 2012 01:40:12 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7625721F8542 for ; Thu, 22 Mar 2012 01:40:11 -0700 (PDT)
Received: from [80.67.16.117] (helo=webmail.df.eu) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1SAdZ3-000828-W1; Thu, 22 Mar 2012 09:40:10 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_f794bb86ad11f01614127e3bda11680f"
Date: Thu, 22 Mar 2012 09:40:09 +0100
From: Torsten Lodderstedt 
To: George Fletcher 
In-Reply-To: <4F6A3F22.6060809@aol.com>
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net> <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com> <4F6A3F22.6060809@aol.com>
Message-ID: <8708c9bdf1e08a7b7ea3cb158add7e2a@lodderstedt-online.de>
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail/0.6
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 08:40:13 -0000

--=_f794bb86ad11f01614127e3bda11680f
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=UTF-8

  

Hi George, 

I see two distinct areas of interoperability, which
are Client-AS and AS-RS. Dynamic client registration belongs to
Client-AS whereas JWT & AS-RS communication belong to the later area.


OAuth 2.0 currently (not fully) covers Client-AS and does not address
AS-RS. In my opinion, the WG should decide whether we first complete
Client-AS and address AS-RS later on or vice versa. 

I'm in favour of
completing Client-AS first and consider client registration a major
missing piece. Why? Because otherwise clients cannot dynamically bind to
any OAuth-AS at runtime but have to pre-register (with any?) :-(.


regards,
Torsten. 

Am 21.03.2012 21:50, schrieb George Fletcher: 

>
+1 to JWT and AS-RS communication over dynamic registration
> 
> On
3/21/12 3:52 PM, John Bradley wrote: 
> 
>> I don't think dynamic
registration completely removes the need for a public client, that can't
keep secrets.
>> 
>> While we did do dynamic client registration for
Connect that is a more constrained use case.
>> I would put JWT and
AS-RS communication as higher priorities than dynamic registration.
>>
Partially because they are more self contained issues.
>> 
>> John B.
>>
On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
>> 
>>> In my
opinion, dynamic client registration would allow us to drop public
client thus simplifying the core spec.
>>> 
>>> regards,
>>>
Torsten.
>>> 
>>> Am 15.03.2012 16:00, schrieb Eran Hammer:
>>> 
>>>> I
believe most do, except for the dynamic client registration. I don't
have strong objections to it, but it is the least important and least
defined / deployed proposal on the list. The AS->RS work is probably
simpler and more useful at this point.
>>>> 
>>>> EH
>>>> 
>>>>>
-----Original Message-----
>>>>> From: oauth-bounces@ietf.org [6]
[mailto:oauth-bounces@ietf.org [7]] On Behalf
>>>>> Of Tschofenig,
Hannes (NSN - FI/Espoo)
>>>>> Sent: Thursday, March 15, 2012 4:47
AM
>>>>> To: ext Blaine Cook; Hannes Tschofenig
>>>>> Cc: oauth@ietf.org
[8]
>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>> 
>>>>> Hi
Blaine,
>>>>> 
>>>>> These are indeed good requirements you stated
below.
>>>>> 
>>>>> When you look at the list of topics do you think
that the proposed items
>>>>> indeed fulfill them?
>>>>> 
>>>>>
Ciao
>>>>> Hannes
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From:
oauth-bounces@ietf.org [1] [mailto:oauth-bounces@ietf.org [2]] On
Behalf
>>>>>> Of ext Blaine Cook
>>>>>> Sent: Thursday, March 15, 2012
1:31 PM
>>>>>> To: Hannes Tschofenig
>>>>>> Cc: oauth@ietf.org [3]
WG
>>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>>> 
>>>>>>
On 14 March 2012 20:21, Hannes Tschofenig
>>>>> 
>>>>>> wrote:
>>>>>>

>>>>>>> So, here is a proposal:
>>>>>>> 
>>>>>>> [Editor's Note: New
work for the group. 5 items maximum! ]
>>>>>>> 
>>>>>>> Aug. 2012 Submit
'Token Revocation' to the IESG for consideration
>>>>>> 
>>>>>> as a
Proposed Standard
>>>>>> 
>>>>>>> Nov. 2012 Submit 'JSON Web Token
(JWT)' to the IESG for
>>>>>> 
>>>>>> consideration as a Proposed
Standard
>>>>>> 
>>>>>>> 2.0' to the IESG for consideration
>>>>>>
er-left:#1010ff 2px solid; margin-left:5px; width:100%"> 
>>>>>> 
>>>>>>
Jan. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to
>>>>>>

>>>>>> the IESG for considerat> solid; margin-left:5px; width:100%">

>>>>>>> 
>>>>>>> Sep. 2012 Submit 'OAuth Use Cases' to
>>>>>>
consideration 
>>>>>> 
>>>>>> as an Informational RFC
>>>>>> 
>>>>>>
This looks great to me.
>>>>>> 
>>>>>> I have serious concerns about
feature-creep, and think that the OAuth
>>>>>> WG should strongly limit
its purview to these issues. > y under the following criteria: 1.
Proposals must have a direct relationship to t
>>>>>> of OAuth (and not,
specifically, bound to an application-level protocol). 2. Proposals must
have significant adoption in both enterprise and startup environments.
3. Any proposal must be driven based on a consideration of the different
approaches, as adopted in the wild, and strive to be a better synthesis
of those approaches, not a means to an end. These are the constraints
with which I started the OAuth project, and they're more relevant than
ever. I'd hate to see OAuth fail in the end because of a WS-*-like death
by standards-pile-on. b. _______________________________________________
OAuth mailing list OAuth@ietf.org [4]
https://www.ietf.org/mailman/listinfo/oauth [5]
>>>>> 
>>>>>
_______________________________________________
>>>>> OAuth mailing
list
>>>>> OAuth@ietf.org [9]
>>>>>
https://www.ietf.org/mailman/listinfo/oauth [10]
>>>> 
>>>>
_______________________________________________
>>>> OAuth mailing
list
>>>> OAuth@ietf.org [11]
>>>>
https://www.ietf.org/mailman/listinfo/oauth [12]
>>> 
>>>
_______________________________________________
>>> OAuth mailing
list
>>> OAuth@ietf.org [13]
>>>
https://www.ietf.org/mailman/listinfo/oauth [14]
>> 
>>
_______________________________________________
>> OAuth mailing list
>>
OAuth@ietf.org [15]
>> https://www.ietf.org/mailman/listinfo/oauth
[16]

  

Links:
------
[1] mailto:oauth-bounces@ietf.org
[2]
mailto:oauth-bounces@ietf.org
[3] mailto:oauth@ietf.org
[4]
mailto:OAuth@ietf.org
[5]
https://www.ietf.org/mailman/listinfo/oauth
[6]
mailto:oauth-bounces@ietf.org
[7] mailto:oauth-bounces@ietf.org
[8]
mailto:oauth@ietf.org
[9] mailto:OAuth@ietf.org
[10]
https://www.ietf.org/mailman/listinfo/oauth
[11]
mailto:OAuth@ietf.org
[12]
https://www.ietf.org/mailman/listinfo/oauth
[13]
mailto:OAuth@ietf.org
[14]
https://www.ietf.org/mailman/listinfo/oauth
[15]
mailto:OAuth@ietf.org
[16] https://www.ietf.org/mailman/listinfo/oauth

--=_f794bb86ad11f01614127e3bda11680f
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8




Hi George,


I see two distinct areas of interoperability, which are Client-AS and AS=
-RS. Dynamic client registration belongs to Client-AS whereas JWT & AS-=
RS communication belong to the later area.


OAuth 2.0 currently (not fully) covers Client-AS and does not addre=
ss AS-RS. In my opinion, the WG should decide whether we first complete Cli=
ent-AS and address AS-RS later on or vice versa.


I'm in favour of completing Client-AS first and consider client registra=
tion a major missing piece. Why? Because otherwise clients cannot dynamical=
ly bind to any OAuth-AS at runtime but have to pre-register (with any?) :-(=
=2E


regards,
Torsten.


 


Am 21.03.2012 21:50, schrieb George Fletcher:


+1 to JWT and AS-RS communication over dynamic registration

On 3/21/12 3:52 PM, John Bradley wrote:



I don't think dynamic registration completely removes the need for a p=
ublic client, that can't keep secrets.

While we did do dynamic client registration for Connect that is a more cons=
trained use case.
I would put JWT and AS-RS communication as higher priorities than dynamic r=
egistration.
Partially because they are more self contained issues.

John B.
On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:






In my opinion, dynamic client registration would allow us to drop publ=
ic client thus simplifying the core spec.

regards,
Torsten.

Am 15.03.2012 16:00, schrieb Eran Hammer:





I believe most do, except for the dynamic client registration. I don't=
 have strong objections to it, but it is the least important and least defi=
ned / deployed proposal on the list. The AS->RS work is probably simpler=
 and more useful at this point.

EH






-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be=
half
Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, March 15, 2012 4:47 AM
To: ext Blaine Cook; Hannes Tschofenig
Cc: oa=
uth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Hi Blaine,

These are indeed good requirements you stated below.

When you look at the list of topics do you think that the proposed items
indeed fulfill them?

Ciao
Hannes







-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be=
half
Of ext Blaine Cook
Sent: Thursday, March 15, 2012 1:31 PM
To: Hannes Tschofenig
Cc: oa=
uth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

On 14 March 2012 20:21, Hannes Tschofenig





 




wrote:





So, here is a proposal:

[Editor's Note: New work for the group. 5 items maximum! ]

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration





as a Proposed Standard





Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for





consideration as a Proposed Standard





Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for





OAuth 2.0' to the IESG for consideration





Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to





the IESG for consideration as a Proposed Standard





Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration





as an Informational RFC

This looks great to me.

I have serious concerns about feature-creep, and think that the OAuth
WG should strongly limit its purview to these issues. In general, I
think it prudent for this working group in particular to consider
standardisation of work only under the following criteria:

1. Proposals must have a direct relationship to the mechanism of OAuth
(and not, specifically, bound to an application-level protocol).
2. Proposals must have significant adoption in both enterprise and
startup environments.
3. Any proposal must be driven based on a consideration of the
different approaches, as adopted in the wild, and strive to be a
better synthesis of those approaches, not a means to an end.

These are the constraints with which I started the OAuth project, and
they're more relevant than ever. I'd hate to see OAuth fail in the end
because of a WS-*-like death by standards-pile-on.

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





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





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





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





 





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







 



--=_f794bb86ad11f01614127e3bda11680f--


From ve7jtb@ve7jtb.com  Thu Mar 22 06:25:04 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE22B21F861A for ; Thu, 22 Mar 2012 06:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level: 
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=0.348,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNDexpqp6apx for ; Thu, 22 Mar 2012 06:25:04 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09BF721F8604 for ; Thu, 22 Mar 2012 06:25:03 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so1924650ggm.31 for ; Thu, 22 Mar 2012 06:25:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=pVKAraX5ULZVHp49CovQ1V/6zCbLEYS1ydlLIiEdAkk=; b=G8zMbTnlZS+5WEe0aCAda04Kv25dvBHTZawYk/irfb+JS4ufnLFpnbqdVnfvw/PWEV d/CLzWTRN/W0G8PoI68VBdX9xXO9CMpeE8SD6NlcwasmYAEEXrXKKMy3Uyd5n3y1DMr2 G28Hcg+UIiRQQJ+QmUZvko6ZwsJlQegtNx3vBA3h8OYpNWZY2gvgu0WPCUDFfLp66MJO m7gQWXdA+MgTNH5UtkVWcKtnPMR7BvRbEQJ/2JVjRn2YzFAmMN2pnsvPXKipEBUE9iTI An0sYzNg+Zi75Uo57BC/7Gefq/F+hDzb5Nre8HsSMGUhSMObYdCXKhbEdGPZXCc1Fle+ pQjg==
Received: by 10.100.81.10 with SMTP id e10mr2406155anb.77.1332422703402; Thu, 22 Mar 2012 06:25:03 -0700 (PDT)
Received: from [192.168.1.213] (190-20-46-22.baf.movistar.cl. [190.20.46.22]) by mx.google.com with ESMTPS id 34sm6190048anu.6.2012.03.22.06.24.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 06:25:02 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_23DA8A3D-A422-4A40-B230-47E3281D1FBE"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <4bec89cc2d73c8814b94c8cfeb3e9776@lodderstedt-online.de>
Date: Thu, 22 Mar 2012 10:24:35 -0300
Message-Id: <487834D3-8E35-4452-A1B1-9C26CBEEDC3F@ve7jtb.com>
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net> <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com> <4bec89cc2d73c8814b94c8cfeb3e9776@lodderstedt-online.de>
To: Torsten Lodderstedt 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQlgdvyTXdOa2IXIqrMmIkI6Pu5uRXdt/8N8O0l4PfrZ6gWR2xVralwfdIaeAT/3vH6ovVMe
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 13:25:05 -0000

--Apple-Mail=_23DA8A3D-A422-4A40-B230-47E3281D1FBE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

In Connect's dynamic client authentication we optionally allow for =
authenticated clients to register.

The idea is that you can have a master token pre provisioned in an app =
and then use that to get an individual client ID and client secret for a =
native app on a per instance basis.
This is useful to UMA, and potentially other cases where de-authorizing =
a particular instance of a client from using it's refresh token would be =
useful.

So I agree that obtaining a clientID and secret on activation is useful.

While you could theoretically move JS clients who are public now to a =
registration and code flow it is unclear to me if that actually adds any =
real security. =20
I can see a simplification of the AS argument,  but at a performance =
cost to the client.

As to the refresh token argument, it seems that Facebook at least has =
moved to refreshing access tokens directly to get around the implicit =
grant problem.

I am for Dynamic client registration, I just don't think it is a silver =
bullet, and needs significant thought.

I admit that openID is not under time pressure on this as we have our =
own extension,  that is not intended to be generic.
However we did make registration a separate spec so that people can =
reuse the pattern if it works for them, but mostly to make it easier for =
us to move to a eventual standard without modifying the core spec.

John B.

On 2012-03-22, at 5:29 AM, Torsten Lodderstedt wrote:

> Hi John,
>=20
>> I don't think dynamic registration completely removes the need for a
>> public client, that can't keep secrets.
>=20
> I don't get this argument. In my opinion, there are two use cases, =
which currently motivate usage of public clients and none of them is =
about "keeping secrets".
>=20
> 1) native apps - There is no mechanism for securely _provisioning_ =
those clients with client secrets. So it does not make sense to use =
secrets for authenticating them. Dynamic client registration would allow =
them to obtain client id and secret on activation/installation. The =
security of the respective secret is the same as for refresh tokens. So =
either both can be protected appropriately or none of them. Please note: =
I'm not talking about trust in the identity/authenticity of the =
particular app installation. I'm just talking about simplifying the =
OAuth flows and description. Today an AS needs to support the refresh =
tokens or resource owner grant type for both confidential and public =
clients in order to also support native apps.
> 2) implicit grant - here, public clients are used because the protocol =
design itself does not allows for validating client secrets. Obviously, =
digital signature would help but make the protocol more difficult to =
use.
>=20
> Basically, dynamic client registration allows a client to bind to an =
AS at runtime. That's what it makes so valuable with respect to =
interoperatibility. Whether the client just registers meta data or also =
obtains a secret is another aspect but not the only one.
>=20
> regards,
> Torsten.
>=20
>>=20
>> While we did do dynamic client registration for Connect that is a
>> more constrained use case.
>> I would put JWT and AS-RS communication as higher priorities than
>> dynamic registration.
>> Partially because they are more self contained issues.
>>=20
>> John B.
>> On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
>>=20
>>> In my opinion, dynamic client registration would allow us to drop =
public client thus simplifying the core spec.
>>>=20
>>> regards,
>>> Torsten.
>>>=20
>>> Am 15.03.2012 16:00, schrieb Eran Hammer:
>>>> I believe most do, except for the dynamic client registration. I =
don't have strong objections to it, but it is the least important and =
least defined / deployed proposal on the list. The AS->RS work is =
probably simpler and more useful at this point.
>>>>=20
>>>> EH
>>>>=20
>>>>> -----Original Message-----
>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>>>> Of Tschofenig, Hannes (NSN - FI/Espoo)
>>>>> Sent: Thursday, March 15, 2012 4:47 AM
>>>>> To: ext Blaine Cook; Hannes Tschofenig
>>>>> Cc: oauth@ietf.org
>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>>=20
>>>>> Hi Blaine,
>>>>>=20
>>>>> These are indeed good requirements you stated below.
>>>>>=20
>>>>> When you look at the list of topics do you think that the proposed =
items
>>>>> indeed fulfill them?
>>>>>=20
>>>>> Ciao
>>>>> Hannes
>>>>>=20
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>>>>> Of ext Blaine Cook
>>>>>> Sent: Thursday, March 15, 2012 1:31 PM
>>>>>> To: Hannes Tschofenig
>>>>>> Cc: oauth@ietf.org WG
>>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>>>=20
>>>>>> On 14 March 2012 20:21, Hannes Tschofenig
>>>>> 
>>>>>> wrote:
>>>>>>> So, here is a proposal:
>>>>>>>=20
>>>>>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>>>>>>=20
>>>>>>> Aug. 2012    Submit 'Token Revocation' to the IESG for =
consideration
>>>>>> as a Proposed Standard
>>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
>>>>>> consideration as a Proposed Standard
>>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles =
for
>>>>>> OAuth 2.0' to the IESG for consideration
>>>>>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' =
to
>>>>>> the IESG for consideration as a Proposed Standard
>>>>>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for =
consideration
>>>>>> as an Informational RFC
>>>>>>=20
>>>>>> This looks great to me.
>>>>>>=20
>>>>>> I have serious concerns about feature-creep, and think that the =
OAuth
>>>>>> WG should strongly limit its purview to these issues. In general, =
I
>>>>>> think it prudent for this working group in particular to consider
>>>>>> standardisation of work only under the following criteria:
>>>>>>=20
>>>>>> 1. Proposals must have a direct relationship to the mechanism of =
OAuth
>>>>>> (and not, specifically, bound to an application-level protocol).
>>>>>> 2. Proposals must have significant adoption in both enterprise =
and
>>>>>> startup environments.
>>>>>> 3. Any proposal must be driven based on a consideration of the
>>>>>> different approaches, as adopted in the wild, and strive to be a
>>>>>> better synthesis of those approaches, not a means to an end.
>>>>>>=20
>>>>>> These are the constraints with which I started the OAuth project, =
and
>>>>>> they're more relevant than ever. I'd hate to see OAuth fail in =
the end
>>>>>> because of a WS-*-like death by standards-pile-on.
>>>>>>=20
>>>>>> b.
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_23DA8A3D-A422-4A40-B230-47E3281D1FBE
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMy
MjEzMjQzNVowIwYJKoZIhvcNAQkEMRYEFNc3FN9X0W6bf4w511Ny4Wi6mBXIMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
ACXThPdnhRD3NHcaYJKYJHCIYb/8ZPdKq0dYuLELOm9niJl4nAVF6aEz9/ZupdrMfXpKJ3z4y4vG
Uk6eSGgPPLBh6tTukJmvkd01cKc4ihlcBfPyXitqzjc21zlLxT/2ht+NkL2vMN6u9FEq/q6zmqWi
kPThP9ne7H+MS5Wz+fPhXR8v68vhKuG96gwCp0kY1MHWLJXEscJJoPsLZ6Fu5lQXOMOPXGzYYej8
nSyzXplZMP1CAwkevVYLxOHtkpAP7FnXuxuCkZ9Xv+JikpgR/eY2Klb2N6CZlf/NgPwQi0tfMP/a
mQ/26F4eha/wjG7s5jJyIhunGtAKluVKVspYBFMAAAAAAAA=

--Apple-Mail=_23DA8A3D-A422-4A40-B230-47E3281D1FBE--

From gffletch@aol.com  Thu Mar 22 06:28:36 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E75721F861B for ; Thu, 22 Mar 2012 06:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYjT8xkYDj34 for ; Thu, 22 Mar 2012 06:28:35 -0700 (PDT)
Received: from imr-ma02.mx.aol.com (imr-ma02.mx.aol.com [64.12.206.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0F721F860B for ; Thu, 22 Mar 2012 06:28:35 -0700 (PDT)
Received: from mtaout-ma04.r1000.mx.aol.com (mtaout-ma04.r1000.mx.aol.com [172.29.41.4]) by imr-ma02.mx.aol.com (8.14.1/8.14.1) with ESMTP id q2MDSOhc012372; Thu, 22 Mar 2012 09:28:24 -0400
Received: from palantir.local (unknown [10.172.3.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id C1E7EE0000EA; Thu, 22 Mar 2012 09:28:20 -0400 (EDT)
Message-ID: <4F6B28F0.7010607@aol.com>
Date: Thu, 22 Mar 2012 09:28:16 -0400
From: George Fletcher 
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Torsten Lodderstedt 
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net> <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com> <4F6A3F22.6060809@aol.com> <8708c9bdf1e08a7b7ea3cb158add7e2a@lodderstedt-online.de>
In-Reply-To: <8708c9bdf1e08a7b7ea3cb158add7e2a@lodderstedt-online.de>
Content-Type: multipart/alternative; boundary="------------000403000502090609040508"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1332422904; bh=oRVR6PO5Sfvze9mv1DqHN4nTG7LNF4/N8xeT+Gkwd3k=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=J8iKxwJiPLyj2WzA3EwxeYitsD5UDGz7EuVPMurX0JbUzjl8pa6AllbC95c1Hfrlu ieeGwc+JgYM9Q6vdhe1zL588xlDX3lApEd6DhhPhHPy6cxFu3+33hyju9eywxd5fWf 8c06Y0iwDR8oD+aM7FjRyrKe3cHJeKh2Gb18mD+I=
X-AOL-SCOLL-SCORE: 0:2:458257984:93952408  
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d29044f6b28f42f40
X-AOL-IP: 10.172.3.218
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 13:28:36 -0000

This is a multi-part message in MIME format.
--------------000403000502090609040508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Torsten,

I guess I worry that trying to solve all the use cases that get pulled 
in with dynamic client registration will take a long time. I've been 
involved with both the UMA work and the OpenID Connect work regarding 
dynamic client registration and some reasonable constraints and 
expectations need to be set in order to reach consensus.

And what John said... since he beat my response:)

Thanks,
George

On 3/22/12 4:40 AM, Torsten Lodderstedt wrote:
>
> Hi George,
>
> I see two distinct areas of interoperability, which are Client-AS and 
> AS-RS. Dynamic client registration belongs to Client-AS whereas JWT & 
> AS-RS communication belong to the later area.
>
> OAuth 2.0 currently (not fully) covers Client-AS and does not address 
> AS-RS. In my opinion, the WG should decide whether we first complete 
> Client-AS and address AS-RS later on or vice versa.
>
> I'm in favour of completing Client-AS first and consider client 
> registration a major missing piece. Why? Because otherwise clients 
> cannot dynamically bind to any OAuth-AS at runtime but have to 
> pre-register (with any?) :-(.
>
> regards,
> Torsten.
>
> Am 21.03.2012 21:50, schrieb George Fletcher:
>
>> +1 to JWT and AS-RS communication over dynamic registration
>>
>> On 3/21/12 3:52 PM, John Bradley wrote:
>>> I don't think dynamic registration completely removes the need for a public client, that can't keep secrets.
>>>
>>> While we did do dynamic client registration for Connect that is a more constrained use case.
>>> I would put JWT and AS-RS communication as higher priorities than dynamic registration.
>>> Partially because they are more self contained issues.
>>>
>>> John B.
>>> On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
>>>
>>>> In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec.
>>>>
>>>> regards,
>>>> Torsten.
>>>>
>>>> Am 15.03.2012 16:00, schrieb Eran Hammer:
>>>>> I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS->RS work is probably simpler and more useful at this point.
>>>>>
>>>>> EH
>>>>>
>>>>>> -----Original Message-----
>>>>>> From:oauth-bounces@ietf.org  [mailto:oauth-bounces@ietf.org] On Behalf
>>>>>> Of Tschofenig, Hannes (NSN - FI/Espoo)
>>>>>> Sent: Thursday, March 15, 2012 4:47 AM
>>>>>> To: ext Blaine Cook; Hannes Tschofenig
>>>>>> Cc:oauth@ietf.org
>>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>>>
>>>>>> Hi Blaine,
>>>>>>
>>>>>> These are indeed good requirements you stated below.
>>>>>>
>>>>>> When you look at the list of topics do you think that the proposed items
>>>>>> indeed fulfill them?
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From:oauth-bounces@ietf.org  [mailto:oauth-bounces@ietf.org] On Behalf
>>>>>>> Of ext Blaine Cook
>>>>>>> Sent: Thursday, March 15, 2012 1:31 PM
>>>>>>> To: Hannes Tschofenig
>>>>>>> Cc:oauth@ietf.org  WG
>>>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>>>>
>>>>>>> On 14 March 2012 20:21, Hannes Tschofenig
>>>>>>   
>>>>>>> wrote:
>>>>>>>> So, here is a proposal:
>>>>>>>>
>>>>>>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>>>>>>>
>>>>>>>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration
>>>>>>> as a Proposed Standard
>>>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
>>>>>>> consideration as a Proposed Standard
>>>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
>>>>>>> OAuth 2.0' to the IESG for consideration
>>>>>>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to
>>>>>>> the IESG for consideration as a Proposed Standard
>>>>>>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration
>>>>>>> as an Informational RFC
>>>>>>>
>>>>>>> This looks great to me.
>>>>>>>
>>>>>>> I have serious concerns about feature-creep, and think that the OAuth
>>>>>>> WG should strongly limit its purview to these issues. In general, I
>>>>>>> think it prudent for this working group in particular to consider
>>>>>>> standardisation of work only under the following criteria:
>>>>>>>
>>>>>>> 1. Proposals must have a direct relationship to the mechanism of OAuth
>>>>>>> (and not, specifically, bound to an application-level protocol).
>>>>>>> 2. Proposals must have significant adoption in both enterprise and
>>>>>>> startup environments.
>>>>>>> 3. Any proposal must be driven based on a consideration of the
>>>>>>> different approaches, as adopted in the wild, and strive to be a
>>>>>>> better synthesis of those approaches, not a means to an end.
>>>>>>>
>>>>>>> These are the constraints with which I started the OAuth project, and
>>>>>>> they're more relevant than ever. I'd hate to see OAuth fail in the end
>>>>>>> because of a WS-*-like death by standards-pile-on.
>>>>>>>
>>>>>>> b.
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>   
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth


--------------000403000502090609040508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Torsten,

    

    I guess I worry that trying to solve all the use cases that get
    pulled in with dynamic client registration will take a long time.
    I've been involved with both the UMA work and the OpenID Connect
    work regarding dynamic client registration and some reasonable
    constraints and expectations need to be set in order to reach
    consensus.

    

    And what John said... since he beat my response:)

    

    Thanks,

    George

    

    On 3/22/12 4:40 AM, Torsten Lodderstedt wrote:
    

      
Hi George,

      
I see two distinct areas of interoperability, which are
        Client-AS and AS-RS. Dynamic client registration belongs to
        Client-AS whereas JWT & AS-RS communication belong to the
        later area.

      
OAuth 2.0 currently (not fully) covers Client-AS and does not
        address AS-RS. In my opinion, the WG should decide whether we
        first complete Client-AS and address AS-RS later on or vice
        versa.

      
I'm in favour of completing Client-AS first and consider client
        registration a major missing piece. Why? Because otherwise
        clients cannot dynamically bind to any OAuth-AS at runtime but
        have to pre-register (with any?) :-(.

      
regards,

        Torsten.

      
 

      
Am 21.03.2012 21:50, schrieb George Fletcher:

      
+1 to JWT
          and AS-RS communication over dynamic registration

        

        On 3/21/12 3:52 PM, John Bradley wrote:
        

          
I don't think dynamic registration completely removes the need for a public client, that can't keep secrets.

While we did do dynamic client registration for Connect that is a more constrained use case.
I would put JWT and AS-RS communication as higher priorities than dynamic registration.
Partially because they are more self contained issues.

John B.
On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:



          

            
In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec.

regards,
Torsten.

Am 15.03.2012 16:00, schrieb Eran Hammer:


            

              
I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS->RS work is probably simpler and more useful at this point.

EH



              

                
-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, March 15, 2012 4:47 AM
To: ext Blaine Cook; Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Hi Blaine,

These are indeed good requirements you stated below.

When you look at the list of topics do you think that the proposed items
indeed fulfill them?

Ciao
Hannes




                

                  
-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of ext Blaine Cook
Sent: Thursday, March 15, 2012 1:31 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

On 14 March 2012 20:21, Hannes Tschofenig


                

                
 

                

                  
wrote:


                  

                    
So, here is a proposal:

[Editor's Note: New work for the group. 5 items maximum! ]

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration


                  

                  
as a Proposed Standard


                  

                    
Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for


                  

                  
consideration as a Proposed Standard


                  

                    
Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for


                  

                  
OAuth 2.0' to the IESG for consideration


                  

                    
Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to


                  

                  
the IESG for consideration as a Proposed Standard


                  

                    
Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration


                  

                  
as an Informational RFC

This looks great to me.

I have serious concerns about feature-creep, and think that the OAuth
WG should strongly limit its purview to these issues. In general, I
think it prudent for this working group in particular to consider
standardisation of work only under the following criteria:

1. Proposals must have a direct relationship to the mechanism of OAuth
(and not, specifically, bound to an application-level protocol).
2. Proposals must have significant adoption in both enterprise and
startup environments.
3. Any proposal must be driven based on a consideration of the
different approaches, as adopted in the wild, and strive to be a
better synthesis of those approaches, not a means to an end.

These are the constraints with which I started the OAuth project, and
they're more relevant than ever. I'd hate to see OAuth fail in the end
because of a WS-*-like death by standards-pile-on.

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


                

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


              

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


            

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


          

          
 

          

          

          

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


        

      

      
 

    

    

  


--------------000403000502090609040508--

From Michael.Jones@microsoft.com  Thu Mar 22 08:35:18 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B1221F84F9 for ; Thu, 22 Mar 2012 08:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.835
X-Spam-Level: 
X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkNuC8i3FYRT for ; Thu, 22 Mar 2012 08:35:17 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2201A21F84B9 for ; Thu, 22 Mar 2012 08:35:17 -0700 (PDT)
Received: from mail41-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Thu, 22 Mar 2012 15:35:09 +0000
Received: from mail41-ch1 (localhost [127.0.0.1])	by mail41-ch1-R.bigfish.com (Postfix) with ESMTP id 7FBF960146	for ; Thu, 22 Mar 2012 15:35:08 +0000 (UTC)
X-SpamScore: -49
X-BigFish: VS-49(zzbb2dI9371I936eKc85fh1b0bM542M98dK4015I199bRzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail41-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail41-ch1 (localhost.localdomain [127.0.0.1]) by mail41-ch1 (MessageSwitch) id 1332430505528575_3635; Thu, 22 Mar 2012 15:35:05 +0000 (UTC)
Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247])	by mail41-ch1.bigfish.com (Postfix) with ESMTP id 7D6064201F8 for ; Thu, 22 Mar 2012 15:35:05 +0000 (UTC)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 22 Mar 2012 15:35:02 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0283.004; Thu, 22 Mar 2012 15:34:55 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAMCRIf4APwgUm5DSot8V56SZZrOgWAgAAERQCAADYZgIAJuwoAgAAEowCAABA+AIAAxjiAgABQgACAACLxwA==
Date: Thu, 22 Mar 2012 15:34:54 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436642CABB@TK5EX14MBXC284.redmond.corp.microsoft.com>
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net> <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>	<4F6A3F22.6060809@aol.com> <8708c9bdf1e08a7b7ea3cb158add7e2a@lodderstedt-online.de> <4F6B28F0.7010607@aol.com>
In-Reply-To: <4F6B28F0.7010607@aol.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436642CABBTK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 15:35:18 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436642CABBTK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI, the OpenID Connect dynamic client registration spec is at http://openi=
d.net/specs/openid-connect-registration-1_0.html.  You can find points to a=
ll the Connect specs at http://openid.net/connect/.

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of G=
eorge Fletcher
Sent: Thursday, March 22, 2012 6:28 AM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Hi Torsten,

I guess I worry that trying to solve all the use cases that get pulled in w=
ith dynamic client registration will take a long time. I've been involved w=
ith both the UMA work and the OpenID Connect work regarding dynamic client =
registration and some reasonable constraints and expectations need to be se=
t in order to reach consensus.

And what John said... since he beat my response:)

Thanks,
George

On 3/22/12 4:40 AM, Torsten Lodderstedt wrote:

Hi George,

I see two distinct areas of interoperability, which are Client-AS and AS-RS=
. Dynamic client registration belongs to Client-AS whereas JWT & AS-RS comm=
unication belong to the later area.

OAuth 2.0 currently (not fully) covers Client-AS and does not address AS-RS=
. In my opinion, the WG should decide whether we first complete Client-AS a=
nd address AS-RS later on or vice versa.

I'm in favour of completing Client-AS first and consider client registratio=
n a major missing piece. Why? Because otherwise clients cannot dynamically =
bind to any OAuth-AS at runtime but have to pre-register (with any?) :-(.

regards,
Torsten.



Am 21.03.2012 21:50, schrieb George Fletcher:
+1 to JWT and AS-RS communication over dynamic registration

On 3/21/12 3:52 PM, John Bradley wrote:

I don't think dynamic registration completely removes the need for a public=
 client, that can't keep secrets.



While we did do dynamic client registration for Connect that is a more cons=
trained use case.

I would put JWT and AS-RS communication as higher priorities than dynamic r=
egistration.

Partially because they are more self contained issues.



John B.

On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:



In my opinion, dynamic client registration would allow us to drop public cl=
ient thus simplifying the core spec.



regards,

Torsten.



Am 15.03.2012 16:00, schrieb Eran Hammer:

I believe most do, except for the dynamic client registration. I don't have=
 strong objections to it, but it is the least important and least defined /=
 deployed proposal on the list. The AS->RS work is probably simpler and mor=
e useful at this point.



EH



-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf

Of Tschofenig, Hannes (NSN - FI/Espoo)

Sent: Thursday, March 15, 2012 4:47 AM

To: ext Blaine Cook; Hannes Tschofenig

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering



Hi Blaine,



These are indeed good requirements you stated below.



When you look at the list of topics do you think that the proposed items

indeed fulfill them?



Ciao

Hannes





-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf

Of ext Blaine Cook

Sent: Thursday, March 15, 2012 1:31 PM

To: Hannes Tschofenig

Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering



On 14 March 2012 20:21, Hannes Tschofenig



wrote:

So, here is a proposal:



[Editor's Note: New work for the group. 5 items maximum! ]



Aug. 2012    Submit 'Token Revocation' to the IESG for consideration

as a Proposed Standard

Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for

consideration as a Proposed Standard

Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for

OAuth 2.0' to the IESG for consideration

Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to

the IESG for consideration as a Proposed Standard

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration

as an Informational RFC



This looks great to me.



I have serious concerns about feature-creep, and think that the OAuth

WG should strongly limit its purview to these issues. In general, I

think it prudent for this working group in particular to consider

standardisation of work only under the following criteria:



1. Proposals must have a direct relationship to the mechanism of OAuth

(and not, specifically, bound to an application-level protocol).

2. Proposals must have significant adoption in both enterprise and

startup environments.

3. Any proposal must be driven based on a consideration of the

different approaches, as adopted in the wild, and strive to be a

better synthesis of those approaches, not a means to an end.



These are the constraints with which I started the OAuth project, and

they're more relevant than ever. I'd hate to see OAuth fail in the end

because of a WS-*-like death by standards-pile-on.



b.

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth



--_000_4E1F6AAD24975D4BA5B16804296739436642CABBTK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











FYI, the OpenID Connect d=
ynamic client registration spec is at
ht=
tp://openid.net/specs/openid-connect-registration-1_0.html.  You c=
an find points to all the Connect specs at
http://openid.net/connect/.=



 <=
/p>

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


 <=
/p>





From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf=
.org]
On Behalf Of George Fletcher

Sent: Thursday, March 22, 2012 6:28 AM

To: Torsten Lodderstedt

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering






 


Hi Torsten,



I guess I worry that trying to solve all the use cases that get pulled in w=
ith dynamic client registration will take a long time. I've been involved w=
ith both the UMA work and the OpenID Connect work regarding dynamic client =
registration and some reasonable
 constraints and expectations need to be set in order to reach consensus.


And what John said... since he beat my response:)



Thanks,

George



On 3/22/12 4:40 AM, Torsten Lodderstedt wrote: 


Hi George,


I see two distinct areas of interoperability, which are Client-AS and AS=
-RS. Dynamic client registration belongs to Client-AS whereas JWT & AS-=
RS communication belong to the later area.


OAuth 2.0 currently (not fully) covers Client-AS and does not addre=
ss AS-RS. In my opinion, the WG should decide whether we first complete Cli=
ent-AS and address AS-RS later on or vice versa.


I'm in favour of completing Client-AS first and consider client registra=
tion a major missing piece. Why? Because otherwise clients cannot dynamical=
ly bind to any OAuth-AS at runtime but have to pre-register (with any?) :-(=
.


regards,

Torsten.


 


Am 21.03.2012 21:50, schrieb George Fletcher:




+1 to JWT and AS-RS communication over dynamic reg=
istration



On 3/21/12 3:52 PM, John Bradley wrote: 


I don't think dynamic registration completely removes the need for a p=
ublic client, that can't keep secrets.


 


While we did do dynamic client registration for Connect that is a more=
 constrained use case.


I would put JWT and AS-RS communication as higher priorities than dyna=
mic registration.


Partially because they are more self contained issues.

 


John B.


On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:


 




In my opinion, dynamic client registration would allow us to drop publ=
ic client thus simplifying the core spec.


 


regards,


Torsten.


 


Am 15.03.2012 16:00, schrieb Eran Hammer:




I believe most do, except for the dynamic client registration. I don't=
 have strong objections to it, but it is the least important and least defi=
ned / deployed proposal on the list. The AS->RS work is probably simpler=
 and more useful at this point.


 


EH


 




-----Original Message-----


From: oauth-bounces@ietf.org=
 [mailto:oauth-bounces@ietf.o=
rg] On Behalf


Of Tschofenig, Hannes (NSN - FI/Espoo)


Sent: Thursday, March 15, 2012 4:47 AM


To: ext Blaine Cook; Hannes Tschofenig


Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering


 


Hi Blaine,


 


These are indeed good requirements you stated below.


 


When you look at the list of topics do you think that the proposed ite=
ms


indeed fulfill them?


 


Ciao


Hannes


 


 




-----Original Message-----


From: oauth-bounces@ietf.org=
 [mailto:oauth-bounces@ietf.o=
rg] On Behalf


Of ext Blaine Cook


Sent: Thursday, March 15, 2012 1:31 PM


To: Hannes Tschofenig


Cc: oauth@ietf.org WG=



Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering


 


On 14 March 2012 20:21, Hannes Tschofenig




 




wrote:




So, here is a proposal:


 


[Editor's Note: New work for the group. 5 items maximum! ]<=
/pre>

 


Aug. 2012    Submit 'Token Revocation' to the IESG for =
consideration




as a Proposed Standard




Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG =
for




consideration as a Proposed Standard




Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token =
Profiles for




OAuth 2.0' to the IESG for consideration




Jan. 2013    Submit 'OAuth Dynamic Client Registration =
Protocol' to




the IESG for consideration as a Proposed Standard




Sep. 2012    Submit 'OAuth Use Cases' to the IESG for c=
onsideration




as an Informational RFC


 


This looks great to me.


 


I have serious concerns about feature-creep, and think that the OAuth<=
o:p>


WG should strongly limit its purview to these issues. In general, I


think it prudent for this working group in particular to consider=



standardisation of work only under the following criteria:<=
/pre>

 


1. Proposals must have a direct relationship to the mechanism of OAuth=



(and not, specifically, bound to an application-level protocol).<=
/o:p>


2. Proposals must have significant adoption in both enterprise and


startup environments.


3. Any proposal must be driven based on a consideration of the


different approaches, as adopted in the wild, and strive to be a<=
/o:p>


better synthesis of those approaches, not a means to an end.


 


These are the constraints with which I started the OAuth project, and<=
o:p>


they're more relevant than ever. I'd hate to see OAuth fail in the end=



because of a WS-*-like death by standards-pile-on.


 


b.


_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth




_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth




 









_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth






 




 






--_000_4E1F6AAD24975D4BA5B16804296739436642CABBTK5EX14MBXC284r_--

From phil.hunt@oracle.com  Thu Mar 22 09:24:57 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A801F21F8638 for ; Thu, 22 Mar 2012 09:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.319
X-Spam-Level: 
X-Spam-Status: No, score=-10.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ26s46KUp6s for ; Thu, 22 Mar 2012 09:24:56 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id D81D121F861E for ; Thu, 22 Mar 2012 09:24:55 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2MGOrZw029731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Mar 2012 16:24:54 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2MGOdon022628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2012 16:24:40 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2MGOdwf015522; Thu, 22 Mar 2012 11:24:39 -0500
Received: from [192.168.1.8] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Mar 2012 09:24:38 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8533C625-6D75-4F33-A392-4BE78C356718"
From: Phil Hunt 
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436642CABB@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Thu, 22 Mar 2012 09:24:37 -0700
Message-Id: 
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net> <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>	<4F6A3F22.6060809@aol.com> <8708c9bdf1e08a7b7ea3cb158add7e2a@lodderstedt-online.de> <4F6B28F0.7010607@aol.com> <4E1F6AAD24975D4BA5B16804296739436642CABB@TK5EX14MBXC284.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1257)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F6B5257.0039,ss=1,re=-6.500,fgs=0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 16:24:57 -0000

--Apple-Mail=_8533C625-6D75-4F33-A392-4BE78C356718
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Would the plan be for the Connect Registration spec to be submitted to =
IETF so they can become WG drafts?

The spec seems like a good starting point.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-03-22, at 8:34 AM, Mike Jones wrote:

> FYI, the OpenID Connect dynamic client registration spec is at =
http://openid.net/specs/openid-connect-registration-1_0.html.  You can =
find points to all the Connect specs at http://openid.net/connect/.
> =20
>                                                             -- Mike
> =20
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =
Of George Fletcher
> Sent: Thursday, March 22, 2012 6:28 AM
> To: Torsten Lodderstedt
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
> =20
> Hi Torsten,
>=20
> I guess I worry that trying to solve all the use cases that get pulled =
in with dynamic client registration will take a long time. I've been =
involved with both the UMA work and the OpenID Connect work regarding =
dynamic client registration and some reasonable constraints and =
expectations need to be set in order to reach consensus.
>=20
> And what John said... since he beat my response:)
>=20
> Thanks,
> George
>=20
> On 3/22/12 4:40 AM, Torsten Lodderstedt wrote:
> Hi George,
>=20
> I see two distinct areas of interoperability, which are Client-AS and =
AS-RS. Dynamic client registration belongs to Client-AS whereas JWT & =
AS-RS communication belong to the later area.
>=20
> OAuth 2.0 currently (not fully) covers Client-AS and does not address =
AS-RS. In my opinion, the WG should decide whether we first complete =
Client-AS and address AS-RS later on or vice versa.
>=20
> I'm in favour of completing Client-AS first and consider client =
registration a major missing piece. Why? Because otherwise clients =
cannot dynamically bind to any OAuth-AS at runtime but have to =
pre-register (with any?) :-(.
>=20
> regards,
> Torsten.
>=20
> =20
>=20
> Am 21.03.2012 21:50, schrieb George Fletcher:
>=20
> +1 to JWT and AS-RS communication over dynamic registration
>=20
> On 3/21/12 3:52 PM, John Bradley wrote:
> I don't think dynamic registration completely removes the need for a =
public client, that can't keep secrets.
> =20
> While we did do dynamic client registration for Connect that is a more =
constrained use case.
> I would put JWT and AS-RS communication as higher priorities than =
dynamic registration.
> Partially because they are more self contained issues.
> =20
> John B.
> On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
> =20
> In my opinion, dynamic client registration would allow us to drop =
public client thus simplifying the core spec.
> =20
> regards,
> Torsten.
> =20
> Am 15.03.2012 16:00, schrieb Eran Hammer:
> I believe most do, except for the dynamic client registration. I don't =
have strong objections to it, but it is the least important and least =
defined / deployed proposal on the list. The AS->RS work is probably =
simpler and more useful at this point.
> =20
> EH
> =20
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Thursday, March 15, 2012 4:47 AM
> To: ext Blaine Cook; Hannes Tschofenig
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
> =20
> Hi Blaine,
> =20
> These are indeed good requirements you stated below.
> =20
> When you look at the list of topics do you think that the proposed =
items
> indeed fulfill them?
> =20
> Ciao
> Hannes
> =20
> =20
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of ext Blaine Cook
> Sent: Thursday, March 15, 2012 1:31 PM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
> =20
> On 14 March 2012 20:21, Hannes Tschofenig
> =20
> wrote:
> So, here is a proposal:
> =20
> [Editor's Note: New work for the group. 5 items maximum! ]
> =20
> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration
> as a Proposed Standard
> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
> consideration as a Proposed Standard
> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
> OAuth 2.0' to the IESG for consideration
> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to
> the IESG for consideration as a Proposed Standard
> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration
> as an Informational RFC
> =20
> This looks great to me.
> =20
> I have serious concerns about feature-creep, and think that the OAuth
> WG should strongly limit its purview to these issues. In general, I
> think it prudent for this working group in particular to consider
> standardisation of work only under the following criteria:
> =20
> 1. Proposals must have a direct relationship to the mechanism of OAuth
> (and not, specifically, bound to an application-level protocol).
> 2. Proposals must have significant adoption in both enterprise and
> startup environments.
> 3. Any proposal must be driven based on a consideration of the
> different approaches, as adopted in the wild, and strive to be a
> better synthesis of those approaches, not a means to an end.
> =20
> These are the constraints with which I started the OAuth project, and
> they're more relevant than ever. I'd hate to see OAuth fail in the end
> because of a WS-*-like death by standards-pile-on.
> =20
> b.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_8533C625-6D75-4F33-A392-4BE78C356718
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Phil


On 2012-03-22, at 8:34 AM, Mike Jones wrote:

FYI, the OpenID Connect =
dynamic client registration spec is at   
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or=
g] On Behalf =
Of George =
Fletcher
Sent: Thursday, March 22, 2012 =
6:28 AM
To: Torsten =
Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG =
Re-Chartering
 
Hi Torsten,

I guess I worry that =
trying to solve all the use cases that get pulled in with dynamic client =
registration will take a long time. I've been involved with both the UMA =
work and the OpenID Connect work regarding dynamic client registration =
and some reasonable constraints and expectations need to be set in order =
to reach consensus.

And what John said... since he beat my =
response:)

Thanks,
George

On 3/22/12 4:40 AM, Torsten =
Lodderstedt wrote:
Hi George,
I see two distinct areas of interoperability, =
which are Client-AS and AS-RS. Dynamic client registration belongs to =
Client-AS whereas JWT & AS-RS communication belong to the later =
area.
regards,
Torsten.
+1 to JWT and AS-RS communication over dynamic =
registration

On 3/21/12 3:52 PM, John Bradley =
wrote:
I don't think dynamic registration =
completely removes the need for a public client, that can't keep =
secrets.
 
While we did do dynamic client registration for Connect =
that is a more constrained use case.
I would put JWT and AS-RS communication as higher =
priorities than dynamic registration.
Partially because they are more self contained =
issues.
 
John B.
On 2012-03-21, at 4:35 =
PM, Torsten Lodderstedt wrote:
In my opinion, dynamic client registration would allow =
us to drop public client thus simplifying the core =
spec.
 
regards,
 
Am 15.03.2012 16:00, schrieb Eran =
Hammer:
I believe most do, except for the dynamic client =
registration. I don't have strong objections to it, but it is the least =
important and least defined / deployed proposal on the list. The =
AS->RS work is probably simpler and more useful at this =
point.
 
EH
-----Original Message-----
From: Of Tschofenig, Hannes (NSN - =
FI/Espoo)
Sent: Thursday, March 15, =
2012 4:47 AM
To: ext Blaine Cook; =
Hannes Tschofenig
Cc: oauth@ietf.org
Subject: =
Re: [OAUTH-WG] OAuth WG Re-Chartering
 
Hi =
Blaine,
 
These are indeed good requirements you stated =
below.
 
When you look at the list of topics do you think that =
the proposed items
indeed fulfill =
them?
 
Ciao
 
 
-----Original =
Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
Of ext Blaine Cook
Sent: Thursday, March 15, 2012 1:31 =
PM
To: Hannes =
Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG =
Re-Chartering
On 14 March 2012 20:21, =
Hannes Tschofenig
wrote:
So, here is a =
proposal:
 
[Editor's Note: New work for the group. 5 items maximum! =
]
 
Aug. 2012    Submit 'Token Revocation' to =
the IESG for consideration
as a Proposed Standard
Nov. 2012    =
Submit 'JSON Web Token (JWT)' to the IESG =
for
consideration as a =
Proposed Standard
Nov. 2012    Submit 'JSON Web Token (JWT) =
Bearer Token Profiles for
OAuth 2.0' to the IESG for =
consideration
Jan. 2013    Submit 'OAuth Dynamic Client =
Registration Protocol' to
the IESG for consideration as a Proposed =
Standard
Sep. 2012    Submit 'OAuth Use Cases' to =
the IESG for consideration
as an Informational RFC
 
This looks great to =
me.
 
I have serious concerns about feature-creep, and think =
that the OAuth
WG should strongly =
limit its purview to these issues. In general, I
think it prudent for this working group in particular to =
consider
standardisation of work only =
under the following criteria:
1. Proposals must have a =
direct relationship to the mechanism of OAuth
(and not, specifically, bound to an application-level =
protocol).
2. Proposals must have =
significant adoption in both enterprise and
startup environments.
3. Any proposal must be driven based on a consideration =
of the
different approaches, as adopted in the =
wild, and strive to be a
better synthesis of =
those approaches, not a means to an end.
 
These are the =
constraints with which I started the OAuth project, =
and
they're more relevant than ever. I'd hate =
to see OAuth fail in the end
because of =
a WS-*-like death by standards-pile-on.
 
OAuth mailing list
OAuth@ietf.org
OAuth mailing list
OAuth@ietf.org
OAuth mailing list
OAuth@ietf.org
OAuth mailing list
OAuth@ietf.org
 
OAuth@ietf.org
 

Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 16:35:18 -0000

--_000_CB90A1A616C5Deranhueniversecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I really like the 5 items limit. If people are uncomfortable about leaving =
so many items off the charter, the charter can have an explicit line item f=
or further charter review once all work has been completed. This is the def=
ault process anyway, but people here tend to be over sensitive, you that's =
one way to address that concern.

Any item proposed must be supported by an existing I-D used as the basis fo=
r WG work, at least one editor with the capacity to see this work through, =
and sufficient WG interest to do the work. It must also be 100% relevant to=
 OAuth and belong in a security area working group.

I strongly believe that suggesting charter items without an existing draft =
is counter productive. If the work exists elsewhere, it must first be submi=
tted as an I-D before we discuss it.

EH


From: Phil Hunt >
Date: Thu, 22 Mar 2012 09:24:37 -0700
To: Mike Jones >
Cc: "oauth@ietf.org" >
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Would the plan be for the Connect Registration spec to be submitted to IETF=
 so they can become WG drafts?

The spec seems like a good starting point.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-03-22, at 8:34 AM, Mike Jones wrote:

FYI, the OpenID Connect dynamic client registration spec is at http://openi=
d.net/specs/openid-connect-registration-1_0.html.  You can find points to a=
ll the Connect specs at http://openid.net/connect/.

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, March 22, 2012 6:28 AM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Hi Torsten,

I guess I worry that trying to solve all the use cases that get pulled in w=
ith dynamic client registration will take a long time. I've been involved w=
ith both the UMA work and the OpenID Connect work regarding dynamic client =
registration and some reasonable constraints and expectations need to be se=
t in order to reach consensus.

And what John said... since he beat my response:)

Thanks,
George

On 3/22/12 4:40 AM, Torsten Lodderstedt wrote:

Hi George,

I see two distinct areas of interoperability, which are Client-AS and AS-RS=
. Dynamic client registration belongs to Client-AS whereas JWT & AS-RS comm=
unication belong to the later area.

OAuth 2.0 currently (not fully) covers Client-AS and does not address AS-RS=
. In my opinion, the WG should decide whether we first complete Client-AS a=
nd address AS-RS later on or vice versa.

I'm in favour of completing Client-AS first and consider client registratio=
n a major missing piece. Why? Because otherwise clients cannot dynamically =
bind to any OAuth-AS at runtime but have to pre-register (with any?) :-(.

regards,
Torsten.



Am 21.03.2012 21:50, schrieb George Fletcher:

+1 to JWT and AS-RS communication over dynamic registration

On 3/21/12 3:52 PM, John Bradley wrote:

I don't think dynamic registration completely removes the need for a public=
 client, that can't keep secrets.



While we did do dynamic client registration for Connect that is a more cons=
trained use case.

I would put JWT and AS-RS communication as higher priorities than dynamic r=
egistration.

Partially because they are more self contained issues.



John B.

On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:



In my opinion, dynamic client registration would allow us to drop public cl=
ient thus simplifying the core spec.



regards,

Torsten.



Am 15.03.2012 16:00, schrieb Eran Hammer:

I believe most do, except for the dynamic client registration. I don't have=
 strong objections to it, but it is the least important and least defined /=
 deployed proposal on the list. The AS->RS work is probably simpler and mor=
e useful at this point.



EH



-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf

Of Tschofenig, Hannes (NSN - FI/Espoo)

Sent: Thursday, March 15, 2012 4:47 AM

To: ext Blaine Cook; Hannes Tschofenig

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering



Hi Blaine,



These are indeed good requirements you stated below.



When you look at the list of topics do you think that the proposed items

indeed fulfill them?



Ciao

Hannes





-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf

Of ext Blaine Cook

Sent: Thursday, March 15, 2012 1:31 PM

To: Hannes Tschofenig

Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering



On 14 March 2012 20:21, Hannes Tschofenig



wrote:

So, here is a proposal:



[Editor's Note: New work for the group. 5 items maximum! ]



Aug. 2012    Submit 'Token Revocation' to the IESG for consideration

as a Proposed Standard

Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for

consideration as a Proposed Standard

Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for

OAuth 2.0' to the IESG for consideration

Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to

the IESG for consideration as a Proposed Standard

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration

as an Informational RFC



This looks great to me.



I have serious concerns about feature-creep, and think that the OAuth

WG should strongly limit its purview to these issues. In general, I

think it prudent for this working group in particular to consider

standardisation of work only under the following criteria:



1. Proposals must have a direct relationship to the mechanism of OAuth

(and not, specifically, bound to an application-level protocol).

2. Proposals must have significant adoption in both enterprise and

startup environments.

3. Any proposal must be driven based on a consideration of the

different approaches, as adopted in the wild, and strive to be a

better synthesis of those approaches, not a means to an end.



These are the constraints with which I started the OAuth project, and

they're more relevant than ever. I'd hate to see OAuth fail in the end

because of a WS-*-like death by standards-pile-on.



b.

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth



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


--_000_CB90A1A616C5Deranhueniversecom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I really like the 5 item=
s limit. If people are uncomfortable about leaving so many items off the ch=
arter, the charter can have an explicit line item for further charter revie=
w once all work has been completed. This is the default process anyway, but=
 people here tend to be over sensitive, you that's one way to address that =
concern.

Any item proposed must be supported by an=
 existing I-D used as the basis for WG work, at least one editor with the c=
apacity to see this work through, and sufficient WG interest to do the work=
. It must also be 100% relevant to OAuth and belong in a security area work=
ing group.

I strongly believe that suggesting char=
ter items without an existing draft is counter productive. If the work exis=
ts elsewhere, it must first be submitted as an I-D before we discuss it.

EH


From:  Phil Hunt <phil.hunt@oracle.com>
Date:  Thu, 22 Mar 2012 09:24:37 -0700
To:  Mike Jones <Michael.Jones@microsoft.com>
Cc:  "oauth@ietf.org=
" <oauth@ietf.org>
Subject:  Re: [OAUTH-WG] OAuth WG Re-Charter=
ing

Would th=
e plan be for the Connect Registration spec to be submitted to IETF so they=
 can become WG drafts?

The spec seems like a good =
starting point.

Phil
<=
div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-=
break: after-white-space; ">



On 2012-03-22, at 8:34 A=
M, Mike Jones wrote:

FYI, the OpenID Connect dynamic clien=
t registration spec is at http://openid.net/specs/=
openid-connect-registration-1_0.html.  You can find points to all =
the Connect specs at http://openid.net/connect/.
 
          &n=
bsp;            =
;            &n=
bsp;            =
;            -- Mike=

 <=
/span>
From: oau=
th-bounces@ietf.org [=
mailto:oauth-bounces@ietf.org=
] On Behalf Of George Fletcher
Sent:<=
/b> Thursday, March 22, 2=
012 6:28 AM
To: Torsten Lodderstedt
Cc:&nb=
sp;oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
 
Hi Torsten,

I guess I worry that trying to solve all the u=
se cases that get pulled in with dynamic client registration will take a lo=
ng time. I've been involved with both the UMA work and the OpenID Connect w=
ork regarding dynamic client registration and some reasonable constraints a=
nd expectations need to be set in order to reach consensus.

And what=
 John said... since he beat my response:)

Thanks,
George

O=
n 3/22/12 4:40 AM, Torsten Lodderstedt wrote:
Hi George,
I see two distinct areas of interoperability, =
which are Client-AS and AS-RS. Dynamic client registration belongs to Clien=
t-AS whereas JWT & AS-RS communication belong to the later area.
OAuth 2.0 curren=
tly (not fully) covers Client-AS and does not address AS-RS. In my opi=
nion, the WG should decide whether we first complete Client-AS and address =
AS-RS later on or vice versa.
I'm in favour of completing Client-AS first and consider cli=
ent registration a major missing piece. Why? Because otherwise clients cann=
ot dynamically bind to any OAuth-AS at runtime but have to pre-register (wi=
th any?) :-(.
r=
egards,
Torsten.
 
Am =
21.03.2012 21:50, schrieb George Fletcher:
+1 to JWT and AS-RS communic=
ation over dynamic registration

On 3/21/12 3:52 PM, John Brad=
ley wrote:
I don't think dynamic registration completel=
y removes the need for a public client, that can't keep secrets.=

 
While we did do dynamic client registr=
ation for Connect that is a more constrained use case.
=
I would put JWT and AS-RS communication as higher priorities than dynamic r=
egistration.
Partially because they are more self conta=
ined issues.
 
John B.
On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
 
In my opinion, dynamic client registrati=
on would allow us to drop public client thus simplifying the core spec.
 
regards,
To=
rsten.
 
Am 15.03.2012 16:00, =
schrieb Eran Hammer:
I believe most do, except for the dyna=
mic client registration. I don't have strong objections to it, but it is th=
e least important and least defined / deployed proposal on the list. The AS=
->RS work is probably simpler and more useful at this point.<=
/pre>
 
EH
 
-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@iet=
f.org] On Behalf
Of Tschofenig, Hannes (NSN - FI/Es=
poo)
Sent: Thursday, March 15, 2012 4:47 AM<=
/pre>
To: ext Blaine Cook; Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAu=
th WG Re-Chartering
 
Hi Bla=
ine,
 
These are indeed good r=
equirements you stated below.
 
indeed fulfill them?
 
Ciao
Hannes
 =
;
 
-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
O=
f ext Blaine Cook
Sent: Thursday, March 15, 2012 1:31 P=
M
To: Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth=
 WG Re-Chartering
 
On 14 Marc=
h 2012 20:21, Hannes Tschofenig
 
wrote:
So, here is a proposal:
 
[Editor's Note: New work for the group. 5 i=
tems maximum! ]
 
Aug. 2012&nb=
sp;   Submit 'Token Revocation' to the IESG for consideration
as a Proposed Standard
Nov. 2=
012    Submit 'JSON Web Token (JWT)' to the IESG for
consideration as a Proposed Standard
=

Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token P=
rofiles for
OAuth 2.0' to the IESG for con=
sideration
Jan. 2013    Submit 'OAuth Dynami=
c Client Registration Protocol' to
the IE=
SG for consideration as a Proposed Standard
Sep. 2012 =
   Submit 'OAuth Use Cases' to the IESG for consideration
as an Informational RFC
=
 
This looks great to me.
&nbs=
p;
I have serious concerns about feature-creep, and think th=
at the OAuth
WG should strongly limit its purview to th=
ese issues. In general, I
think it prudent for this wor=
king group in particular to consider
standardisation of=
 work only under the following criteria:
 
1. Proposals must have a direct relationship to the mechanism =
of OAuth
(and not, specifically, bound to an applicatio=
n-level protocol).
2. Proposals must have significant a=
doption in both enterprise and
startup environments.
3. Any proposal must be driven based on a consideration o=
f the
different approaches, as adopted in the wild, and=
 strive to be a
better synthesis of those approaches, n=
ot a means to an end.
 
These =
are the constraints with which I started the OAuth project, and<=
/pre>
they're more relevant than ever. I'd hate to see OAuth fail in the=
 end
because of a WS-*-like death by standards-pile-on.=

 
b.
____=
___________________________________________
OAuth maili=
ng list
OAuth@ietf.org
<=
pre style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-b=
ottom: 0.0001pt; font-size: 10pt; font-family: 'Courier New'; color: black;=
 ">https://www.ietf.org/mailman/listinfo/o=
auth
_________________________________=
______________
OAuth mailing list
<=
a href=3D"mailto:OAuth@ietf.org" style=3D"color: blue; text-decoration: und=
erline; ">OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<=
o:p>
https://www.ietf.org/m=
ailman/listinfo/oauth
________________=
_______________________________
OAuth mailing list=

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

<=
br>
_______________________________________________
OAuth mailing list
OAuth@ie=
tf.org
https://www=
.ietf.org/mailman/listinfo/oauth
 
 
_______________________________________________
OAuth mailing l=
ist
OAuth@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/oauth



--_000_CB90A1A616C5Deranhueniversecom_--

From ve7jtb@ve7jtb.com  Thu Mar 22 09:43:49 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C076721F852D for ; Thu, 22 Mar 2012 09:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.285
X-Spam-Level: 
X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=0.313,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LLMvkPXwK-O for ; Thu, 22 Mar 2012 09:43:48 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B90321F8528 for ; Thu, 22 Mar 2012 09:43:47 -0700 (PDT)
Received: by yenm5 with SMTP id m5so2154145yen.31 for ; Thu, 22 Mar 2012 09:43:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=jHy9jXH6/E4vSGtV1M5vXq4/JYBlZOJSs6TVCSlTYRE=; b=hKgWGfi2Yfgn/P5MZl1QNbdluV19sExnT8/2c3JfVJUemggetl9uuOOEkPFKHiMPQp WGxESdTevQOW9deFbTUHkLYxrUQxJ/LRIr+fYMkvHRrW+6N5+RUoSLm8fJEXEKTIfs38 oFyJ+UI8T96L2RjZmz9nm3lnJFNJSZCerZGa+987pEXZerscA2Bm14RWlEqTZB+ghUjV Evqb637oQxITbf2qO4pZe/B9073gS0a6/Fvhg8O+GgZwvSSmLT/ofy4ku3pdGQgGrQPA muK0HS6f/Jyoe8HEmHthBjQHgfZUe4rdHzkUaY86ksA7CG/SeF3IMgOMFePw13fL6L5m 4FqQ==
Received: by 10.236.184.73 with SMTP id r49mr9062837yhm.2.1332434627412; Thu, 22 Mar 2012 09:43:47 -0700 (PDT)
Received: from [192.168.1.213] (190-20-46-22.baf.movistar.cl. [190.20.46.22]) by mx.google.com with ESMTPS id p49sm14263285yhj.6.2012.03.22.09.43.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 09:43:45 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_05F8B7F5-7239-43BF-93EE-DD32A89A866A"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: 
Date: Thu, 22 Mar 2012 13:43:36 -0300
Message-Id: <86F50263-382B-4504-937A-8D66F3A18EE6@ve7jtb.com>
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net> <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>	<4F6A3F22.6060809@aol.com> <8708c9bdf1e08a7b7ea3cb158add7e2a@lodderstedt-online.de> <4F6B28F0.7010607@aol.com> <4E1F6AAD24975D4BA5B16804296739436642CABB@TK5EX14MBXC284.redmond.corp.microsoft.com> 
To: Phil Hunt 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQkcMhxHYtYhVgf/Nv6EecduKrO8u/gnFcgsW6PcKiwA5Slc4ha7Nt/1p9T7KhLbjyinM/Ga
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 16:43:49 -0000

--Apple-Mail=_05F8B7F5-7239-43BF-93EE-DD32A89A866A
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_21CDC648-FB48-4C33-BCED-C19AA04358F0"


--Apple-Mail=_21CDC648-FB48-4C33-BCED-C19AA04358F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

It is a OIDF spec at the moment.  We don't have any plan to submit it =
currently. =20

If there is a WG desire for that to happen the OIDF board would have to =
discuss making a submission.

All in all I don't know that it is worth the IPR Lawyer time, as Thomas =
has a quite similar ID Submission.

Anything is possible however.  =20

John B.
On 2012-03-22, at 1:24 PM, Phil Hunt wrote:

> Would the plan be for the Connect Registration spec to be submitted to =
IETF so they can become WG drafts?
>=20
> The spec seems like a good starting point.
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
>=20
>=20
> On 2012-03-22, at 8:34 AM, Mike Jones wrote:
>=20
>> FYI, the OpenID Connect dynamic client registration spec is at =
http://openid.net/specs/openid-connect-registration-1_0.html.  You can =
find points to all the Connect specs at http://openid.net/connect/.
>> =20
>>                                                             -- Mike
>> =20
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of George Fletcher
>> Sent: Thursday, March 22, 2012 6:28 AM
>> To: Torsten Lodderstedt
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>> =20
>> Hi Torsten,
>>=20
>> I guess I worry that trying to solve all the use cases that get =
pulled in with dynamic client registration will take a long time. I've =
been involved with both the UMA work and the OpenID Connect work =
regarding dynamic client registration and some reasonable constraints =
and expectations need to be set in order to reach consensus.
>>=20
>> And what John said... since he beat my response:)
>>=20
>> Thanks,
>> George
>>=20
>> On 3/22/12 4:40 AM, Torsten Lodderstedt wrote:
>> Hi George,
>>=20
>> I see two distinct areas of interoperability, which are Client-AS and =
AS-RS. Dynamic client registration belongs to Client-AS whereas JWT & =
AS-RS communication belong to the later area.
>>=20
>> OAuth 2.0 currently (not fully) covers Client-AS and does not address =
AS-RS. In my opinion, the WG should decide whether we first complete =
Client-AS and address AS-RS later on or vice versa.
>>=20
>> I'm in favour of completing Client-AS first and consider client =
registration a major missing piece. Why? Because otherwise clients =
cannot dynamically bind to any OAuth-AS at runtime but have to =
pre-register (with any?) :-(.
>>=20
>> regards,
>> Torsten.
>>=20
>> =20
>>=20
>> Am 21.03.2012 21:50, schrieb George Fletcher:
>>=20
>> +1 to JWT and AS-RS communication over dynamic registration
>>=20
>> On 3/21/12 3:52 PM, John Bradley wrote:
>> I don't think dynamic registration completely removes the need for a =
public client, that can't keep secrets.
>> =20
>> While we did do dynamic client registration for Connect that is a =
more constrained use case.
>> I would put JWT and AS-RS communication as higher priorities than =
dynamic registration.
>> Partially because they are more self contained issues.
>> =20
>> John B.
>> On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
>> =20
>> In my opinion, dynamic client registration would allow us to drop =
public client thus simplifying the core spec.
>> =20
>> regards,
>> Torsten.
>> =20
>> Am 15.03.2012 16:00, schrieb Eran Hammer:
>> I believe most do, except for the dynamic client registration. I =
don't have strong objections to it, but it is the least important and =
least defined / deployed proposal on the list. The AS->RS work is =
probably simpler and more useful at this point.
>> =20
>> EH
>> =20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>> Of Tschofenig, Hannes (NSN - FI/Espoo)
>> Sent: Thursday, March 15, 2012 4:47 AM
>> To: ext Blaine Cook; Hannes Tschofenig
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>> =20
>> Hi Blaine,
>> =20
>> These are indeed good requirements you stated below.
>> =20
>> When you look at the list of topics do you think that the proposed =
items
>> indeed fulfill them?
>> =20
>> Ciao
>> Hannes
>> =20
>> =20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>> Of ext Blaine Cook
>> Sent: Thursday, March 15, 2012 1:31 PM
>> To: Hannes Tschofenig
>> Cc: oauth@ietf.org WG
>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>> =20
>> On 14 March 2012 20:21, Hannes Tschofenig
>> =20
>> wrote:
>> So, here is a proposal:
>> =20
>> [Editor's Note: New work for the group. 5 items maximum! ]
>> =20
>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration
>> as a Proposed Standard
>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
>> consideration as a Proposed Standard
>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
>> OAuth 2.0' to the IESG for consideration
>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to
>> the IESG for consideration as a Proposed Standard
>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration
>> as an Informational RFC
>> =20
>> This looks great to me.
>> =20
>> I have serious concerns about feature-creep, and think that the OAuth
>> WG should strongly limit its purview to these issues. In general, I
>> think it prudent for this working group in particular to consider
>> standardisation of work only under the following criteria:
>> =20
>> 1. Proposals must have a direct relationship to the mechanism of =
OAuth
>> (and not, specifically, bound to an application-level protocol).
>> 2. Proposals must have significant adoption in both enterprise and
>> startup environments.
>> 3. Any proposal must be driven based on a consideration of the
>> different approaches, as adopted in the wild, and strive to be a
>> better synthesis of those approaches, not a means to an end.
>> =20
>> These are the constraints with which I started the OAuth project, and
>> they're more relevant than ever. I'd hate to see OAuth fail in the =
end
>> because of a WS-*-like death by standards-pile-on.
>> =20
>> b.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> =20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> =20
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_21CDC648-FB48-4C33-BCED-C19AA04358F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

It is =
a OIDF spec at the moment.  We don't have any plan to submit it =
currently.  

If there is a WG desire for that to =
happen the OIDF board would have to discuss making a =
submission.

All in all I don't know that it is =
worth the IPR Lawyer time, as Thomas has a quite similar ID =
Submission.

Anything is possible however. =
  

John B.
On =
2012-03-22, at 1:24 PM, Phil Hunt wrote:

Would the plan be for the =
Connect Registration spec to be submitted to IETF so they can become WG =
drafts?

The spec seems like a good starting =
point.

Phil


On 2012-03-22, at 8:34 AM, Mike Jones wrote:

FYI, the OpenID Connect =
dynamic client registration spec is at   
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or=
g] On Behalf =
Of George =
Fletcher
Sent: Thursday, March 22, 2012 =
6:28 AM
To: Torsten =
Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG =
Re-Chartering
 
Hi Torsten,

I guess I worry that =
trying to solve all the use cases that get pulled in with dynamic client =
registration will take a long time. I've been involved with both the UMA =
work and the OpenID Connect work regarding dynamic client registration =
and some reasonable constraints and expectations need to be set in order =
to reach consensus.

And what John said... since he beat my =
response:)

Thanks,
George

On 3/22/12 4:40 AM, Torsten =
Lodderstedt wrote:
Hi George,
I see two distinct areas of interoperability, =
which are Client-AS and AS-RS. Dynamic client registration belongs to =
Client-AS whereas JWT & AS-RS communication belong to the later =
area.
regards,
Torsten.
+1 to JWT and AS-RS communication over dynamic =
registration

On 3/21/12 3:52 PM, John Bradley =
wrote:
I don't think dynamic registration =
completely removes the need for a public client, that can't keep =
secrets.
 
While we did do dynamic client registration for Connect =
that is a more constrained use case.
I would put JWT and AS-RS communication as higher =
priorities than dynamic registration.
Partially because they are more self contained =
issues.
 
John B.
On 2012-03-21, at 4:35 =
PM, Torsten Lodderstedt wrote:
In my opinion, dynamic client registration would allow =
us to drop public client thus simplifying the core =
spec.
 
regards,
 
Am 15.03.2012 16:00, schrieb Eran =
Hammer:
I believe most do, except for the dynamic client =
registration. I don't have strong objections to it, but it is the least =
important and least defined / deployed proposal on the list. The =
AS->RS work is probably simpler and more useful at this =
point.
 
EH
-----Original Message-----
From: Of Tschofenig, Hannes (NSN - =
FI/Espoo)
Sent: Thursday, March 15, =
2012 4:47 AM
To: ext Blaine Cook; =
Hannes Tschofenig
Cc: oauth@ietf.org
Subject: =
Re: [OAUTH-WG] OAuth WG Re-Chartering
 
Hi =
Blaine,
 
These are indeed good requirements you stated =
below.
 
When you look at the list of topics do you think that =
the proposed items
indeed fulfill =
them?
 
Ciao
 
 
-----Original =
Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
Of ext Blaine Cook
Sent: Thursday, March 15, 2012 1:31 =
PM
To: Hannes =
Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG =
Re-Chartering
On 14 March 2012 20:21, =
Hannes Tschofenig
wrote:
So, here is a =
proposal:
 
[Editor's Note: New work for the group. 5 items maximum! =
]
 
Aug. 2012    Submit 'Token Revocation' to =
the IESG for consideration
as a Proposed Standard
Nov. 2012    =
Submit 'JSON Web Token (JWT)' to the IESG =
for
consideration as a =
Proposed Standard
Nov. 2012    Submit 'JSON Web Token (JWT) =
Bearer Token Profiles for
OAuth 2.0' to the IESG for =
consideration
Jan. 2013    Submit 'OAuth Dynamic Client =
Registration Protocol' to
the IESG for consideration as a Proposed =
Standard
Sep. 2012    Submit 'OAuth Use Cases' to =
the IESG for consideration
as an Informational RFC
 
This looks great to =
me.
 
I have serious concerns about feature-creep, and think =
that the OAuth
WG should strongly =
limit its purview to these issues. In general, I
think it prudent for this working group in particular to =
consider
standardisation of work only =
under the following criteria:
1. Proposals must have a =
direct relationship to the mechanism of OAuth
(and not, specifically, bound to an application-level =
protocol).
2. Proposals must have =
significant adoption in both enterprise and
startup environments.
3. Any proposal must be driven based on a consideration =
of the
different approaches, as adopted in the =
wild, and strive to be a
better synthesis of =
those approaches, not a means to an end.
 
These are the =
constraints with which I started the OAuth project, =
and
they're more relevant than ever. I'd hate =
to see OAuth fail in the end
because of =
a WS-*-like death by standards-pile-on.
 
OAuth mailing list
OAuth@ietf.org
OAuth mailing list
OAuth@ietf.org
OAuth mailing list
OAuth@ietf.org
OAuth mailing list
OAuth@ietf.org
 
OAuth@ietf.org
 
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

=

--Apple-Mail=_21CDC648-FB48-4C33-BCED-C19AA04358F0--

--Apple-Mail=_05F8B7F5-7239-43BF-93EE-DD32A89A866A
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMy
MjE2NDMzN1owIwYJKoZIhvcNAQkEMRYEFClGCQwusTyR79PapWEoDZY8w7CVMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AAVufkkKMPAnfcruoKBfh+KqTsedThEpIL5vSx4PmibUJ3Z1eV+bhMZmhfPawKoyEkG9n6L4tJcf
QQsmgdS/7RFhGhnjHUzieU/agSBZ9AwgosfTzB7TNUgUiBgm53ovrcD/B5DLrjMpguNf8uqvqywF
h5LTj+kvR2dlDKeCQftDdZz1v46e8y8UoaNIeUEKE8F+/bc2otHJXorlIr4arEX7pHS4PKY/BlOu
MZW8Qs+1zPkiCVafqsfjjpg7YdXJ0jvmOXC+lk6gzlPmIKrVjv5MFl1UeWRhjTAOgPstez2OrkWG
kOut4tKGr75V81CwUTEncdpeQ+TCO6MWiNEK6zkAAAAAAAA=

--Apple-Mail=_05F8B7F5-7239-43BF-93EE-DD32A89A866A--

From phil.hunt@oracle.com  Thu Mar 22 10:24:31 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757DD21F85C0 for ; Thu, 22 Mar 2012 10:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.33
X-Spam-Level: 
X-Spam-Status: No, score=-10.33 tagged_above=-999 required=5 tests=[AWL=0.268,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWUDBzTJwhIv for ; Thu, 22 Mar 2012 10:24:29 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC3321F8542 for ; Thu, 22 Mar 2012 10:24:29 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2MHORu0030748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Mar 2012 17:24:28 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2MHOQmG019189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2012 17:24:26 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2MHOPXb029240; Thu, 22 Mar 2012 12:24:25 -0500
Received: from [192.168.1.8] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Mar 2012 10:24:25 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DC3312A4-D464-4053-9C80-FEBE97223698"
From: Phil Hunt 
In-Reply-To: <86F50263-382B-4504-937A-8D66F3A18EE6@ve7jtb.com>
Date: Thu, 22 Mar 2012 10:24:24 -0700
Message-Id: <870F7F56-A29A-48DC-B29B-5FF4766D8D2E@oracle.com>
References:   <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net> <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>	<4F6A3F22.6060809@aol.com> <8708c9bdf1e08a7b7ea3cb158add7e2a@lodderstedt-online.de> <4F6B28F0.7010607@aol.com> <4E1F6AAD24975D4BA5B16804296739436642CABB@TK5EX14MBXC284.redmond.corp.microsoft.com>  <86F50263-382B-4504-937A-8D66F3A18EE6@ve7jtb.com>
To: John Bradley 
X-Mailer: Apple Mail (2.1257)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A02020B.4F6B604C.00F7,ss=1,re=-6.500,fgs=0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 17:24:31 -0000

--Apple-Mail=_DC3312A4-D464-4053-9C80-FEBE97223698
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I've been told recently that they have to be published as I-Ds to be =
considered.  The secretariat even clamped down on referencing external =
blog posts never-mind external specs. :-)  The new SCIM BoF which hopes =
to get a WG formed had to arrange to get the simplecloud.info specs =
submitted as I-Ds requiring the AD had to open a special window to allow =
the specs to be submitted during the closed period (which re-opens Mar =
26).

I think dynamic registration should become part of the IETF (as opposed =
to OIDF) because there is a broad issue with software that is installed =
in many locations running the same service APIs that clients can reach. =
The OpenID Connect scenario demonstrates one possible case of many to =
come - particularly with the same software running in the cloud and =
private infrastructure.=20

SCIM (simplecloud.info) is another example. Not only did they have the =
same IPR issue, but they have the same dynamic registration issue since =
the idea is that application service providers implement a common =
RESTful service API for provisioning.

I suspect that since the OIDF would have to decide this, it might not be =
able to happen in time for the charter. I support this happening after, =
as long as it is fairly soon --> I have to agree with Eran's practical =
assertion that charter items should be supported by an existing I-D as a =
starting point.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-03-22, at 9:43 AM, John Bradley wrote:

> It is a OIDF spec at the moment.  We don't have any plan to submit it =
currently. =20
>=20
> If there is a WG desire for that to happen the OIDF board would have =
to discuss making a submission.
>=20
> All in all I don't know that it is worth the IPR Lawyer time, as =
Thomas has a quite similar ID Submission.
>=20
> Anything is possible however.  =20
>=20
> John B.
> On 2012-03-22, at 1:24 PM, Phil Hunt wrote:
>=20
>> Would the plan be for the Connect Registration spec to be submitted =
to IETF so they can become WG drafts?
>>=20
>> The spec seems like a good starting point.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2012-03-22, at 8:34 AM, Mike Jones wrote:
>>=20
>>> FYI, the OpenID Connect dynamic client registration spec is at =
http://openid.net/specs/openid-connect-registration-1_0.html.  You can =
find points to all the Connect specs at http://openid.net/connect/.
>>> =20
>>>                                                             -- Mike
>>> =20
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of George Fletcher
>>> Sent: Thursday, March 22, 2012 6:28 AM
>>> To: Torsten Lodderstedt
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>> =20
>>> Hi Torsten,
>>>=20
>>> I guess I worry that trying to solve all the use cases that get =
pulled in with dynamic client registration will take a long time. I've =
been involved with both the UMA work and the OpenID Connect work =
regarding dynamic client registration and some reasonable constraints =
and expectations need to be set in order to reach consensus.
>>>=20
>>> And what John said... since he beat my response:)
>>>=20
>>> Thanks,
>>> George
>>>=20
>>> On 3/22/12 4:40 AM, Torsten Lodderstedt wrote:
>>> Hi George,
>>>=20
>>> I see two distinct areas of interoperability, which are Client-AS =
and AS-RS. Dynamic client registration belongs to Client-AS whereas JWT =
& AS-RS communication belong to the later area.
>>>=20
>>> OAuth 2.0 currently (not fully) covers Client-AS and does not =
address AS-RS. In my opinion, the WG should decide whether we first =
complete Client-AS and address AS-RS later on or vice versa.
>>>=20
>>> I'm in favour of completing Client-AS first and consider client =
registration a major missing piece. Why? Because otherwise clients =
cannot dynamically bind to any OAuth-AS at runtime but have to =
pre-register (with any?) :-(.
>>>=20
>>> regards,
>>> Torsten.
>>>=20
>>> =20
>>>=20
>>> Am 21.03.2012 21:50, schrieb George Fletcher:
>>>=20
>>> +1 to JWT and AS-RS communication over dynamic registration
>>>=20
>>> On 3/21/12 3:52 PM, John Bradley wrote:
>>> I don't think dynamic registration completely removes the need for a =
public client, that can't keep secrets.
>>> =20
>>> While we did do dynamic client registration for Connect that is a =
more constrained use case.
>>> I would put JWT and AS-RS communication as higher priorities than =
dynamic registration.
>>> Partially because they are more self contained issues.
>>> =20
>>> John B.
>>> On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
>>> =20
>>> In my opinion, dynamic client registration would allow us to drop =
public client thus simplifying the core spec.
>>> =20
>>> regards,
>>> Torsten.
>>> =20
>>> Am 15.03.2012 16:00, schrieb Eran Hammer:
>>> I believe most do, except for the dynamic client registration. I =
don't have strong objections to it, but it is the least important and =
least defined / deployed proposal on the list. The AS->RS work is =
probably simpler and more useful at this point.
>>> =20
>>> EH
>>> =20
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>> Of Tschofenig, Hannes (NSN - FI/Espoo)
>>> Sent: Thursday, March 15, 2012 4:47 AM
>>> To: ext Blaine Cook; Hannes Tschofenig
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>> =20
>>> Hi Blaine,
>>> =20
>>> These are indeed good requirements you stated below.
>>> =20
>>> When you look at the list of topics do you think that the proposed =
items
>>> indeed fulfill them?
>>> =20
>>> Ciao
>>> Hannes
>>> =20
>>> =20
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>> Of ext Blaine Cook
>>> Sent: Thursday, March 15, 2012 1:31 PM
>>> To: Hannes Tschofenig
>>> Cc: oauth@ietf.org WG
>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>> =20
>>> On 14 March 2012 20:21, Hannes Tschofenig
>>> =20
>>> wrote:
>>> So, here is a proposal:
>>> =20
>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>> =20
>>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration
>>> as a Proposed Standard
>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
>>> consideration as a Proposed Standard
>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
>>> OAuth 2.0' to the IESG for consideration
>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to
>>> the IESG for consideration as a Proposed Standard
>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration
>>> as an Informational RFC
>>> =20
>>> This looks great to me.
>>> =20
>>> I have serious concerns about feature-creep, and think that the =
OAuth
>>> WG should strongly limit its purview to these issues. In general, I
>>> think it prudent for this working group in particular to consider
>>> standardisation of work only under the following criteria:
>>> =20
>>> 1. Proposals must have a direct relationship to the mechanism of =
OAuth
>>> (and not, specifically, bound to an application-level protocol).
>>> 2. Proposals must have significant adoption in both enterprise and
>>> startup environments.
>>> 3. Any proposal must be driven based on a consideration of the
>>> different approaches, as adopted in the wild, and strive to be a
>>> better synthesis of those approaches, not a means to an end.
>>> =20
>>> These are the constraints with which I started the OAuth project, =
and
>>> they're more relevant than ever. I'd hate to see OAuth fail in the =
end
>>> because of a WS-*-like death by standards-pile-on.
>>> =20
>>> b.
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> =20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> =20
>>> =20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--Apple-Mail=_DC3312A4-D464-4053-9C80-FEBE97223698
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



Phil

@independentid
www.independentid.com
phil.hunt@oracle.com








On 2012-03-22, at 9:43 AM, John Bradley wrote:

It is a OIDF spec at the =
moment.  We don't have any plan to submit it currently. =
 

If there is a WG desire for that to happen the =
OIDF board would have to discuss making a =
submission.

All in all I don't know that it is =
worth the IPR Lawyer time, as Thomas has a quite similar ID =
Submission.

Anything is possible however. =
  

John B.
On =
2012-03-22, at 1:24 PM, Phil Hunt wrote:

Would the plan be for the =
Connect Registration spec to be submitted to IETF so they can become WG =
drafts?

The spec seems like a good starting =
point.

Phil


On 2012-03-22, at 8:34 AM, Mike Jones wrote:

FYI, the OpenID Connect =
dynamic client registration spec is at   
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or=
g] On Behalf =
Of George =
Fletcher
Sent: Thursday, March 22, 2012 =
6:28 AM
To: Torsten =
Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG =
Re-Chartering
 
Hi Torsten,

I guess I worry that =
trying to solve all the use cases that get pulled in with dynamic client =
registration will take a long time. I've been involved with both the UMA =
work and the OpenID Connect work regarding dynamic client registration =
and some reasonable constraints and expectations need to be set in order =
to reach consensus.

And what John said... since he beat my =
response:)

Thanks,
George

On 3/22/12 4:40 AM, Torsten =
Lodderstedt wrote:
Hi George,
I see two distinct areas of interoperability, =
which are Client-AS and AS-RS. Dynamic client registration belongs to =
Client-AS whereas JWT & AS-RS communication belong to the later =
area.
regards,
Torsten.
+1 to JWT and AS-RS communication over dynamic =
registration

On 3/21/12 3:52 PM, John Bradley =
wrote:
I don't think dynamic registration =
completely removes the need for a public client, that can't keep =
secrets.
 
While we did do dynamic client registration for Connect =
that is a more constrained use case.
I would put JWT and AS-RS communication as higher =
priorities than dynamic registration.
Partially because they are more self contained =
issues.
 
John B.
On 2012-03-21, at 4:35 =
PM, Torsten Lodderstedt wrote:
In my opinion, dynamic client registration would allow =
us to drop public client thus simplifying the core =
spec.
 
regards,
 
Am 15.03.2012 16:00, schrieb Eran =
Hammer:
I believe most do, except for the dynamic client =
registration. I don't have strong objections to it, but it is the least =
important and least defined / deployed proposal on the list. The =
AS->RS work is probably simpler and more useful at this =
point.
 
EH
-----Original Message-----
From: Of Tschofenig, Hannes (NSN - =
FI/Espoo)
Sent: Thursday, March 15, =
2012 4:47 AM
To: ext Blaine Cook; =
Hannes Tschofenig
Cc: oauth@ietf.org
Subject: =
Re: [OAUTH-WG] OAuth WG Re-Chartering
 
Hi =
Blaine,
 
These are indeed good requirements you stated =
below.
 
When you look at the list of topics do you think that =
the proposed items
indeed fulfill =
them?
 
Ciao
 
 
-----Original =
Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
Of ext Blaine Cook
Sent: Thursday, March 15, 2012 1:31 =
PM
To: Hannes =
Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG =
Re-Chartering
On 14 March 2012 20:21, =
Hannes Tschofenig
wrote:
So, here is a =
proposal:
 
[Editor's Note: New work for the group. 5 items maximum! =
]
 
Aug. 2012    Submit 'Token Revocation' to =
the IESG for consideration
as a Proposed Standard
Nov. 2012    =
Submit 'JSON Web Token (JWT)' to the IESG =
for
consideration as a =
Proposed Standard
Nov. 2012    Submit 'JSON Web Token (JWT) =
Bearer Token Profiles for
OAuth 2.0' to the IESG for =
consideration
Jan. 2013    Submit 'OAuth Dynamic Client =
Registration Protocol' to
the IESG for consideration as a Proposed =
Standard
Sep. 2012    Submit 'OAuth Use Cases' to =
the IESG for consideration
as an Informational RFC
 
This looks great to =
me.
 
I have serious concerns about feature-creep, and think =
that the OAuth
WG should strongly =
limit its purview to these issues. In general, I
think it prudent for this working group in particular to =
consider
standardisation of work only =
under the following criteria:
1. Proposals must have a =
direct relationship to the mechanism of OAuth
(and not, specifically, bound to an application-level =
protocol).
2. Proposals must have =
significant adoption in both enterprise and
startup environments.
3. Any proposal must be driven based on a consideration =
of the
different approaches, as adopted in the =
wild, and strive to be a
better synthesis of =
those approaches, not a means to an end.
 
These are the =
constraints with which I started the OAuth project, =
and
they're more relevant than ever. I'd hate =
to see OAuth fail in the end
because of =
a WS-*-like death by standards-pile-on.
 
OAuth mailing list
OAuth@ietf.org
OAuth mailing list
OAuth@ietf.org
OAuth mailing list
OAuth@ietf.org
OAuth mailing list
OAuth@ietf.org
 
OAuth@ietf.org
 


=

--Apple-Mail=_DC3312A4-D464-4053-9C80-FEBE97223698--

From Michael.Jones@microsoft.com  Thu Mar 22 10:26:51 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD97F21F853D for ; Thu, 22 Mar 2012 10:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h73TOavDAZ6h for ; Thu, 22 Mar 2012 10:26:51 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id B2D1F21F8516 for ; Thu, 22 Mar 2012 10:26:50 -0700 (PDT)
Received: from mail115-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 22 Mar 2012 17:26:41 +0000
Received: from mail115-db3 (localhost [127.0.0.1])	by mail115-db3-R.bigfish.com (Postfix) with ESMTP id 9491F4E04FA; Thu, 22 Mar 2012 17:26:41 +0000 (UTC)
X-SpamScore: -28
X-BigFish: VS-28(zzbb2dI9371I936eKc85fh98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail115-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail115-db3 (localhost.localdomain [127.0.0.1]) by mail115-db3 (MessageSwitch) id 1332437199356419_1507; Thu, 22 Mar 2012 17:26:39 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.248])	by mail115-db3.bigfish.com (Postfix) with ESMTP id 470F2C0055; Thu, 22 Mar 2012 17:26:39 +0000 (UTC)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 22 Mar 2012 17:26:37 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0283.004; Thu, 22 Mar 2012 17:26:32 +0000
From: Mike Jones 
To: John Bradley , Phil Hunt 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: Ac0IUOwQCRIf4APwgUm5DSot8V56SQ==
Content-Class: urn:content-classes:message
Date: Thu, 22 Mar 2012 17:26:31 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436642CE1A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436642CE1ATK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 17:26:51 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436642CE1ATK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree with John that submitting the OpenID Connect dynamic client registr=
ation spec to the IETF would make no sense.  It is intentionally specific t=
o the requirements of the Connect use case.

I sent the link to it only so people could compare them, if interested.

-- Mike
________________________________
From: John Bradley
Sent: 3/22/2012 9:43 AM
To: Phil Hunt
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

It is a OIDF spec at the moment.  We don't have any plan to submit it curre=
ntly.

If there is a WG desire for that to happen the OIDF board would have to dis=
cuss making a submission.

All in all I don't know that it is worth the IPR Lawyer time, as Thomas has=
 a quite similar ID Submission.

Anything is possible however.

John B.
On 2012-03-22, at 1:24 PM, Phil Hunt wrote:

Would the plan be for the Connect Registration spec to be submitted to IETF=
 so they can become WG drafts?

The spec seems like a good starting point.

Phil

@independentid

[The entire original message is not included.]

--_000_4E1F6AAD24975D4BA5B16804296739436642CE1ATK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









I agree wi=
th John that submitting the OpenID Connect dynamic client registration spec=
 to the IETF would make no sense.  It is intentionally specific to the=
 requirements of the Connect use case.



I sent the link to it only so people could compare them, if interested.



-- Mike







From:
Joh=
n Bradley

Sent:
3/2=
2/2012 9:43 AM

To:
Phi=
l Hunt

Cc:
Mik=
e Jones; oauth@ietf.org

Subject:
Re:=
 [OAUTH-WG] OAuth WG Re-Chartering



It is a OIDF spec at the moment.  We don't have any plan to submit it =
currently.  






If there is a WG desire for that to happen the OIDF board would have t=
o discuss making a submission.







All in all I don't know that it is worth the IPR Lawyer time, as Thoma=
s has a quite similar ID Submission.







Anything is possible however.   







John B.




On 2012-03-22, at 1:24 PM, Phil Hunt wrote:








Would the plan be for the Connect Registration spec to be submitted to=
 IETF so they can become WG drafts?







The spec seems like a good starting point.







Phil























@independentid




























[The entire original message is not included.]




--_000_4E1F6AAD24975D4BA5B16804296739436642CE1ATK5EX14MBXC284r_--

From jricher@mitre.org  Thu Mar 22 10:35:42 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32CE21F85CF for ; Thu, 22 Mar 2012 10:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.517
X-Spam-Level: 
X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.081,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcNeGlTI5tjq for ; Thu, 22 Mar 2012 10:35:42 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DE43421F852A for ; Thu, 22 Mar 2012 10:35:41 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3AD3521B0E23 for ; Thu, 22 Mar 2012 13:35:41 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0A2A421B0E3B for ; Thu, 22 Mar 2012 13:35:41 -0400 (EDT)
Received: from [129.83.50.12] (129.83.31.51) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 22 Mar 2012 13:35:40 -0400
Message-ID: <4F6B62E5.4070500@mitre.org>
Date: Thu, 22 Mar 2012 13:35:33 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: 
References: <4E1F6AAD24975D4BA5B16804296739436642CE1A@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436642CE1A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------020508070906020300010604"
X-Originating-IP: [129.83.31.51]
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 17:35:42 -0000

--------------020508070906020300010604
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

I think it's a matter of politics and semantics: The real question is 
what do we officially build the IETF version off of? The WG can't 
officially start with the OIDF document due to IETF process, which makes 
sense. But there's nothing that says we can't start with Thomas's draft 
and be heavily influenced by the Connect draft, and make a new one as a 
real starting point for conversation.

If the Connect implementation still needs specific things, it can extend 
or profile the IETF version, and remain an OIDF document that 
normatively references the IETF document. This is where I see some real 
value -- the WG can focus on making a solid interoperable registration 
piece that different applications can extend and use as they see fit for 
the particulars of their use cases.

Does this pass muster with everyone?

  -- Justin

On 03/22/2012 01:26 PM, Mike Jones wrote:
> I agree with John that submitting the OpenID Connect dynamic client 
> registration spec to the IETF would make no sense.  It is 
> intentionally specific to the requirements of the Connect use case.
>
> I sent the link to it only so people could compare them, if interested.
>
> -- Mike
> ------------------------------------------------------------------------
> From: John Bradley
> Sent: 3/22/2012 9:43 AM
> To: Phil Hunt
> Cc: Mike Jones; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>
> It is a OIDF spec at the moment.  We don't have any plan to submit it 
> currently.
>
> If there is a WG desire for that to happen the OIDF board would have 
> to discuss making a submission.
>
> All in all I don't know that it is worth the IPR Lawyer time, as 
> Thomas has a quite similar ID Submission.
>
> Anything is possible however.
>
> John B.
> On 2012-03-22, at 1:24 PM, Phil Hunt wrote:
>
>> Would the plan be for the Connect Registration spec to be submitted 
>> to IETF so they can become WG drafts?
>>
>> The spec seems like a good starting point.
>>
>> Phil
>>
>> @independentid
>
> [The entire original message is not included.]
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------020508070906020300010604
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    I think it's a matter of politics and semantics: The real question
    is what do we officially build the IETF version off of? The WG can't
    officially start with the OIDF document due to IETF process, which
    makes sense. But there's nothing that says we can't start with
    Thomas's draft and be heavily influenced by the Connect draft, and
    make a new one as a real starting point for conversation. 

    

    If the Connect implementation still needs specific things, it can
    extend or profile the IETF version, and remain an OIDF document that
    normatively references the IETF document. This is where I see some
    real value -- the WG can focus on making a solid interoperable
    registration piece that different applications can extend and use as
    they see fit for the particulars of their use cases. 

    

    Does this pass muster with everyone?

    

     -- Justin

    

    On 03/22/2012 01:26 PM, Mike Jones wrote:
    

      
      

        
I
          agree with John that submitting the OpenID Connect dynamic
          client registration spec to the IETF would make no sense.  It
          is intentionally specific to the requirements of the Connect
          use case.

          

          I sent the link to it only so people could compare them, if
          interested.

          

          -- Mike

        

      

      

      From:
      John Bradley

      Sent:
      3/22/2012 9:43 AM

      To:
      Phil Hunt

      Cc:
      Mike Jones; oauth@ietf.org

      Subject:
      Re: [OAUTH-WG] OAuth WG Re-Chartering

      

      It is a OIDF spec at the moment.  We don't have any plan to submit
      it currently.  
      


      

      
If there is a WG desire for that to happen the OIDF board
        would have to discuss making a submission.

      


      

      
All in all I don't know that it is worth the IPR Lawyer time,
        as Thomas has a quite similar ID Submission.

      


      

      
Anything is possible however.   

      


      

      
John B.

        

          
On 2012-03-22, at 1:24 PM, Phil Hunt wrote:

          

          

            

              
Would the plan be for the Connect Registration spec
                to be submitted to IETF so they can become WG drafts?

              


              

              
The spec seems like a good starting point.

              


              

              
Phil

              

                

                      

                        
                          

                            
                              

                                

                                  

                                    


                                    

                                    
@independentid

                                  

                                

                              

                            

                        

                    

              

            

          

        

      

      

      
[The entire original message is not included.]

      

      

      

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


    

    

  


--------------020508070906020300010604--

From Michael.Jones@microsoft.com  Thu Mar 22 11:04:49 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD7F21F850D for ; Thu, 22 Mar 2012 11:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.832
X-Spam-Level: 
X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzangzoeLNGT for ; Thu, 22 Mar 2012 11:04:47 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id B0C5221F84FF for ; Thu, 22 Mar 2012 11:04:46 -0700 (PDT)
Received: from mail19-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 22 Mar 2012 18:04:37 +0000
Received: from mail19-am1 (localhost [127.0.0.1])	by mail19-am1-R.bigfish.com (Postfix) with ESMTP id 9A3A280136; Thu, 22 Mar 2012 18:04:37 +0000 (UTC)
X-SpamScore: -28
X-BigFish: VS-28(zzbb2dI9371I936eKc85fh98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail19-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail19-am1 (localhost.localdomain [127.0.0.1]) by mail19-am1 (MessageSwitch) id 133243947652175_31841; Thu, 22 Mar 2012 18:04:36 +0000 (UTC)
Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.241])	by mail19-am1.bigfish.com (Postfix) with ESMTP id 074384C0082; Thu, 22 Mar 2012 18:04:36 +0000 (UTC)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 22 Mar 2012 18:04:34 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0283.004; Thu, 22 Mar 2012 18:04:30 +0000
From: Mike Jones 
To: Justin Richer , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: Ac0IUOwQCRIf4APwgUm5DSot8V56SQAAULKAAAB/3rA=
Date: Thu, 22 Mar 2012 18:04:28 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436642CFEB@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739436642CE1A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F6B62E5.4070500@mitre.org>
In-Reply-To: <4F6B62E5.4070500@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.76]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436642CFEBTK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 18:04:49 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436642CFEBTK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree that a goal of any OAuth dynamic registration work should be that i=
t can be extended to meet the requirements of the OpenID Connect use case. =
 I'm sure that extensions would be required, as the Connect registration sp=
ec intentionally has knowledge built into it that is specific to choices ma=
de in Connect.  For instance, it provides ways to specify requested signatu=
re and encryption algorithms for JWTs used as ID Tokens and for signing and=
/or encrypting UserInfo Endpoint responses; it allows requested Authenticat=
ion Context Class References to be specified, etc.

If a generic OAuth dynamic registration spec can't be extended to meet thes=
e use case needs, that would be a clear failure.  Extensions would be neede=
d because this more specific functionality would likely not be in the more =
generic, presumably token-type-agnostic OAuth spec.

Also, as a timing issue, I expect the OpenID Connect specs to be final befo=
re there's a complete OAuth dynamic registration spec, for what it's worth.

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
Sent: Thursday, March 22, 2012 10:36 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

I think it's a matter of politics and semantics: The real question is what =
do we officially build the IETF version off of? The WG can't officially sta=
rt with the OIDF document due to IETF process, which makes sense. But there=
's nothing that says we can't start with Thomas's draft and be heavily infl=
uenced by the Connect draft, and make a new one as a real starting point fo=
r conversation.

If the Connect implementation still needs specific things, it can extend or=
 profile the IETF version, and remain an OIDF document that normatively ref=
erences the IETF document. This is where I see some real value -- the WG ca=
n focus on making a solid interoperable registration piece that different a=
pplications can extend and use as they see fit for the particulars of their=
 use cases.

Does this pass muster with everyone?

 -- Justin

On 03/22/2012 01:26 PM, Mike Jones wrote:
I agree with John that submitting the OpenID Connect dynamic client registr=
ation spec to the IETF would make no sense.  It is intentionally specific t=
o the requirements of the Connect use case.

I sent the link to it only so people could compare them, if interested.

-- Mike
________________________________
From: John Bradley
Sent: 3/22/2012 9:43 AM
To: Phil Hunt
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

It is a OIDF spec at the moment.  We don't have any plan to submit it curre=
ntly.

If there is a WG desire for that to happen the OIDF board would have to dis=
cuss making a submission.

All in all I don't know that it is worth the IPR Lawyer time, as Thomas has=
 a quite similar ID Submission.

Anything is possible however.

John B.
On 2012-03-22, at 1:24 PM, Phil Hunt wrote:


Would the plan be for the Connect Registration spec to be submitted to IETF=
 so they can become WG drafts?

The spec seems like a good starting point.

Phil

@independentid

[The entire original message is not included.]




_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


--_000_4E1F6AAD24975D4BA5B16804296739436642CFEBTK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I agree that a goal of an=
y OAuth dynamic registration work should be that it can be extended to meet=
 the requirements of the OpenID Connect use case.  I’m sure
 that extensions would be required, as the Connect registration spec intent=
ionally has knowledge built into it that is specific to choices made in Con=
nect.  For instance, it provides ways to specify requested signature a=
nd encryption algorithms for JWTs used
 as ID Tokens and for signing and/or encrypting UserInfo Endpoint responses=
; it allows requested Authentication Context Class References to be specifi=
ed, etc.


 <=
/p>

If a generic OAuth dynami=
c registration spec can’t be extended to meet these use case needs, t=
hat would be a clear failure.  Extensions would be needed because
 this more specific functionality would likely not be in the more generic, =
presumably token-type-agnostic OAuth spec.


 <=
/p>

Also, as a timing issue, =
I expect the OpenID Connect specs to be final before there’s a comple=
te OAuth dynamic registration spec, for what it’s worth.


 <=
/p>

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


 <=
/p>





From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf=
.org]
On Behalf Of Justin Richer

Sent: Thursday, March 22, 2012 10:36 AM

To: oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering






 


I think it's a matter of politics and semantics: The=
 real question is what do we officially build the IETF version off of? The =
WG can't officially start with the OIDF document due to IETF process, which=
 makes sense. But there's nothing
 that says we can't start with Thomas's draft and be heavily influenced by =
the Connect draft, and make a new one as a real starting point for conversa=
tion.




If the Connect implementation still needs specific things, it can extend or=
 profile the IETF version, and remain an OIDF document that normatively ref=
erences the IETF document. This is where I see some real value -- the WG ca=
n focus on making a solid interoperable
 registration piece that different applications can extend and use as they =
see fit for the particulars of their use cases.




Does this pass muster with everyone?



 -- Justin



On 03/22/2012 01:26 PM, Mike Jones wrote: 






I agree with John that submitting the O=
penID Connect dynamic client registration spec to the IETF would make no se=
nse.  It is intentionally specific to the requirements of
 the Connect use case.



I sent the link to it only so people could compare them, if interested.



-- Mike












From:
John Bradley

Sent: 
3/22/2012 9:43 AM

To: Phil Hunt

Cc: Mike Jones;
oauth@ietf.org

Subject: 
Re: [OAUTH-WG] OAuth WG Re-Chartering



It is a OIDF spec at the moment.  We don't have any plan to submit it =
currently.  





 






If there is a WG desire for that to happen the OIDF =
board would have to discuss making a submission.






 






All in all I don't know that it is worth the IPR Law=
yer time, as Thomas has a quite similar ID Submission.






 






Anything is possible however.   






 






John B.






On 2012-03-22, at 1:24 PM, Phil Hunt wrote:















Would the plan be for the Connect Registration spec =
to be submitted to IETF so they can become WG drafts?






 






The spec seems like a good starting point.






 






Phil




















 






@independentid
























 




[The entire original message is not included.]<=
/o:p>













_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth


 






--_000_4E1F6AAD24975D4BA5B16804296739436642CFEBTK5EX14MBXC284r_--

From phil.hunt@oracle.com  Thu Mar 22 11:15:06 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5459321F8585 for ; Thu, 22 Mar 2012 11:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.34
X-Spam-Level: 
X-Spam-Status: No, score=-10.34 tagged_above=-999 required=5 tests=[AWL=0.258,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNvA-SG6f25Y for ; Thu, 22 Mar 2012 11:15:05 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0979521F8578 for ; Thu, 22 Mar 2012 11:15:04 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2MIF3VX029070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Mar 2012 18:15:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2MIF2D4021144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2012 18:15:02 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2MIF1bN002009; Thu, 22 Mar 2012 13:15:01 -0500
Received: from [192.168.1.8] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Mar 2012 11:15:01 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_84D0DA69-C190-447C-A308-C3BE49285BA4"
From: Phil Hunt 
In-Reply-To: <4F6B62E5.4070500@mitre.org>
Date: Thu, 22 Mar 2012 11:14:59 -0700
Message-Id: <225701EC-557E-4C05-BF7F-E9074B686422@oracle.com>
References: <4E1F6AAD24975D4BA5B16804296739436642CE1A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F6B62E5.4070500@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1257)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4F6B6C28.0065,ss=1,re=-2.300,fgs=0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 18:15:07 -0000

--Apple-Mail=_84D0DA69-C190-447C-A308-C3BE49285BA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Am happy to start with Thomas's draft.=20

Going forwards it seems hard to be 'heavily influenced' by things 'we =
cannot consider'.  :-)

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-03-22, at 10:35 AM, Justin Richer wrote:

> I think it's a matter of politics and semantics: The real question is =
what do we officially build the IETF version off of? The WG can't =
officially start with the OIDF document due to IETF process, which makes =
sense. But there's nothing that says we can't start with Thomas's draft =
and be heavily influenced by the Connect draft, and make a new one as a =
real starting point for conversation.=20
>=20
> If the Connect implementation still needs specific things, it can =
extend or profile the IETF version, and remain an OIDF document that =
normatively references the IETF document. This is where I see some real =
value -- the WG can focus on making a solid interoperable registration =
piece that different applications can extend and use as they see fit for =
the particulars of their use cases.=20
>=20
> Does this pass muster with everyone?
>=20
>  -- Justin
>=20
> On 03/22/2012 01:26 PM, Mike Jones wrote:
>>=20
>> I agree with John that submitting the OpenID Connect dynamic client =
registration spec to the IETF would make no sense.  It is intentionally =
specific to the requirements of the Connect use case.
>>=20
>> I sent the link to it only so people could compare them, if =
interested.
>>=20
>> -- Mike
>> From: John Bradley
>> Sent: 3/22/2012 9:43 AM
>> To: Phil Hunt
>> Cc: Mike Jones; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>=20
>> It is a OIDF spec at the moment.  We don't have any plan to submit it =
currently. =20
>>=20
>> If there is a WG desire for that to happen the OIDF board would have =
to discuss making a submission.
>>=20
>> All in all I don't know that it is worth the IPR Lawyer time, as =
Thomas has a quite similar ID Submission.
>>=20
>> Anything is possible however.  =20
>>=20
>> John B.
>> On 2012-03-22, at 1:24 PM, Phil Hunt wrote:
>>=20
>>> Would the plan be for the Connect Registration spec to be submitted =
to IETF so they can become WG drafts?
>>>=20
>>> The spec seems like a good starting point.
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>=20
>> [The entire original message is not included.]
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_84D0DA69-C190-447C-A308-C3BE49285BA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Phil


On 2012-03-22, at 10:35 AM, Justin Richer wrote:


 =20
    
 =20
  

    I think it's a matter of politics and semantics: The real question
    is what do we officially build the IETF version off of? The WG can't
    officially start with the OIDF document due to IETF process, which
    makes sense. But there's nothing that says we can't start with
    Thomas's draft and be heavily influenced by the Connect draft, and
    make a new one as a real starting point for conversation. 

    

    If the Connect implementation still needs specific things, it can
    extend or profile the IETF version, and remain an OIDF document that
    normatively references the IETF document. This is where I see some
    real value -- the WG can focus on making a solid interoperable
    registration piece that different applications can extend and use as
    they see fit for the particulars of their use cases. 

    

    Does this pass muster with everyone?

    

     -- Justin

    

    On 03/22/2012 01:26 PM, Mike Jones wrote:
    

      
      

        
I
          agree with John that submitting the OpenID Connect dynamic
          client registration spec to the IETF would make no =
sense.  It
          is intentionally specific to the requirements of the Connect
          use case.

          

          I sent the link to it only so people could compare them, if
          interested.

          

          -- Mike

        

      

      

      From:
      John Bradley

      Sent:
      3/22/2012 9:43 AM

      To:
      Phil Hunt

      Cc:
      Mike Jones; oauth@ietf.org

      Subject:
      Re: [OAUTH-WG] OAuth WG Re-Chartering

      

      It is a OIDF spec at the moment.  We don't have any plan to =
submit
      it currently.  
      


      

      
If there is a WG desire for that to happen the OIDF board
        would have to discuss making a submission.

      


      

      
All in all I don't know that it is worth the IPR Lawyer time,
        as Thomas has a quite similar ID Submission.

      


      

      
Anything is possible however.   

      


      

      
John B.

        

          
On 2012-03-22, at 1:24 PM, Phil Hunt wrote:

          

          

            

              
Would the plan be for the Connect Registration spec
                to be submitted to IETF so they can become WG =
drafts?

              


              

              
The spec seems like a good starting point.

              


              

              
Phil

              

                

                      

                        
                          

                            
                              

                                

                                  

                                    


                                    

                                    
@independentid

                                  

                                

                              

                            

                        

                    

              

            

          

        

      

      

      
[The entire original message is not included.]

      

      

      

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


    

    

  


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

=

--Apple-Mail=_84D0DA69-C190-447C-A308-C3BE49285BA4--

From aaron@parecki.com  Sun Mar 25 10:51:04 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD6521F847E for ; Sun, 25 Mar 2012 10:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.755
X-Spam-Level: 
X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=0.221,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC3YlUC2a7UM for ; Sun, 25 Mar 2012 10:51:04 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A82C21F847C for ; Sun, 25 Mar 2012 10:51:04 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so5121056pbb.31 for ; Sun, 25 Mar 2012 10:51:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=AGCcyboPSuGOoLxY3Zb+2OtXd/pIvMfFYu3iQoH3Tp0=; b=kWg76cTyybzL7S4AXBWfRiIEPJLKEqAVVUQgQDmQ0BipQBk3xxPWFl/qv+lLP8jAA9 /lHx3aZbwgnCnoaUzprWdwbp+PuBxOuI2K40JPVMyyvKwZeTrjpt2H1gZf1/EbhQe4mE khbjdTHd6c1IopKPJ3DyUuXl83PyH7FIbF7HKW6sVYkzgbz+yervcOfUPE6nYKwdK5S6 8tRq3mc+HMMNQPSeVy8eIFUpG631Hps9FsEduxj7JP7u7b6NAeqULJlTafOqW4jc0SFm bcwDgaGXURLtsDOZGHh3cGM/AeugXJUYRqmup1BFp+iT45krr2pfBzV4FITrrQZTyJKf Nlaw==
Received: by 10.68.212.35 with SMTP id nh3mr24016014pbc.84.1332697864030; Sun, 25 Mar 2012 10:51:04 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id b4sm10631446pbc.7.2012.03.25.10.51.02 (version=SSLv3 cipher=OTHER); Sun, 25 Mar 2012 10:51:03 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so5121040pbb.31 for ; Sun, 25 Mar 2012 10:51:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.129.74 with SMTP id nu10mr46256322pbb.157.1332697862251; Sun, 25 Mar 2012 10:51:02 -0700 (PDT)
Received: by 10.143.90.17 with HTTP; Sun, 25 Mar 2012 10:51:02 -0700 (PDT)
Date: Sun, 25 Mar 2012 10:51:02 -0700
Message-ID: 
From: Aaron Parecki 
To: OAuth WG 
Content-Type: multipart/alternative; boundary=e89a8f234f31ac253b04bc14e6a6
X-Gm-Message-State: ALoCoQmmn3jb5dBDjoQfvZdgz6O8ySDv7/r3L8RB2ceMBmcpWpcKm4e4dxTVQ2FRq78dufBUFZms
Subject: [OAUTH-WG] Examples of structured tokens in the wild?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 17:51:04 -0000

--e89a8f234f31ac253b04bc14e6a6
Content-Type: text/plain; charset=UTF-8

If you have an example of an API that uses structured access tokens, I
would love some links to documentation or examples. I'm looking for some
examples of the types of information people put into structured tokens for
some OAuth 2 tutorials I'm writing. It would be great if these examples
were available in public services that I could poke at as well.

Thanks!

Aaron Parecki

--e89a8f234f31ac253b04bc14e6a6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If you have an example of an API that uses structured access tokens, I woul=
d love some links to documentation or examples. I'm looking for some ex=
amples of the types of information people put into structured tokens for so=
me OAuth 2 tutorials I'm writing. It would be great if these examples w=
ere available in public services that I could poke at as well.


Thanks!

Aaron Parecki


--e89a8f234f31ac253b04bc14e6a6--

From torsten@lodderstedt.net  Mon Mar 26 09:55:19 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A297621E80B9 for ; Mon, 26 Mar 2012 09:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00BuETFz4yhU for ; Mon, 26 Mar 2012 09:55:19 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by ietfa.amsl.com (Postfix) with ESMTP id CBC9021E80C8 for ; Mon, 26 Mar 2012 09:55:18 -0700 (PDT)
Received: from [80.67.16.116] (helo=webmail.df.eu) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1SCDCN-0000S9-71; Mon, 26 Mar 2012 18:55:15 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 26 Mar 2012 18:55:15 +0200
From: Torsten Lodderstedt 
To: Barry Leiba 
In-Reply-To: 
References: <30401997-7A6A-4306-B909-2EEAE80AA90D@gmx.net> 
Message-ID: <9de93963a7944298df17600eefd6af11@lodderstedt-online.de>
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail/0.6
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 16:55:19 -0000

Hi Barry,

we incorporated all issues we were aware of in the last revision (esp. 
Tim Bray's review comments).

regards,
Torsten.

Am 14.03.2012 22:23, schrieb Barry Leiba:
> Looks good to me.  One note:
>
>> 2. OAuth Threats Document (Torsten)
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/
>
> I have been terribly remiss on this, so here's the thing:
>
> - We have completed WGLC on this, and are awaiting my shepherd review
> (which will include a recommendation for the remaining unresolved
> issue).
>
> - I will do this before I leave chairdom and head into the abyss that
> is the IESG.
>
> - Torsten, please let me know if there's anything outstanding that 
> you
> have to do; else it's all waiting for my action.
>
> Unless I've missed something, this agenda item should be brief 
> indeed.
>
> Barry, two more weeks
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From mike@mtcc.com  Mon Mar 26 09:57:44 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F4721E8110 for ; Mon, 26 Mar 2012 09:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level: 
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrlZt+ktoMkB for ; Mon, 26 Mar 2012 09:57:43 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 6264C21E80E0 for ; Mon, 26 Mar 2012 09:57:43 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q2QGvb6I018885 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 26 Mar 2012 09:57:38 -0700
Message-ID: <4F70A001.503@mtcc.com>
Date: Mon, 26 Mar 2012 09:57:37 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Torsten Lodderstedt 
References: <30401997-7A6A-4306-B909-2EEAE80AA90D@gmx.net>  <9de93963a7944298df17600eefd6af11@lodderstedt-online.de>
In-Reply-To: <9de93963a7944298df17600eefd6af11@lodderstedt-online.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1310; t=1332781058; x=1333645058; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20Agenda=20Proposal |Sender:=20 |To:=20Torsten=20Lodderstedt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=UlS06whmXhcqITp4djqk4imXFZMJvzFgUfrpE30bEvE=; b=ALCfK5nG4O0MtyA+K2iIccFeee7jFASdACE/FRgZJ82hxiFV8UTlUyBbAv jgQTS+bzknw/AK9N+ji15PT1q9EcIT/qukg07Wsc5ypR06wmGuRdVuUpShTb 7afAU/mq/TXv9ksMcTK8B0HUiKnERO9V16aQBrhIH+R5BmNqb34Lo=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: Barry Leiba , oauth@ietf.org
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 16:57:44 -0000

As far as I know, none of my concerns were incorporated.

Mike


On 03/26/2012 09:55 AM, Torsten Lodderstedt wrote:
> Hi Barry,
>
> we incorporated all issues we were aware of in the last revision (esp. Tim Bray's review comments).
>
> regards,
> Torsten.
>
> Am 14.03.2012 22:23, schrieb Barry Leiba:
>> Looks good to me.  One note:
>>
>>> 2. OAuth Threats Document (Torsten)
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/
>>
>> I have been terribly remiss on this, so here's the thing:
>>
>> - We have completed WGLC on this, and are awaiting my shepherd review
>> (which will include a recommendation for the remaining unresolved
>> issue).
>>
>> - I will do this before I leave chairdom and head into the abyss that
>> is the IESG.
>>
>> - Torsten, please let me know if there's anything outstanding that you
>> have to do; else it's all waiting for my action.
>>
>> Unless I've missed something, this agenda item should be brief indeed.
>>
>> Barry, two more weeks
>> _______________________________________________
>> 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 barryleiba@gmail.com  Mon Mar 26 10:00:08 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7344921E80E0 for ; Mon, 26 Mar 2012 10:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.004
X-Spam-Level: 
X-Spam-Status: No, score=-103.004 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EN5I-I5FTUR for ; Mon, 26 Mar 2012 10:00:08 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCA7321E80C8 for ; Mon, 26 Mar 2012 10:00:07 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so6362420obb.31 for ; Mon, 26 Mar 2012 10:00:07 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jtYlRnVQGXfpTE/tWY2ssAJqcj5dq/daU/AytzlAoiM=; b=BREscDdX6CKjwDULW/aWPuU6jsJf2TqKNo40mOZ9znulPv/6k+zpAuhkxZCmOLnQdB zBxFkyoWJ5x8/p2AeNstK1DNx0dAjVBS+QKdVbzusHmngixlXrQ0rwfg13MTtueTjiG+ mMJ/5y9MJkldF3tHRcZc3SaqCH9tzECDhuxMZUv/QajozLGMzZ+uE/PBIbwjwg+i2Cwa +koMD9MFR914rL4IpMpbG59uhnG7tC5QHtKr84A8KM3gD1iUOndLf1U9G4kKcnWBWQmO rAQSwHFfk5D/v5+iCKDNx1VIduX1qKJ96AuuBqAZ/tWS0WhkmsnE69UCjjdXEGRsj89L A58g==
MIME-Version: 1.0
Received: by 10.182.12.6 with SMTP id u6mr28841794obb.12.1332781207460; Mon, 26 Mar 2012 10:00:07 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.60.10.68 with HTTP; Mon, 26 Mar 2012 10:00:07 -0700 (PDT)
In-Reply-To: <4F70A001.503@mtcc.com>
References: <30401997-7A6A-4306-B909-2EEAE80AA90D@gmx.net>  <9de93963a7944298df17600eefd6af11@lodderstedt-online.de> <4F70A001.503@mtcc.com>
Date: Mon, 26 Mar 2012 13:00:07 -0400
X-Google-Sender-Auth: 2erHIEvaI972emTdUF7NcPVHvdE
Message-ID: 
From: Barry Leiba 
To: Michael Thomas 
Content-Type: multipart/alternative; boundary=f46d0444edd36f19c004bc284e31
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 17:00:08 -0000

--f46d0444edd36f19c004bc284e31
Content-Type: text/plain; charset=ISO-8859-1

> As far as I know, none of my concerns were incorporated.

Correct, and I will take care of that (or try to) in my shepherd review.

Barry

--f46d0444edd36f19c004bc284e31
Content-Type: text/html; charset=ISO-8859-1

> As far as I know, none of my concerns were incorporated.

Correct, and I will take care of that (or try to) in my shepherd review.

Barry

--f46d0444edd36f19c004bc284e31--

From werners@bloudraak.com  Mon Mar 26 23:41:48 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE0F21F8771 for ; Mon, 26 Mar 2012 23:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4AP4iNZDhyY for ; Mon, 26 Mar 2012 23:41:47 -0700 (PDT)
Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4569C21F8772 for ; Mon, 26 Mar 2012 23:41:46 -0700 (PDT)
Received: from bloudraak.com ([66.209.67.179]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKT3FhKhP3l5QIgUJcWvyXMHyHxDPDLACZ@postini.com; Mon, 26 Mar 2012 23:41:47 PDT
Received: from [172.16.1.102] (c-98-207-173-190.hsd1.ca.comcast.net [98.207.173.190]) by bloudraak.com (Postfix) with ESMTPSA id 324E0251498; Mon, 26 Mar 2012 23:41:46 -0700 (PDT)
From: Werner Strydom 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Mar 2012 23:41:38 -0700
To: oauth@ietf.org
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [OAUTH-WG] HTTP responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Mar 2012 06:41:48 -0000

Sections 4.1.4, 4.3.3, 5.1 and 5.2 requires that entity bodies in HTTP =
responses be in "application/json".  Is my understanding correct? If so, =
this is awkward for services that rely solely on XML formats for =
communication.=20

Can the standard explicitly accommodate implementors that want to return =
other (agreed upon) formats based on the HTTP Accept header? For =
example, is a consumer requests a token from an Authorization Server =
with an accept Accept header of "text/xml" then the response will be =
formatted as XML. The schema describing that document can be =
standardized, if needed. If it is "application/json" the response will =
be formatted accordingly. In the case of unsupported formats, the =
authorization server should return HTTP status code 406 to be consistent =
with the way HTTP works.

Thanks,
Werner




From hannes.tschofenig@nsn.com  Tue Mar 27 05:08:06 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFC621E814E for ; Tue, 27 Mar 2012 05:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.747
X-Spam-Level: 
X-Spam-Status: No, score=-105.747 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1YPeEuY5UIZ for ; Tue, 27 Mar 2012 05:08:04 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8AD21E8188 for ; Tue, 27 Mar 2012 05:08:02 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2RC81GE002949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Mar 2012 14:08:02 +0200
Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2RC80R4011390 for ; Tue, 27 Mar 2012 14:08:01 +0200
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 27 Mar 2012 14:07:39 +0200
Received: from 10.144.248.121 ([10.144.248.121]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Mar 2012 12:07:39 +0000
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 27 Mar 2012 15:06:49 +0200
From: Hannes Tschofenig 
To: 
Message-ID: 
Thread-Topic: OMA IETF MIF API Workshop - Room info
Thread-Index: Ac0MEhZ/eyKYBMsjtk66B1SapHAJAQ==
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3415705661_18058355"
X-OriginalArrivalTime: 27 Mar 2012 12:07:39.0404 (UTC) FILETIME=[348A5CC0:01CD0C12]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 5366
X-purgate-ID: 151667::1332850082-00003570-A934A744/0-0/0-0
Subject: [OAUTH-WG] FW: OMA IETF MIF API Workshop - Room info
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Mar 2012 12:08:06 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3415705661_18058355
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

FYI: I mentioned to some of you that there is another OAuth related event
during this week.=20

------ Forwarded Message
From: Hui Deng 
Date: Mon, 26 Mar 2012 19:28:50 +0200
To: MIF Mailing List , Internet Area , IET=
F
Discussion 
Cc: , ,
, Ralph Droms 
Subject: OMA IETF MIF API Workshop - Room info

OMA IETF MIF API Workshop
=A0
Time: Tuesday: 18:10-20:00
Location: room 212/213
=A0
1) Program
1.1) OMA OpenCMAPI activity (Thierry Berisot, OMA)
1.2) IETF MIF API Design (Ted Lemon, IETF)
1.3) IETF API related consideration (TBD)
1.4) OMA API Program (Liliana Dinale, OMA)
1.5) Vendor's today implementation (Maybe)
1.6) Next step between IETF and OMA (Thierry, Margaret, and Hui)
=A0
2) Purpose
2.1) From IETF, this workshop would help to explain the API related topic,
and clarify what is recommended and not recommended to do and standardized,
if possible, either publish a information document or adding word into the
current MIF api draft about how to use those MIF API for Internet developer=
.
and some current practices information how today smart terminal is doing.
=A0
2.2) From OMA perspective, to socialize OMA=B9s published specifications and
current ongoing standards activities in the area of APIs. To make sure that
the standards landscape for APIs is coordinated and harmonized. To solicit
feedback about OMA=B9s specification for Authorization4APIs, which is built
on IETF OAuth as well as OpenCMAPI.
=A0
3) Outcomes:
3.1) Future work about how to use those MIF API in an IETF information
=A0document or inside current MIF API documentfor Internet developers.

3.2) Outcomes OMA: Improved understanding of each others=B9 activities,
=A0and a coordinated approach going forward

3.3) Better mutual understanding of the work of both organizations,
=A0and how to cooperate in the future.


------ End of Forwarded Message


--B_3415705661_18058355
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable



FW: OMA IETF MIF API Workshop - Room info


FYI: I mentioned to some of you that there is another OAuth related event =
during this week. 



------ Forwarded Message

From: Hui Deng <denghui02@gmail.com=
>

Date: Mon, 26 Mar 2012 19:28:50 +0200

To: MIF Mailing List <mif@ietf.org>=
, Internet Area <int-area@ietf.org>, I=
ETF Discussion <ietf@ietf.org>

Cc: <thierry.berisot@telekom=
.de>, <jerry.shih@att.com>, &l=
t;liliana.dinale@ericsson.com>,=
 Ralph Droms <rdroms@cisco.com>

Subject: OMA IETF MIF API Workshop - Room info



OMA IETF MIF API Workshop

=A0

Time: Tuesday: 18:10-20:00

Location: room 212/213

=A0

1) Program

1.1) OMA OpenCMAPI activity (Thierry Berisot, OMA) 

1.2) IETF MIF API Design (Ted Lemon, IETF)

1.3) IETF API related consideration (TBD) 

1.4) OMA API Program (Liliana Dinale, OMA) 

1.5) Vendor's today implementation (Maybe)

1.6) Next step between IETF and OMA (Thierry, Margaret, and Hui)

=A0

2) Purpose

2.1) From IETF, this workshop would help to explain the API related topic,<=
BR>
and clarify what is recommended and not recommended to do and standardized,=
 

if possible, either publish a information document or adding word into the =


current MIF api draft about how to use those MIF API for Internet developer=
.

and some current practices information how today smart terminal is doing. <=
BR>
=A0

2.2) From OMA perspective, to socialize OMA’s published specification=
s and 

current ongoing standards activities in the area of APIs. To make sure that=
 

the standards landscape for APIs is coordinated and harmonized. To solicit =


feedback about OMA’s specification for Authorization4APIs, which is b=
uilt 

on IETF OAuth as well as OpenCMAPI.

=A0

3) Outcomes:

3.1) Future work about how to use those MIF API in an IETF information 

=A0document or inside current MIF API documentfor Internet developers.



3.2) Outcomes OMA: Improved understanding of each others’ activities,=


=A0and a coordinated approach going forward



3.3) Better mutual understanding of the work of both organizations, 

=A0and how to cooperate in the future.





------ End of Forwarded Message






--B_3415705661_18058355--


From jricher@mitre.org  Tue Mar 27 07:20:48 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03B821F8867 for ; Tue, 27 Mar 2012 07:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pspJSn-vgExx for ; Tue, 27 Mar 2012 07:20:48 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A9A3A21F8855 for ; Tue, 27 Mar 2012 07:20:47 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D07DF21B1688; Tue, 27 Mar 2012 10:20:44 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 954E221B1693; Tue, 27 Mar 2012 10:20:42 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.233]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Tue, 27 Mar 2012 10:20:40 -0400
From: "Richer, Justin P." 
To: Werner Strydom 
Thread-Topic: [OAUTH-WG] HTTP responses
Thread-Index: AQHNC+TGE3mkOC9xg0SuzLMbSCyQm5Z+dNcA
Date: Tue, 27 Mar 2012 14:20:40 +0000
Message-ID: <4008FD89-8DCA-414E-A92D-97EB377BEAA5@mitre.org>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [129.83.50.150]
Content-Type: multipart/mixed; boundary="_004_4008FD898DCA414EA92D97EB377BEAA5mitreorg_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [OAUTH-WG] HTTP responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Mar 2012 14:20:49 -0000

--_004_4008FD898DCA414EA92D97EB377BEAA5mitreorg_
Content-Type: multipart/alternative;
	boundary="_000_4008FD898DCA414EA92D97EB377BEAA5mitreorg_"

--_000_4008FD898DCA414EA92D97EB377BEAA5mitreorg_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Werner,

I have an extension draft to address this exact problem:

  http://tools.ietf.org/html/draft-richer-oauth-xml-00

I'm updating it to track the latest spec's section numbers (now that things=
 have settled) and will upload it as soon as the IETF allows. For your bene=
fit (and the WG in case anyone is interested) I'm attaching the PDF version=
 of the draft-in-progress here.


I welcome any comments, suggestions, and questions.

 -- Justin


On Mar 27, 2012, at 2:41 AM, Werner Strydom wrote:

> Sections 4.1.4, 4.3.3, 5.1 and 5.2 requires that entity bodies in HTTP re=
sponses be in "application/json".  Is my understanding correct? If so, this=
 is awkward for services that rely solely on XML formats for communication.
>
> Can the standard explicitly accommodate implementors that want to return =
other (agreed upon) formats based on the HTTP Accept header? For example, i=
s a consumer requests a token from an Authorization Server with an accept A=
ccept header of "text/xml" then the response will be formatted as XML. The =
schema describing that document can be standardized, if needed. If it is "a=
pplication/json" the response will be formatted accordingly. In the case of=
 unsupported formats, the authorization server should return HTTP status co=
de 406 to be consistent with the way HTTP works.
>
> Thanks,
> Werner
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--_000_4008FD898DCA414EA92D97EB377BEAA5mitreorg_
Content-Type: text/html; charset="us-ascii"
Content-ID: <54A3C58B8EAD3B4E9A270D02FC90EBE5@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable









Werner,



I have an extension draft to address this exact problem:



  htt=
p://tools.ietf.org/html/draft-richer-oauth-xml-00



I'm updating it to track the latest spec's section numbers (now that things=
 have settled) and will upload it as soon as the IETF allows. For your bene=
fit (and the WG in case anyone is interested) I'm attaching the PDF version=
 of the draft-in-progress here.










I welcome any comments, suggestions, and questions.



 -- Justin





On Mar 27, 2012, at 2:41 AM, Werner Strydom wrote:



> Sections 4.1.4, 4.3.3, 5.1 and 5.2 requires that entity bodies in HTTP=
 responses be in "application/json".  Is my understanding co=
rrect? If so, this is awkward for services that rely solely on XML formats =
for communication.


> 

> Can the standard explicitly accommodate implementors that want to retu=
rn other (agreed upon) formats based on the HTTP Accept header? For example=
, is a consumer requests a token from an Authorization Server with an accep=
t Accept header of "text/xml" then
 the response will be formatted as XML. The schema describing that document=
 can be standardized, if needed. If it is "application/json" the =
response will be formatted accordingly. In the case of unsupported formats,=
 the authorization server should return HTTP
 status code 406 to be consistent with the way HTTP works.

> 

> Thanks,

> Werner

> 

> 

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

> https://www.ie=
tf.org/mailman/listinfo/oauth










--_000_4008FD898DCA414EA92D97EB377BEAA5mitreorg_--

--_004_4008FD898DCA414EA92D97EB377BEAA5mitreorg_
Content-Type: application/pdf;
	name="draft-richer-oauth-xml-01.html-1-v1.pdf"
Content-Description: draft-richer-oauth-xml-01.html-1-v1.pdf
Content-Disposition: attachment;
	filename="draft-richer-oauth-xml-01.html-1-v1.pdf"; size=197327;
	creation-date="Tue, 27 Mar 2012 14:20:39 GMT";
	modification-date="Tue, 27 Mar 2012 14:20:39 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

JVBERi0xLjMKJcTl8uXrp/Og0MTGCjUgMCBvYmoKPDwgL0xlbmd0aCA2IDAgUiAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1nV+PJLeVZ9/7U+TzAi4nyYisKsCYhzEGBvbNGAHzvKsd
zcCwFvDq+wN7f9HdylDxhNyRJ3sEo0s9rdOXQfLy/uPlPy5/vfzj0t9eRr+8tfFye7v8fFlv68v7
r//+96//Pm4vy225tsvfv/wHH3/j0xfC3y//ffmP/3H5v5dr/bO+r5e3pV/+339e/qN+649/+aVd
/uuXyx//XL/++Mvl+rL8+r9ffrws7y/X9XZ5fbu+3OrXdusvb61+7S/97e1TMX669PqX23LwR/LX
/PQr5fb68pHx+Q98ZcAf+PyXfJVjXV7WZfkgx28Zx3/k01fK0l6Wt7ffpfzOH6lPcR3vvd0+/fpT
fbIvv3fJR3vL17m091bD/fnr6Nv79eWtprXmb1lf2luN4je/8772T5//k7//lpDp+6n+hvex/R/+
dJ+qQK+35VP9vV/EeHt/6e+3L39v/S2X9pvf+SpJ/Uf1Z758oi+U+o3//pS/++vo6CcY8ce/+TO1
hrfJ9tu/5vM3+Srs9s2+YcSf6m/9+B1rp3z9sr8Z4Tzm7Xe+/FVf/ptNuM+yfP7ct2275K/p/eW9
9V9XeG8v67Vmr37ZttFPl7b9U3/0H/WpXmvPZqP94fOP+7386cefL//6w6Xl/11/oH691WIe75cf
fq6NGMoPP13+dL1e279cfvjb5d9+2LTBaeQrIbtBrijlMMhbJykXhXwnpPmW/U6sbfOM2Rm3X2Xc
Ec3klC7/uoJ2RDM3y0pEMzW1UUDGVUz2+kbEmyDeGhFfDRG/45sh4qjfBfH1rix2q8fMzNug72hm
5g33jJmZ9yvJ+L/Ed3zHUf9vQ0Td86MgtuvTF2S74or8P0bKsi9BWZgF1Bp+S7PKW8dv+Z9m4AM1
0E8C2fFwaFeFJI3R1Cm74nY0irKvtB+bOWf7DaU0SqPfUEpzdvcbLfVmDu/+iktdfcs3XOpmj/dy
qGa10cwe72+01K9qXeLJ09TA30nKZo7HccV1qfb4e4UtPvs5dzujmU9ZrvRMvJoTd7wR0ezGpRHR
7JzllYhm/ZTyffJ3LBwQzajLWQSimZnbCsRmLOly+2cZmzkeSu/OxKuZ61eU0eyZ0rqzjM1YqaV0
Z+LVzHWsoBnZjJHaF9Rn6phdcbrNtunl084DdwdYRQlnZDN2b38dhDRnQ38lFeRmvPxaGLianjIG
AGk2eC9jYEaqGR9XlNK4JeOKUhpbbTSaHqUsRzmi8C3VwDtpoqsaeCed7gZejug88GaOiTFwxo1W
Hwuty6s5cMeCi0hNDx4UykytoHRpzC1l8DxTeiYqGcuUBqKZ7jKlgWjUb5nSQDSrvIIOM1F5YivN
9dWMugzfJ8v4ijNjju/XSidPK7ybqFUZvjNRGZUVwZiJSkeW4TsTlYxlXwDR2GqVR56JamZamReA
NLGGVuGLGamMoHalgau4TSuLZZaym73dGi5zY7G0TntRaaA2aMaVxdIGfUtlC7TK1ML0mCOsVWJ1
RrpvuZIaUkd3W5+uh1qFzueBK2XZbjg9ygGvMMEsZTfWX19wQ5o93qsWA6RUTiNOj9qQyWzMUl7N
0ZPMxoxUiyiZjRnpBo6WRjfR+F6RB5DSGFi9UuozsitkVSgC0kRU+zvtHpXSGVUuOUupTINRtWAz
Un3LUZVhgFSubQUzAGm8nVHBDEC6RXQpm/Wja2t0W53iM1EZWeWIzsSrsbHKEQWime3K6QDRfMdy
bYFoDrJybWeiciXqzAGi8STKyJiJSlvUITYTu8mXVKh7Jiqj8q0T0azwqoYGGY0t/Y670KzHipzP
MnYjY5xGQJpt2KoOeUaq2Y7TCEglZcfZMSdD/NBZym7Or/ihM1KZF/FDZ6RSGPFDZ6QyL1o5OoA0
B04rRweQanrK0QGkWURJBM/I/fTU/YatNv+ba/n75z//h/q1vKhWsdDNehmiWnyHfH1H5Gk1t0OW
5U9SntZzO2TdKCLkaV98h2xXHvlpZ3zPrCpQkvO0ptszB4/9tL+3Z1bKiOQ0U9SqXp6Yao5eK/0E
C/70Dt2P/WDFn3Yj98wKWpOcZt7rwhoyT+vQnZy9fiY5TyvRPbM0HjFPG5x75sFaOl1Ps2dWWork
VHNUKRping5C7eUsK5GYZs0ngEDM0wb3Ts6UQxDTrKVRiWdiGp08qmSXmOp7LriPzle9779neYIk
52nncs98wzV/vpR+x8x1YJLTnB1LRaOAeb6Yfi9n/QzMvSn2bXcp98wyvoHZ1NgrNgNMJ2cZtsA8
X6O/H/srztH5RNCeyabieQdpx1wr2wtjvxo7ZG34Pc+H8fdylm9Ichq9tFYNFDDPJ5H3cladFjDd
9+S1dL6OZS9nrrvPtuL5CwA75u1gLZkz7pbmBrOcai3d6qYCMNX3vPEZp+b9xg6sknPUudnLvvno
FBv7c1R8kpjKDqnsFTGNH7dU+I+Yxq5b2opMdcZVaA3kPH8ZYrc3lzqLgXm+0nXPrOpMYhq/Y6lM
CTGNH1dNWYjp7KU3ltOcm8s7yqnmKI0x4HuqtbSWLwNMZdus5csQ0+z3ldensufXypKRnGa/r3VT
CZhqfa51vhPTxG3WulNPTLM3b3XzgJjKZihbEZjnkzI7XXcrWxGYah/FZiCmOYtjMxBzp5OvL726
4nz+3zeH1euY+9wip467krp21kcL4rTnvUPm487IBy4x3aXMtwXkaX2yk7LcREA+UBB8lzLaZJby
vMbfSVmBO0KagVdRCSFP7/udlBUKJOROjX7uyfTtC3R8WaB1Y6RMx6pY3xZoeTmPdwnaIWueAHk6
71Mn5+dtNC63WvOA3H2Bbwu47JDlJxLytE2yR7KUp037HTJTDwM/HVneI3l6zq/5+/RUXJmkPB1v
2EnZYovByE+fyXtm5T2IeX5v3oeeVirEPH0m7+WM/wFjP33W7ZlV+UXM3Vl3egu1nBsgp1nwLT4N
MM2KT/6QmGqOEhsAOY3+aDk7gKn2UXwvYJ7OI+3XUsX+iWnUcasqK2Kejjfs5azcKTHNvMdeJKaZ
9954b5p91Mt+ADnP55F237N3Xp9Kzs5nh9HJvS7XwtjP+9z7sVeNEDGN/kyfJ2IaSyldE4hpjvdc
XiCm0cm9evcRU62lA2tJjf0Nx34+LrJfS4kNgE5WYz+wwcz6HFe2l8zZke4JMHallwbruquxl8aB
rjN6fiTWMs/7+djVbi1VV2Vknr9vfLdpx3ewFceBrWhshlG1ZvA93bzXBUJgns/D7+coYYZ53h+I
XOzmiHXy+Tz8Xs6qiQM5z+fM90zWyefzxntm1c+TnEbPp/YEmGqOlmpZSkyjQ5YDH9bo+aXhmn/g
wuN9fS51v4rGbvz3hfXn+XqW3VpaEk6Fvam+Z9UtElON/cAvNmfxUk27SE7jHy11j4mYxlZcqqaB
mMZeWur2LDHV9zzwtdX3PPCLlQ6pmncY+/l6lt0+WqttBTCvRievB36xsevWqqMnOc33XJPlAR1i
5n0dz48zrAd2ndlH9QAFjV35R+uBXWf25pqEFMyRWp/V2ZOYJnaxHuglNUd1L4HkNGfcljOH72li
F2vqmIBp9lHq7IhpvueNY4DKpr1VHSjIeT5nvtPJtwMf1tght2qvB3JezVq61S1BYqq1VEupQjcf
8poPdLS9m7SpFpiRykNIsRUgz5cH3KWMrQRIo+eiPmbkA81L7lJWdTYgVYQ2BWGzlCoY0BIAA6ZR
HrlXDcwHug7fv2aL8gA5jaHU4sAB0xjyubQMTGV4turWCExleG6JTRi7CVa1GDXAVHOUYBUwjTKu
V/KQqdZ8kqUgp/qeCYABU33PJCWAqb5nCr6BaRRyPUWHTDVHrD8faDt910tbsnQe+wO1ajtmgv3A
NInifqDrzPfMhViS0wTme5zCeezqjEtbAWIaPd8TrAI51feMAzczlaPZUxgyM9XZ0Q90nXFe+4FR
ZxzNPDlDY1dzlGAVfE/jwOX1T2IaPZ9Ly8Q0hTYjwSoYu9HzI8EqYJq9OVJwAUwzR6MaSRBTyVml
vsQ063PUhVhimr05UkH77O954GqaIOVIDe0sp7K9R4JVM1Ppz1ENI4mp9nsShiCn+p7V35GYZh9t
l+6eLOdSASGQc9+r7usFh/z67TXk98L8snTSTvHDJYcHwmF3ZGXlAHn+huiuij4Pw4KU5+3Gu5Rl
khDyfPjmjsyjerOUD4TXdkj+lucV6R1Zhaok5fn9dEdWnQAgHwgy3ZHl0QBSLaJEhIh5/qS7i9nK
ciDmee94z+Q9ed4a2THrqi3Jed5q2jPrCdZ5ve+10zeWpe+YB8pDjZ21x/mr9TuF1Fh9PFB2sRs7
648HvKQds8qCYI4eOOV3zEqVE/O8JbZn1uuh81ra73d1T2pUue6HfMIDb93fIxl1n42QJutRNh4h
jU1SJh4hz58e94FXPgGQD6j6O7LyCYC0+QRA9vOH+13KVkVmwFQppO1d7HllPtAleidn5RNIzvMa
dMesnUnM8zt+z+T1fv403jHLlyU5z9s2O2bF2IhpNlFyFMB8oOfvTs56kAOYKl6bfAIwu/qeOZHm
Na8KVVsM0JmpNHwuNQHTzVFdHiCmWkt1eQCYSi911nVq7L1ypyCnWp+9il+BqdZnrxgbMNX67FUk
AUy1PnOrnJhmLfWKsQHzfCOmXSFLrzwnMY2e7we2kjnfU8QCcro1z9bSAy/73PV8HmUBOd1+z3vz
s/50Y6+CMGKaec+LsMBU9Rfjynre2EujOtuDnEovjXpulZjnPfj7WhpVEEZMNUfVWBWYbo5YL3VT
DDdYL6k1Pw7sJaOT08gOvqfa76MaaADTjZ2dTXVujspzkpwmdzoSWZx1nSrWXKqAnpjn49P3vZnm
t89nPl/P57IQyKnOuCVZiXmO1JrPBSRgqjW/sL+p1vyy4PrsZs0viVbO39Ot+UQrganWPOul5pi4
5t1aYn9T2clL5Tnpe5qzeGU/Tvkd64G9dD7jcdd1abQIY1c6ZGXfUM37Ws8LkZxq7KzrlA5ZWS8p
HZLLQjD2BzLFu3mvS4zAVHbyWhe2gal0yMoxK2V/rlVbCnKq82g98OOM/VklMqP6dn5InjgxSyPP
SLXiYyTPSLXg63k7QKr1nkwHSGnCqVVhB0i12vOKOTDVas+b48BU2rhFw8+fU53CLdE/YJpTuCWn
PTPVKdxiJc5MtS1zy4GYRnu0shCB6eY9nvuzxx7PHZhq3mPNzkwVCWn1yjMwH3iO8H4Kt5waIKca
e7ISwDQZwx7L89nMqtIlpqlY3DIIIKeJKHbWIUonb9F+kFONPRbdzHRyxqIDprG6O+9N5XFsGYRZ
TqXr+sF+V2NPBmGW02XiElUDporQHtghZn3mgXOQU52baWFGTHNu5vYAMNVaSls0YLr2bckgzPOu
bjXlaTZimvMotweIqeYoFRfz2N1aqmeVgKm8ji2DAHKam5Ej2dKZqWzakajazHzgxeG7bbNlEGam
+54Hus6c70vdaoKxuwgt+1zKN1z68/XnUm24YexK1y31zAoxzbm51HNaxDTn0VLtbolp9NKWQZjX
/AP3EO77aGHf8PxTI7vKkIX9uAfemdjJWbev6HuaEMuSahP4nmqO6lYoMc0Zt6TaBORUeol9Q9e2
j/Xn1diKa+52wNhN1mxlu04VJq9sgyl7aT2wwcz5vqZiDb6nWfMr6zplf67V2pvkNHGG9SBmZSrx
12rtTXKq78l+sdLzK/vFD9wXuevklX1Ydb5v2RNYnyZTvFZnDpojNe+llsrd/pA9UUdcIiyANFZI
UvmANAqk5oaQ5lsmIQNSmq0ej2NGqnvVdQUYkA9cDLtvoJyXs5TqHNruQgLTTHmr9vBPlzNnMMhp
7KSWMxiYRhdveaOZqc62liz+zNzfifvG+5X3pdRymwWYauy5zQJMNUepWAKm0R/bbRZgGt+gVScr
ktNU5bbvoOi2GzIwduMPt1RnAtOcwS1V48A0895TNQ5Msz63XBQwzT7q1R6e5DRzlKeEiGmshTwl
REw19uQLn/w9R6rfZmY3BsPILSZgmrU0cmMTmGYfjVSqAdPsozyBAkzVl3VUB0hgDtNpLc+VPJ3J
59EwN4622wLzHA1ziTydgmDs+54MT+gYs7Tbx44xD9ytvt/+r2ADIB/wku7IapdOyPOxsB3yHZHn
1fMdWasKpFQdH8qXI6QZeMUqAflADPA+8LosQsjz6umOLGuEkOe16A7JM37euLsj6wYwSWkWUTWz
AuQDL1PdpYwrB8wHQks7ZrXKAeYD5Xp75vNnKO4hyPlAU4adnAca7rzrsWNWCSDI+UArjh2zUjLA
3IcaVBuWpdLwH2Nh5gitNiyENCdoHaCEPL9B7053xVQJeX7yd0iW0pjgFQsDKVX2PSoZZtw4H+Uf
EtLErcr1IOT5s+g+PWnsQkzjerQqXSKm+ZqtLioTU429LrQQ00xRqxQXMIfZlS06eV6dqlQxjV2A
qaK/rcqMgOlCi6w4HzA8d2s+luf8PR+wGfZMXp9Gz7W6zENyqrUUexbGblR8qwtCxFRjrxsoxFRy
xqSFsZt0fhrQEPO8MX9fS/3KxoIpEUjzeZLTrKVe5VDENPqzV+jm+UyW05wdaWpDcprwWmf9qdLP
vZKwJKea92poT0xzvqehPTGNDknpPDDV2ZHSeWCqkqDO+vMBv3inQ95w3iWT513N0YGZfD5ysRv7
O+vP85GlOzMvitO8mzWfcnxgqvWZcnxgqrKYNPMnpvERRpWoEtOccaMufgNT2Z+5+AxMVQY3qsSK
mGbNpxyImOaMG5XeJabZ76Na8gLzgZjVbm9WJQswH4jK75gHesnYNuPAfzdBoLz+TWM3c7Qc2J9m
7EulDklONfYDm9as+TTfITnV96wHlYCpireWKo8BpvLfwyOmOTfz+jcwh/HjlroCDUy135cqUSWm
kvM7+O95UZzkVHNUqV1iGtsmTYKIqb5n8kfgv5u9mXJ8YprvuXL8U9l164H+VGPnmOpQTLYV1bX/
lPjDHHVzHq3JST17LVWJPzCHiQmsdc2SmGp91oPAwFRxhpXtT2V7rwf2p9FLeVGcxq7m6MBWVPuo
2uWAnGpv3thWVHszL4qDnGpv3g7sOvM9b5zrUXvzxnadKrW6sV23L4s6XUpdjbFiNnxIZ6t8aay6
Gam84iRlAGmUfHQSII1/EJUESBMKSTobkEbLxSEGpBl4fFdAmunJ1Q5gulxp4nSznC5XWu27gKl8
rTx8Dkx1Xubhc2KaupUWHTd/T5crrbYZxDS+wZbPBjnNmdHqgWGQ081Rcicgp1Eg7UB1mu3eUkoJ
cqrvWTxgqthfrnYAU8W7c7WDmGqOWH8+UAN3j1Hm4XOSU+X2WH+qkz1XO0DOpuRM7eOT12faoRHT
+Aa9rsYR0/hvW+4Zxm7yB3lMneRUtREHus7kePJIOclpdF2vdhTENBZYr3YUxDT2Uj/QS+bc7MmV
wloyen5UOzRimjWfh8+BqWJqW/712WNP/hWYZt5HPYlKTJM72fKvIKfZR6PaZpCcai0lTjfLqZzX
tFgDpjrjxoFHrOa9WgSRnGqODnxiY9uMeqiZ5DT6My3WiKnGfuAWqzmqlgckp1rzyXPMa161482j
78BUa37L6YKcxq7LIy0kp2OyDWbW5zJ4zZv1ueQq4Pw993daTsf+0g6NmGa/55EWYqo5yn0eGLua
o+R0Z6byO5YDXWf2+/LKYzdxm4X9YhW7WL6D/bmw/an84vVA15k52nK681rqps47D7/A+lSxizU1
2bOcKla5clzxgWu199jFWm3CSU6jP/PwCzHVvLP+HMbXXll/Kpt2Zf2pbIY8UEPf0+ilPFADTLeP
2H8fJnax5YnnfeTycPVQM4zd5d1ZJz9wV/m+N2+cl1F66ZaamPl7qjzCjeOKyl5KrrS6633IlSox
szMBabz3bMwZqQ732DUzUg28uikS0qjj3JQAKU1kqXCENE7hO06PakGcp45ITHNetsTU4Gsa36BV
wxVimklv1cobmMqOb/VIMTCVndTiE8L3NKuzxScEpjnb8nwSMFU9cjvQciY23VKnBmNXaynxL2Ca
nERa1gFTqeOWWNUs5wPNi+7nektN2cxU9kda1gFTjT0t64hpTsx+oOvM+uypn4XvafZ7T50aMM2a
3+7UAtPlNXnsJgbUD3SdmqPU5MLYzfHecycMmObc7MmVAlN9z9wzA6aJWfRqI0pMcx71xL9ATjVH
B5aisZd6yUhyqr2Z/ME8dlUTs+VfZ6by37b8KzDNmh9sK6rYX56Ogu+p7gaNA51sYtMjdXXz91Q2
7Ujt8MxU53taVBLTnB0j8S+Q05ybaVFJTBOnG99B140DXWfsz1HfksZudN1IDhLmyKz5LQcJTKPn
l+9g1y0Hdp3R81tecx67spO3u6ozU7VdXxKXB6YaO9t1Kt6dp6NITrU+v0PwL09HkZxmb253VWGO
zFm8pFcKMNX3PAgAqrGnLxTIqXRI7qrOTHUPYWFfW91D2PKas5wqZrWy/lR6aU0N3CynqtXLc1TA
VPHp9SAGaPzNNfW+89hd3ij3JWamsuvW9K8CpsrtpYYYmCZusx74xUaHrOk1BXKaMy7PUQFT9Vta
D3IyJiaw3amFsas1n/4BwDQ6eU2uFJhqjpIrBabxO24H8U+1j/plrau6H3OQxpWpLpqENFGbaj9M
SGOEVG3A05EspVEf1VmNpDSWUjWmJKTZQOW/EdLsn9zXBKay49N/GJiqLrXV063ENJ8z/YeJaRZS
q7gSMc0WSv9hYprV2cr+IKYae9XgE1PNUflvwFR2fPKawFR2fPsOqjO9gkFOZce36tVGTHO25b4m
MJUdn1wpMY1Nk1wpMY3+TK6UmMae61UXQkwz9l61WsRUY68+IcBU6zM9jYGp1lLugBJTjf1AJxu/
qB/oZKM/e8XUaOyOiXtT1Zp01snDxNB75Uph7MOccb3K9J7PxO95NfmY5F9BTrc3D6xktZbKd3u6
nAd2spEz+VeQU8XpRtXEAFPNUfKvwFR1/cm/AtPldOv+ATBVnW+e8yOmsb1HxdSAqWJ/uasKTJfP
rjgdMY2uGxWnI6baR9XXBJgqjpxnB4Hp5qh6EgDT1VvUnQZiqvXJtrerOaiYGsipzs1xYHubM26p
Xikgp9LJ6ZMMTKWTl7oTRkzjcy31xCowlZ28HMQujN+RO7Ugp1pLyWcDU51xyT0T00RTF45duPXJ
drJjVp0Njd2cHck9E9PErJbKPRPTnEdL5TmA6dZn9YkBpjqPspRqK33IH6gwbXW3AKSK0uZwn6VU
Sqlq+wlp1mb1eySkOYbrtgAhzWpPAAy+pRl49SsjpNk/W/5gFtPFZ6tfGcjp4rM5g2c5ld5Mv0dg
Klsh/R6JaWyF9HsEptqWW/4AvqexFdLvkeQ0cbr0ewSmm6P4RTB2o0DS75GYZrun3yMx1fes+77E
NHZ8yxn87O9ZtQbAdPMeH2aWU/muW/5gZqq92ZN/BaaZ97xfSEwz7/1AJ5vajbxfSHKaQote71oR
0/gGvfqqEVPFu+sOEzGNDtli6LCWjGWT+0Ykp7FD8oYfMc151A+sOrWPEkOfv6d6Oyc9JIGpdN1I
XnOWU9W+bTH0menintUXCORUuZORvCbIaeZ9pNZkZqqzY7D96WKUbH8qO3lU/SyMXdW6juRK4Xte
/+Xyw98u//bD5a+X033Vtrj8zHRy1vuvIOfV6PlRd+iB6fZ7ak3msQ+j50fi3TPT7fe6A0pM9T2r
twcxzfm+JF8IYzdyLsntAdPopaX6cBDT2GBL1eADU+m65cAGU2OvN6hATnfXKvlCmCNTD7SwX6z2
5nJgK6rvmdg0jF2t+cSRganWZ+LIwDS6bqk7TMQ0Nm3e2yOmqTFKb0ZiGjs5d5iIadZSejMCU51x
K9tgKuK9JmcGa8n4xetBvE59z9RGgJxmb65s27g5yq2GWU7VIyd3g4Cp7LrcDSKm6cOxHugl47+v
B3pJraXUbM1zdDX20pqarZmpagpvB3rJ7M28jUdyGr8jb+MBU8UAb6l5nb+nqq+6Hfhx6nuyvdTV
+qzPWS2CPuRKlQsbywaQZmemkHRGqgVfdwsJaeyF5EpBSrPcU7E0I1X1RgwlQJrpiZ0ESLPWW/Ka
M1Ot9fR7BKY621r1YCWmsblbakjnsatNmX6PxDS6o8XPBDnV2BPrB6axFVrxiGns+JaKEJBTjT15
zZmp4sgt9tzMVGdbS/4AmMZ/a4l/AdOopZbaImAqvZT4FzDVPjrQn2bN9wP9aWojeuy5J489PSSJ
afZRekgS06zPnjtMMHZjL2x3mIBp1nxPvTwwTb1FT0EdMM2a7/WuOzHN3uyJ9YOcai0l1g9MlSM/
0HXGJ8x7eySniVlseU0Yu1mf2z0eYJp44naPB5hmv4/UjAPT2AzjO9hgeccO5FRxpbxjB0zlY496
m4SYRoeM6uMNTDf2A+9VrU92X1WcbhzoJfU92YF18566ENhHJsczDrxipetS7wtyGl23pLZsZqra
9u3OzcxUPuySfiEzUxXMb/nXmanW0naPB5hmzS+pgQOmWZ9bTheY5uxYEk8Ephp76kKAqcZePXiJ
afTnkrrkWU6l55fUJQPT2HUL+9oqTLkc+NrGnl8O7E9jJy9sf7qxH/jaZuxravXmeVd1NmvqV2am
Wp/pSwlMpT/X1MTMcqpY0FpvMxPT6KX0pSSmseeT3yGmWfNr9fUlphr7gZ1sfMM19Ssw7+Y8Wutt
ZmIae2nN/TWQU31PtpOVbbPmXgfIac64Nfc6gKnWfO51AFPNUe51ANPo5NuV95H5nrfcwQA5zdhv
uYMBTDNHWz57Zqo7gQnXVSrhQ05XXQnMrecZqTJSaUQxI9WhmX0JSBPzjqk0I9UxHO8VkEYbJ6cL
SKM4Y3vNSDU9ecMPmKqGtKX2bZZT+cMteQ5gGh3Xqic4MY0+aqlbmeVUtcNb/8yZqWzE7f4rMNX3
TA8KYKrvyYpT1Ty22Ekgp/Ezt/6ZwFRjZ93p9tGB8jRxupb7W/PYlV7a7pXOTKXkt3ulwDRz1BOn
A6bZR1v+FZgmBtSTO5mZbo466k9VG7HdVZ3lVGu+554EMI2fufWlBKaa9+ROgGlMhrwLSExjH+dd
QGKq75k43bPHnhpnYBo9v/WlBKbam+lpDEw1R7mnC0yl69ISHphqfSbHA0wz9pGe8MA0dSHjwKY1
33O7UwtymrN4pCYGmGaOtvuvwDT7fetLCUw17+Wz09jVvKcmBuRU856aGGCasyPvAhJTzXvqsUFO
NUe5IwJMNUe5IzIzlW0z6g1UYCq/YznQS2aO8n4hyKnGvhz42iYasuWJ5zlSdt2WJ56Zw6zP7Z7u
zFRv3y7JScxM1edgObAVjQ5Z6g1UkFP1SV7SwxzGrtZ8aneAaWywJXkOYJp495LaHWCqsbOt6HK6
yUmAnGotHdiKxmZYk5OY5VS9gtfkJGamiqKvB/rT2Axr7tiBnEYnr+y/q9jvyr62qq9aU/s4j32Y
9ZmwYkXoP+RjriYtkZu/gDSWTfIxgDSKLj4xIM06ylMNgDRqLhWKM1JliJPimZHKoEvcE5DG/og7
DEijOrbnzIBpts+W4gGmOS6358yAqcaeayfANFO0pWNmpkoPt6jNmanyw1s70pmpjraWlgkzU7kb
jRWnS5nVcQFyqvRBi4k4j125MNsTaTNTuRuNlacqp9ueSJvlVKH+7Srgs5lp7TAz3RwlFABMo5d6
QgEzU7VE2lqczkzlGmwtTmemWks9LbuAac6jrW0qMNUcpTwRmMau6Xn6AZjGLeopTwSmOYu3tBEw
1dhzjWdmNsVM2mhmqtKIrRXrzHT7KG3/ZqY6j7brhcBUaz4lRsBUKYk8EwZMc5V6u14ITDP2kbJp
YBq9NOJiA9Os+cF6aZieJiMhyllO1dpju144M9VZvF0vnJlNrU/WS0Otz4QoZzndHCUdMzPd2NlW
3Idrri/98vV/v/z4rV1p18u1/vlDdWIpD+xWO2uLtIxLhVx+uvzpeu3nYxh3ZB2igHxA6d+R1aIS
kA/o/DuyupEAsp+PtNyR5dUA8oEdtUO+I/K8g3xH1jolKc/r0Tuyjk9APuB+3JG1kwD5gGW7Q+Ii
eqAz1B3Z6m4UiPmAYt4x6x4TMNX+aWXUE9Ns81b3QIlp1marA5mY5w+Q3fc80Ee7nR5leL18u/oc
X9Rnafxa+aVJPgSquzF0KiUHSJWOrOoDQD6gPu8Dr6gyINUF/QoBA1IFxOqVK0KeX/b3gVdUGZAq
y7VpkXkVXU1uopVZD3Iql6ZVNS0xjbnc6oYQMIepAszLWcB8QNPfp33TTPMcDXPLMC9nkZzqe1Yn
XmAqMzShamAqE7xVNQMxjZvU6s4VMN3YKyMHzAeMut1aqhvqwFT5s8YKuZkwU6sqVZBTpWFzGwGY
3bhzrbrBAVPNUa+bV8Q0KeheVarEPG9639dSLx+OmEYv9eqmScydxXT69ZNeL78Q87y1uBt7dfgg
ptGf6TAHTJVCS4c5YKrkdo//Op9H6mWiHgcWmOp7VpEEMdW81w11Yhp7qVflFjGNJd+rcouY6nuy
/lS2fLrWkZxm7OlaR0yj68aB/Wn00ohnDGvepHzStY6Y5iweVYJATDX26o5OTLM+88oVMY3LNaqb
ETFN58tRt6SIqdZ8pbuIqeadbUXlx+XlLJJTzVFigPM+UmUio24OAPOBIODdZhgHIQE171UWRnKa
9ZlOeMQ0ezOd8ICpbJuF/XdVpbpUQgLkVPZ8OswR09ghS6X6iGnskNxGIKZZn7mNQEy1lurmKjHV
mv8Ooc+FY58qFpSbAzR243MtB9HP85Hvu65bDvSSWUvrgV4yZ9x6YNeZvZnXuGiOzJpPlT8wlf5c
D/xis5ZWjgEqm2E9sBWNrssLX/A9VapjrXJVYhq/Y60bocQ0tvf6imPfp/ZPx1jSZY3kVGuebcWm
1if7xQ/ki++6LqUXMHbJ5HlX37NeIgM5VZbrdhCrNPZ8XjcDOVWeK6+bAVPludINjpjm7MjrZsRU
+73ErFTCh0SxmvYqjCKkOd2rLoqQZuCJ1cHAjZQJ1QHSqPhkOmbkMANPoG5GPlDGcVdyW6IYmMbo
3hLFM9MdRDX00nMfF7vJneRYB6QxPxKZBqTRmvUdCWmWUfJ6IKU5g6qqkJBmFSWqAlKaKGqcF0Cq
woBrHUDANMZMa7zYjeO2lVaBnEZptgQrgGkct5ZgBTDN4bsVGwDTLPiWADIwzVZvCYAA0+z1tD4k
php7nJdnyxnnBZhqH8XRAKYqDKgW+8BcVJFJ3WEDpjvXa9zENLou7RSJafbmVsAAc2TWZ57Ie76c
vJbMcdTjFDx77NUODJhDfc9qxwBMVZLaE0Cex97VWor7MjNVkL8ngDwzh7FsegLIwFRr6TsYdZ2t
OhWc7AdmnbEZ+oFdZ+ZoHOg6s49GkmXzvKsg6jjQdcaLGQmAgJzGVhwJSgNTfc8Uu85MVfQ4Uto/
M1XRY+7FAVMVPY5cE5jlVEWP48AjVnOUArBZTjf2A5/YRGtGAt0gp7E/Rz0nQkxjz48DW9Gcm6Pu
AIOciwmujPqWwHRJ/O+gk7cChnnem/ER8uwejd3oz62AAeQ0/mZaH4Kc6nxf2FZUSZMlicJ57Mqu
W1JUNjOV/blUsRIwVUR+OfDfja2Y1ocgpwpNLwf6U63Pah0LcjodkrD8PO+qAGxJ8hGYao7qiSdi
Gjt5PYhVmvMoT+SRnMZmWHMBYf6e3djzay4gzEwVY1nZ11a6bmWbVunktZ4DpbEbm2Fl/an20XoQ
U1VrPkW587yrpPOaotyZqc6j9cCmVXN0oJONXsoTeU8fO8dUlR+3sp2s/Li15pzGbuzkG9u0yo8r
1/C16t8+5EpVa8G6BglIVVZVC56QJkBdMTBCGh+uzAVCmlRcrSJCGu+gVWkNMY3mzANsxDQaKQ+w
EdNYIK36zRDTWCCtolXAdFfI62ohMFWpUivPiJhqjupRjaczK7MJTHXFrFVkHpjDbM1W1UrEVHuz
ov1PZ1bHHWCqSHIrb4uYJqrWylogptHIrcoyial0yIFONvso171JTrOWenlbz2fi+lTVWrnuTXKa
aEA/0PPqe5a3RXKqea/r3sBU19Y663k3R+XBgZzKpssVcmIaHdIrAgZM5cH1ioABc6i1VGWpwFTR
gF4eHDCVl90P9LwxvPuBmay+Zz0oQmM3Nu2oB0WIac6OXEsnphl7up0CU3WcH/UgKDDVWkoHVWKq
OaqsBDCV/sxVd2AqXTfq8WNgqvZN6XYKTBVZGmx7u3mvR/JITjXvVVVITOPHDdbzKuo76qomyOnW
Z90/eD6Tv6fSS3UDAeRUV19HtVoiprHBlsp0ENOspeVAz5toajLFJKfZR8kUE1ONva66E1PNUVWP
E9NULuWqOzHNms9Vd2Kq73mgk02GKw/vgZwqc5Sr7sBUcYal2o8QU81RtQohppqjahVCTLXf62UR
YKqzYzmIXZixr/VaCclpfIS1WtUB82piQbmST0xTvbNynEH5cXl4j+Q08ZCV7WR1Fq8HsQtzuyGZ
Yhq7OTtWTnEpm3Y9iF2Y/Z5HDGns5nzPNX9iqv1+EGdQY+fYr9J1a2WKnz72g3iyWp9VvUNyGtvm
dmDTGh1yu/L3NPGQbM0yFz9kn1UXyUQAAWlWZxxDQJoDLnsIkOZ8yxYCpElxZWUC0lhfLSsTmEbL
5Q4sMc2uTGNwYKooektUDcZutHHu6gJT1abmri4wlVWTNyyBqaIrLVG1+XsqL6YdqCSj5fKGJcjp
xl7tA4ip1lKshfl7qprklggYMJUOqWZlwFQ1yVumGOQ0J2aLBwdMM/a8DQlM9SbolikGOc1aSmNw
kFNFA/I2JDGNpdRr3MRUc3Sg64wO2bK6MEdKzmqARmNX8x7PCOQ00ao0Biemsen6ga4zRt2WLYWx
G6uuJ7IETGPW9UTRgWnW0oh3AExj143voEPScJvkNHtz1N18Ypp9NOq+ADHN+hzVmBGYyl4a9TgL
MJXNMA70klqfbIOpCMM40Etmvw/WS8r2Homiz3tTMnHNqxe4Btt1Dzxnd+9ZNuq+FYzdZcmT2YTv
aSKfSz2CAEx3f+1AJxu9tKSqcB67suu2zCYwjV23ZTaBaXRI7sDC2NWaXxJFBznVHKUCEJjGBlu+
g05eWCe7NV/3rWjs5txcUkEN39NUKi6prAOm8TeX6sFCTJPhWqoHCzHVPqoeLMQ0a35Ntd78PdXe
XFPFMTNVJdiaKg5gGpthTRUHMM363LKQwFRzxHFFZSum2TiN3eyjNZUh89hVFfGaypCZqW70rNXD
ipgm7r3m9h7IafyjNZUhwFRriXWy8mXWA/1pfNj1QH+aszgh6jriP2bN1HavlQRIo+VzPQqQZiGl
ah6QZr3nGiggzbdMfREgjUZKyTwgjVETHwaQ5lvmWAekGXhaThPThP7ScpqYZpu3HOswdrPaWy5G
AdOozZZQ1cxU6YMttTczVYFNi1sETLM8t3QhMI2buaULganmKAXzwDQ6absAC0yj4FuOdWCqNZ90
4cx0l38TVpqZLv16oD6NRs47wiSnWfM95RYwdrM++4H+VHJWDwqS0+j5nnKLZ4895RbAVGNPAwFg
Gr3U4xYB05zFPW4RMM1+72kgAEy1Pg/sY2NybxdLQU61PlNXBkyjQ7ZLoMA04YWeyjJguhQk6nml
k8eBrjN23UhpGYzd7PeR0rKZqUrLtgubM9OlOVjXqVbeI5foQU6zj0a1LCOm2e9585eYxl7Km7/E
NLpuJFwzf083R0lBzkwV9sybv8Q0OmSwDaZsxS0N9+Sxb5cBgWn00pYyA6ZZn1vKDJhKzqTMgGn0
51Jtt4lp7JAlpaQgp9mby4Fto+aIfcOh5ihlDDB2NUcHto3xYbc03CynCvluKbOZqS5GpcXr079n
GlyAnGYtbSkzYJpzc61nC0hOs4/yPi8wVenOyjaYS0XVUwggpzo38z4vMc25mbd0ianmKBf3YC0Z
HbJd3AOm8YvXXA8CpvGLt4t7wDTnUVq8kpxqjlIGBnKq/X6Q7DD2fNqxkpzGL14PchPGL047VpLT
7M1bLinDHBk9f8slZWAam+F24Mep/V7qs1ykj2lN9TlrhgBpZj15Z0CazZ6GLoA03zIJQ0Aa9ZFE
NiCN5owDB0izMLeEITCN8mipo5yZqn62pcPBzFQdDlqUBzCNgt865gLTKKQW5QFMszpbAt4zsylm
jJqZ6RKbCSwB02i5FgduZqpASEsQCJjG+GoxQGam+54p4JiZyjloqQOamU7OJCGBqfbRgf40+72n
4ALkNPtoS0LOTPfOZJzCman2e48DNzNVM/yeANjMVIH5nvuFM1O9Q7XdL5yZas333A0CpjmLe7ph
AdPso7zbSUxjh+TdTmIaO7GnOOLZYz/QS2q/JwAGchqDticABkwz71uH15mpgqlbh9eZqe7HDNZ1
SodsSchZThVMHUkYzkx1n2N8B/25dXgFOc25uXV4BaZanylkAKbRIXm3k5hGJ4/cuQE5TbB/uwcJ
TONubvcggWnux4wEwICp5j0BMGCq9ZnOf8A0en5JLwpgmjlaElQDpjmLl++gP5ckEGY5lf25JFA3
M1VRzHLga5v9vnVOBTnN+b4c2IpqLeXODchpgtNL7twAU63PXJUAptqbbH8uxn9f2NdWhUtbAhbG
bvTndmcRmOp7HtifZi1tCdhZThW7WA/0pxn7ltSd5VQ27ZoXw4Bp1ufK/rvSn1sCFuRU3/NAJ5u3
Abc7iyCnscHWA51s0ifryvNubNr1wH8351He7aT1qeY9Sd15jlTcZmWd7NY8Z4/c/VfWn8rfvOXO
N3xPp0Mur5Xi+5CEVO0UU3IwI1WpSQwGQJrDKHnNGal66iWvOSNVSDGl6IA02iPOFiCN4Zm1Dkgz
PS1rHZjG7mwp1gKm+ZrbRUhgGr3Z0rNrZird0eo+OjCv6nsmLj/LqdoZb5cWgam+ZwpTZ6b7nilM
nZlKy22XFoFpfIPt0iIw1fcsHozd5V+TgwQ5jT3X0ksQmEovpcfpzFTnRj/QdUYlbznIWU61N3su
BwHTrM+txykwTexv63EKTLPmt7zmzFQXybcLhjNTGQw9hf3ANL5BT1wJmMbu7IkrAdPszX5gJhr/
rZeMJKf6numFBWNX6zNx+Znp1mdef5iZ6tzcerHOTHVubhchn87ENa/GvuUgQU5jg205SGCa9TlS
hD8zVW+xkUtMM9PldHNBe2a6OTrQdcZHGAe2otnv48DLNufm9iLk/D1VbGV7ERKY6nseeMUmxzMO
3GJjf453DlsYu24krwnf0+R0lyvbycauWxLvBjnN+lwS7wam2UdbDhKYZo6WvGgGTKPnt0ugwFRj
Z/2p8hxbXhPkNLbikhg6MNX6zEVyYKrvmRj6zHQ58rycNDOVj7D1YgWmqcleDmxFo5OXNAia5VT3
ELbXG2em+p5bDnJmyrwmjt3J+R3895VjlSrOsB7EKs3e3F6EnOdI1WRvOciZqfb7mvsSM1PVZG+X
QGemsr3XvEg+M2VuD+15t+ZzB2OWU1143/qmAtOcR1vfVGAam2G7BApMY3tvLy0C04z9xnppX2dz
femXr//75cfLP+pfXqvlwrX++cPnH/vbS5XOvrXxcnv79OPPl3/94VLPqWx/oH6tSrO3r1dCx6Vd
fvjp8qfrtZ3/EnfkWAn5wO33O7IkJCnP+yB3ZJXUAvKBNsw7JH7LB6qe78hSJiTleeNhh3xD5Pl1
ekdW6QFJed71uiMrakdIM/BKegCyn3do7lLWZXJAPhAXuCNb+ZzEPO8f7pi10Ylphp5cLDGN5kgu
lphq7BVfI6YaezUaA2bbxej75X9e+uVvlz/+5Zd++a9fLn/88y/t8ud//3R9uW2699///M909aV0
dcXt317Xl/Xy86X6Zn3+8e+Xf7/8tdT87VN0eOn8+itG/op/ovvDi+6/P4mz0Zcqcfn0x7+0X3X/
CetnRpZR8fa6fNqqZnbI3QRG6E3sbxL3007c7QtE3Brxjm2K5erOU4n7XGTmaUbulsY/GfjXM/o+
T1VFQsjzuvCObFWxT0yTEUo7bWIa77lVtIyY50+r3dirnTYxjUWZl3KJabINLVoGltJ5q2c39vKi
iKnmvaL4xDx//O/krCg+MdW8VyU8MXf76Ku2/oYtGuX5fv1VNW8//qqav+q4b1TN85YPvfpsfNB1
KoET1Twj9/GIb1XNs7hRzcC2qvnZSJbyvMVyX6cViKOBq2UaNQoj3y3Tb1ievz3p84g5MdW2jxqd
5VTBvRZPdWaqoESrYD4x1dirIQgxzYLPCwLAVEHdNAQhppKzHl8h5nmD+r6NWtw9mHe1jyrwTkw1
73H4QE5z1KXIDZgPhGDu37NXUyFgqqZCvV42IaYae5xI+J5m3nslGYlp9Gcdx+/VVPzDcXw126iu
gDwd+Xwpq3L/n0h5wmSq2yTv18/ebCu/7vPPz7OZNvw0ScpmqppWGv7OnT19FJfFQEiTwonjRcyd
mI+bdp9navqsau2nPxkJbPZTHkkCpso5xRwB5gPxvbtqjjlCTOUllzkCzLZbAKfXaWrugenmveoA
gLmPm52Xs3rhENNY9Y1VyVXNUZkjz5YzPbqIaea9V8SFmGZvdt6bzhypY/7pclbvQGCqeY/p0CZP
Xm2jmA7PRj5fypgOvy/lSdOhf462bAfS9vNzTYdZVm06zMh9uOW0qovpMCOVlJvpMDP3YkrTAeBG
lWymw7OZUU8z013bqoAwMFU5/2Y6zHJKJi8qNUd1FRvG3pTnXUUNwFRHSNqQElONvUKhwGzOdEBV
6iJtB8rEmE15DxDGrq7S9rgK85pXY+/19ikw98f8iaMpB/z4NUf7+cfnnUwbffK+mgmQZNVX45GP
wYyd0fi4ys/qB7bZUZWjfToSpWwmAVi3D0hKE3RKt3FiqvxfVYIQ06yn1nmGzOdMZ3CS0wQb0xmc
mGqO4nnPC151SMmWr8tWH/en2UPxGJ6NfL6U8Rh+X8oTajku/LrzGLafn6eXg59lVXo5wcYZuTfF
H/IYAKmDjcB8yvGx+XYAN2t/8xiezYzHMDObKveIxwBMpe6rcRcxjRqNeqqy1Gerp2cjny9l1NPv
S3lSPd12uZDt5+eqp1lWrZ5mpFZPM9IHNGbmXszHrdtNPQFcq6dnM6OeZqbPhcxMnwsBpnKWY5HN
TJ8LmZkqiNuSC5mZyglpdScSmK58Jv7XLKcLOtV7JcQ0XkjKKIhpvJDemGmOzx4PDL6n8UJ6PLCZ
ufdCThxNOeDffq1s/Pzj806m0CtK8MF82F9pOm3lJqAxI5+j8hPQALbR+NlQz0ailEqXJKAxS6la
neRqCzBVpVPLdprldOo+qUVgqvj1QKZqQ9TqWhzJaRZnqhCB+cAtqXvJQ7Z8Obcftrw6PRPQeDby
+VLGY/h9KU+o5UQc3ncew/bz8/Tyhp8mSenlBDRg+LtIwWlVn6wFIHVAA5g7MaXHAHC1RZMSeTYz
HsPM7CYdtFVPzUyXsksMd2a6IyQew8x0VnPdiSGmsUY3j2GW0409HsPM3KfCTu/RvJpITDX2VE+B
nGofvfMcmUL2npzNLKcqJeh1eQOYqhtRr3v/xDQmTjqBArMb5ZxOoMBUtkNeIySm6cTUqxMTMZVH
W5c3gNl3B9Ppvdnr8gYwXTr9YL/vPNoTZk4Zi9Xi/Ff388vPz7NzNn71O/9gjXZzQbcc0HpuemI+
zQNFuFF95YI+n/nOTPNh6+YzyanUabseQM3+zz3l50taYR2CKu3XyrlFqDP1DqBG/7XqTo+S7hTL
aQXYqr0yQZWD2w6UytUECtOgniRV5VStwhoEVQdAq2deCeqsyLKiCKrM3X6w95VP0kvzk6Rq9ntd
kEKo2VF51xqhZkf1Uc044PTb76ivXU++vUPVPXqUar1RjW0/HthOZmSqBFnMSpDzgfZPu7GXG0lM
c/bnkWtgqqxrr3gcME+0kpl7CvRSVU9nlqYC5r6J4F//P2MSwG0KZW5kc3RyZWFtCmVuZG9iago2
IDAgb2JqCjE0OTUxCmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNCAwIFIg
L1Jlc291cmNlcyA3IDAgUiAvQ29udGVudHMgNSAwIFIgL01lZGlhQm94IFswIDAgNTk1IDg0Ml0K
L0Fubm90cyAxMyAwIFIgPj4KZW5kb2JqCjcgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0
IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA4IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczIKMjYgMCBS
IC9HczMgMjcgMCBSIC9HczEgMjggMCBSID4+IC9Gb250IDw8IC9HMSA5IDAgUiAvRzQgMTIgMCBS
IC9HMyAxMSAwIFIKL0cyIDEwIDAgUiA+PiA+PgplbmRvYmoKMTMgMCBvYmoKWyAxNCAwIFIgMTUg
MCBSIDE2IDAgUiAxNyAwIFIgMTggMCBSIDE5IDAgUiAyMCAwIFIgMjEgMCBSIDIyIDAgUiAyMyAw
IFIgMjQgMCBSCjI1IDAgUiBdCmVuZG9iagoyNiAwIG9iago8PCAvVHlwZSAvRXh0R1N0YXRlIC9T
QSB0cnVlID4+CmVuZG9iagoyNyAwIG9iago8PCAvVHlwZSAvRXh0R1N0YXRlIC9TQSBmYWxzZSA+
PgplbmRvYmoKMjggMCBvYmoKPDwgL1R5cGUgL0V4dEdTdGF0ZSAvU00gMC4wMiA+PgplbmRvYmoK
MjkgMCBvYmoKPDwgL0xlbmd0aCAzMCAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0Zp
bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VFPZFofPvTe90BIiICX0GnoJINI7SBUE
UYlJgFAChoQmdkQFRhQRKVZkVMABR4ciY0UUC4OCYtcJ8hBQxsFRREXl3YxrCe+tNfPemv3HWd/Z
57fX2Wfvfde6AFD8ggTCdFgBgDShWBTu68FcEhPLxPcCGBABDlgBwOFmZgRH+EQC1Py9PZmZqEjG
s/buLoBku9ssv1Amc9b/f5EiN0MkBgAKRdU2PH4mF+UClFOzxRky/wTK9JUpMoYxMhahCaKsIuPE
r2z2p+Yru8mYlybkoRpZzhm8NJ6Mu1DemiXho4wEoVyYJeBno3wHZb1USZoA5fco09P4nEwAMBSZ
X8znJqFsiTJFFBnuifICAAiUxDm8cg6L+TlongB4pmfkigSJSWKmEdeYaeXoyGb68bNT+WIxK5TD
TeGIeEzP9LQMjjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z3x5+U/09yHr7VfEm7M+eQYyeWd9s
7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA8gUAtN6c8x6GbF6SxOIMJwuL7OxscwGfay4r6Df7
n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aanpktEzMwMDpfPZP33EP/jwDlpzcnDLJyfwBfxhehV
UeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+nWsUaHVfAH2FOVC4SQfIbz0AQyMDJG4/egJ961sQ
MQrIvrxorZGvc48yev7n+h8LXIpu4UxBIlPm9gyPZHIloiwZo9+EbMECEpAHdKAKNIEuMAIsYA0c
gDNwA94gAISASBADlgMuSAJpQASyQT7YAApBMdgBdoNqcADUgXrQBE6CNnAGXARXwA1wCwyAR0AK
hsFLMAHegWkIgvAQFaJBqpAWpA+ZQtYQG1oIeUNBUDgUA8VDiZAQkkD50CaoGCqDqqFDUD30I3Qa
ughdg/qgB9AgNAb9AX2EEZgC02EN2AC2gNmwOxwIR8LL4ER4FZwHF8Db4Uq4Fj4Ot8IX4RvwACyF
X8KTCEDICAPRRlgIG/FEQpBYJAERIWuRIqQCqUWakA6kG7mNSJFx5AMGh6FhmBgWxhnjh1mM4WJW
YdZiSjDVmGOYVkwX5jZmEDOB+YKlYtWxplgnrD92CTYRm40txFZgj2BbsJexA9hh7DscDsfAGeIc
cH64GFwybjWuBLcP14y7gOvDDeEm8Xi8Kt4U74IPwXPwYnwhvgp/HH8e348fxr8nkAlaBGuCDyGW
ICRsJFQQGgjnCP2EEcI0UYGoT3QihhB5xFxiKbGO2EG8SRwmTpMUSYYkF1IkKZm0gVRJaiJdJj0m
vSGTyTpkR3IYWUBeT64knyBfJQ+SP1CUKCYUT0ocRULZTjlKuUB5QHlDpVINqG7UWKqYup1aT71E
fUp9L0eTM5fzl+PJrZOrkWuV65d7JU+U15d3l18unydfIX9K/qb8uAJRwUDBU4GjsFahRuG0wj2F
SUWaopViiGKaYolig+I1xVElvJKBkrcST6lA6bDSJaUhGkLTpXnSuLRNtDraZdowHUc3pPvTk+nF
9B/ovfQJZSVlW+Uo5RzlGuWzylIGwjBg+DNSGaWMk4y7jI/zNOa5z+PP2zavaV7/vCmV+SpuKnyV
IpVmlQGVj6pMVW/VFNWdqm2qT9QwaiZqYWrZavvVLquNz6fPd57PnV80/+T8h+qwuol6uPpq9cPq
PeqTGpoavhoZGlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa57VeMJWZ7sxUZiWzizmhra7tpy3R
PqTdqz2tY6izWGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R76E+UZ+tn6S/R79bf8rA0CDaYItB
m8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2cYrxPuNbJrCJnUmSSY3JTVPY1N5UYLrPtM8Ma+Zo
JjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9i1iLnRbdFl8s7SxTLessH1kpWQVYbbTqsPrD2sSa
a11jfceGauNjs86m3ea1rakt33a/7X07ml2w3Ra7TrvP9g72Ivsm+zEHPYd4h70O99h0dii7hH3V
Eevo4bjO8YzjByd7J7HTSaffnVnOKc4NzqMLDBfwF9QtGHLRceG4HHKRLmQujF94cKHUVduV41rr
+sxN143ndsRtxN3YPdn9uPsrD0sPkUeLx5Snk+cazwteiJevV5FXr7eS92Lvau+nPjo+iT6NPhO+
dr6rfS/4Yf0C/Xb63fPX8Of61/tPBDgErAnoCqQERgRWBz4LMgkSBXUEw8EBwbuCHy/SXyRc1BYC
QvxDdoU8CTUMXRX6cxguLDSsJux5uFV4fnh3BC1iRURDxLtIj8jSyEeLjRZLFndGyUfFRdVHTUV7
RZdFS5dYLFmz5EaMWowgpj0WHxsVeyR2cqn30t1Lh+Ps4grj7i4zXJaz7NpyteWpy8+ukF/BWXEq
HhsfHd8Q/4kTwqnlTK70X7l35QTXk7uH+5LnxivnjfFd+GX8kQSXhLKE0USXxF2JY0muSRVJ4wJP
QbXgdbJf8oHkqZSQlKMpM6nRqc1phLT4tNNCJWGKsCtdMz0nvS/DNKMwQ7rKadXuVROiQNGRTChz
WWa7mI7+TPVIjCSbJYNZC7Nqst5nR2WfylHMEeb05JrkbssdyfPJ+341ZjV3dWe+dv6G/ME17msO
rYXWrlzbuU53XcG64fW+649tIG1I2fDLRsuNZRvfbore1FGgUbC+YGiz7+bGQrlCUeG9Lc5bDmzF
bBVs7d1ms61q25ciXtH1YsviiuJPJdyS699ZfVf53cz2hO29pfal+3fgdgh33N3puvNYmWJZXtnQ
ruBdreXM8qLyt7tX7L5WYVtxYA9pj2SPtDKosr1Kr2pH1afqpOqBGo+a5r3qe7ftndrH29e/321/
0wGNA8UHPh4UHLx/yPdQa61BbcVh3OGsw8/rouq6v2d/X39E7Ujxkc9HhUelx8KPddU71Nc3qDeU
NsKNksax43HHb/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw82XmKfarpJ/2f9rbQWopaodbc1om2
pDZpe0x73+mA050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmfd37yQsaF8YuJF4c6V3Q+urTk0p2u
sK7ey4GXr17xuXKp2737/FWXq2euOV07fZ19ve2G/Y3WHruell/sfmnpte9tvelws/2W462OvgV9
5/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3pfd790QepD14/zHo4/Wj9Y+zjoicKTyqeqj+t/dX4
12apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+pzytGtEbqR61Hz4z5jN16sfTF8MuMl9Pjhb8p/rb3
ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt52To5NN3ae+mp4req74/9oH9oftj9MeR6exP+E+V
n40/d3wJ/PJ4Jm1m5t/3hPP7CmVuZHN0cmVhbQplbmRvYmoKMzAgMCBvYmoKMjYxMgplbmRvYmoK
OCAwIG9iagpbIC9JQ0NCYXNlZCAyOSAwIFIgXQplbmRvYmoKMzIgMCBvYmoKPDwgL0xlbmd0aCAz
MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBtZ1dj2TJcZ7v51fUtQG2Kr9q
ugFCFxIEA74jNICu7bXWAkEaoPn/AWe8OT11uuPN5U49p0wI3Blzn46OkxkZGV/5t8ufLn+71NeX
Vi+vpb3cXi9/vYzbeHn78ee/vP95/q++vvZrufzl+7/w+S++fCf85fJfl//4b5f/e7nO/4y3cXnt
9fL//vPyH/Ov/um//71c/s/fL//0r/O/f/n75fpyu7a3Wm7un778/ZdLf32pr69ThtcpXEjX316u
4zb/4msIOaXr46W89o9/8Tbqj3/lL98ZX94ZId+v8+e9Nf0/+0/xk+8/qEzc/Mnvotxe2mv/sn70
+kn6m0/CxL80f/ZHyvvPTr/1l7sm7G/94Wc77uEHvdUp3A9pl+Lef/A/+KU/aXMuhqXeqbzj75h/
648a/4R5/+Hff+vD7+p+69brS6mHb916eWm3g3o//MX8yV/e/5Ufv/b9L37mW7d+fRlTez++dWtv
L6+1f//R8Tt+/JtYeN//pfs3uf/Ff32JdZa+9eHv7t/6XWLzs9ennb+kpDv+oO96+f6t3xHv6v6N
bx1b6/0jfdfmj2/96XfMv7X+5vtH+suXT5j3H/77fut6vb283X5s6y/x5/JhX3/8m/jR3/+dH9/6
x58/fOq5yPLvf9/W9Tpe+vyyP9Rdr/3lNg3LfVv/+Jsfv+L7v/RjW9//Yv3s3/VL65dcv/Ta1T9+
0Lu1uGO/7+q7Er5/6vU7z23+4XfembL3T/SOuX/qHz9av+PSbtaDvtHd1L5j3n/6NN7zP7Gian15
K9P0Tim/zg9VXsa1X8r8r/plHgC/Xor+M/+Xf5uifp2nTfyLf1j/uE6hMt6uL69TO7/89fIv3y4l
/gfzfzL/+9Ynqo325dtf5zESpG+/Xv54vV7LP1++/fnyb990lj2A/eqxlWHHRtrGsLfqpe0Q++ax
B91OQ6ZvcfjObX7veXQfv3Mc9PrOX0qsiEe/862/Xt6/85fzvvPEpuVzwnd22BO+s8Oe8J0d9re/
c3mdFmBaZfOh52dGHzpO1/WhJ+m8Dz2xz/jQDnvCh3bYEz60wx4+dL38j0u9/Dl88vrDJ//Xfw/v
RBv93//1H2/fL9NM38Y003W8jHmYfp12ZP3zXy7/Pg3yO2uagvljWvyYf2gSghmmv303/e37T3hf
KD8sf/2fP2H0MvXrtNDXH8vvB/V6u1PX6fN77JjBSxVJ6J86rjJ1OpxW6MN3fUDBr17W+jOLMMv6
9mplLUzWcp0Htvtu/3n/bg+ooBQt4/y9/jfDzgVmpWVrt7Srx/7KpG0bad8Ytntp6/+CWL/A4BYr
o3ndst1QbhssVMJ0tO0Ce2W6fZ0Hu9ll9WeOu2wSysbSXOG6fdvo9hekhHr1WGjB6rwiOd1emU2o
xW+HwtZtrRt7y2xCbV63cCXUtpGW7bLab/6TsV1Whz90jrvs3T37XWeafLGIE737Yvrn032x9vbj
dvbdaa9sp8kXy9RTfTGDZ56IfLHzqeGLZWphK+3NU6/QaZIvloWtBx/6d63bj/5+mUEFp4Mr00Gp
sduytFdmG4qcpoyt0HOUyTHYnwlYmBN4hC+WsfBMm3E7i70yu1BuHlugG6J76vlKmBkqq1u2Heo1
/IXTpa0lXLyMhbusVr/ArtBfqN4msKNyHMIW+ufTj8oZB34PZL4flczm6qjM1FOPSoM/4ag8nxrG
IVMLtJDXWMAZS4+Jq5cWev0rbpGlLczmlOqlhZeJ0sJCZmmhcSiRG3JYeK2cWQiHrRA704wOS49g
Of9Gt2zrlq9+O1TojL16LFWCAgxZCe2KIgFllrE84ZPN9KvFQptQZ7r0GdIWbxOww+B3Gbyb1Fky
8gwldL8SmB/ydV3Zi+IB+sPpjsj0pD85IvBK+TUUYajMz3t9ClXb18gKTaO2b8bCDVFm6stplt6l
6gYLTzPFB7MSKtRt8wuBBveVisjSwr1QdKvO2LO88mUYDB8q+RYHxROw/ts1KO3XsOhZWuwyeGnp
Ln6Ls/10aVdOImOpy6DbScZCf3/lJDK2sitarRERyVhoHFaqI2MLi+StnITBskBA3dicwux5HeGO
ZWmpbpX+zNjCAoRV6c+MhZu3Kv1psPCT6XZisCwCXVVpYbBMt+26WQlsgTWlP4207ELZaoQzMxaG
ilvzWLgdmm4nWVp4q25KGmTslVmwpntJxkIz3pQ0yFh4oLdZWOxWwvGK9kBWSuGVmfP7dIuCC0HR
lfOp4dKcTlXI5repP5Wt1l3vdYXgSwl3SX848+q7fkT6aNDd13XSKALGXBV4NtjBYldy7Qz2IC0p
dPz+5ZKO4cYoijYZseElQgV5BgszirquZmxjjm5RtMlgobQ9InkZCw1vkeuYsTCSV25x7zNYFmkq
ch0zFh4T5XdYyQdOn7KzZKy6q+iWmpVA/WdVzhks80irImMGy2zCuqVmbIHevlxHg4XSKoRlsAd7
/sACqzNp4nYZtGD15rHQ1NSvEczMSqBhEBWGZCy0CXIdZwnWE1zH86nhOp5OlVH8bepPu47l+j1r
Eq7j+sPprmMW+QzXMVOPgeIHNu/87e1XKzDtKdfxt6XlrqPhMwu5XMfzsXIdDRb6eHP4gttxuDti
sySg16SoY1YCtOerfjBj6SVCp4/BfmVXKkUYDJa5N+VrBC4ylur2NWriMxb6eGV2aVssW2Cr2tFI
y6KOs2ndSgsLQ1Yvx/nSqgI6Y+FKqKqAzljqNcnRzdgTvKYILpzvNT2BOr2m86nhNf0D6s97TeUQ
cJvVg7NX5GyvyYh8gtdkqGd4TQZbWDpmGkX/2Q4XNOw1GbHpWRkBtydgw2syWNhcXKJ/zGBpJems
h7dY1punOJ6Tlh1qJeJ4DstSaYrjGSxMpZXwmgwWHhMlykIMlm6HSAEbLKyIKG8bmw4/2Tx9nbSw
ZqzuTBm7oFXd2PPRDiv35d6YTwaznzUavAwWltjXqC43WBpwiyC8wVLX8TYvEQZLXceI4xkstAkR
cIsWhie4judTnyKrXMfflvXnXcd2DLjpD6e7jlnkM1zHTD3FdczYekLAzS3cU13HLDY9K+U6no+V
65ixcEWoYdcpmfp4cbJnaaGFLFHSY7DUD4mSHoOlUcco83NYlrCWPZ9NXk+w5+dTQ7GnU2XPf5v6
8/Z8DneNSRFx/s7/e0ooIIsMd2/U3jj1HizkowkUg60wUCz/OevgePrwUIDhM/9cCRSjDXpMyJ5n
aaHbP6eC2iVBLeQU1K006Pavy7VRAvxk8s8zFjrSJbq8zEooLMivahaHPaGaxWBhAZJSEgYLr1Q6
1GYJ7BMOtfOpsQxOp+pQ+23qzx9qt+MlRX84/ZKSRT7jUMvU4zHx8KGWsXBw5opvZ+xRWn6oGT60
kLqknI/VoWaw0HOYE/DtjoNxwpiPZjYyTIOWHm6/UQLMpMxx7xYLb2oKkWVp6ckeBaVGCdQPUSA6
S0szHVEVYKSFA/jKW4TNjbRsJdQocHJYth1WfNtIy0zNim9nLG3Ni7ZHpwSo20jfGyx0HatSaVkJ
ECuvaQ5BeoLXdD41vKbTqfKafpv6817T12MoQH843WvKIp/hNWXq0Q952GvKWDjicnlNGXuUlntN
hs9M2QoFnI+V15SxsB14VQVkLB1G0cNCZiw92aOW0mFhLCuKHh0W3tnn7++wsAlURY9OWrhu5d7k
T3Y8fX7KSurcmY/TKGCq4Ln+cKaV1I+YLeKfjjZoJRXBMVS2GqIdKaZ5f5aVURXcNVS4FvQKUcbS
AtjoRjI6gDUXJeb0OCysFYo5PQZLTaOCr0a38JNFk5ORtsEAoSyukfZgcdEhLMNg+FAbMafHaIPG
4zcG54w5PUZaGC5dMWOjW3YFVAfk+dJqTo/BwmzwurBmJUBPRB2QRlp4tmtOj8HCdas5PQZbWKO8
JgYaLBz8WqOH22FZEKuO8EnNSjiYsgduP3VjE+gnizkXTlrWMVOjX9Ng4ckeT85aLGwIjo4ZJy2L
37TrZoEx3bZ4EclJy/yQpjB8XrfwkzXFyzMW1iy3GFjslMAO9KZ4eZaWjv+Jp4uctHD8T7w6abDw
dGgx18FgoZ/QNhee483vAcMYdjHm9X668EC7GGbxCdSnyBpxx38g60/dqOMKGU/d/ihBWn8480a9
fkT6aPAWEbdUpwh28qqH22GZV6O4o8MepEVXnigec3xmIRV3fAI24o4Oy+oTVYJksLCWX21DDgul
jbYhg4WGV5VNBgurbzT+x2FZqEnjfwwWHhMa/2Ow8JzQ5ddg4b1Pl1+Dhc6YLr8OyzxSjf9xWGZq
dPk12DPG/zgslDYiYw57sOcPuDca/2Ow0IJp/I/BQlOj8T8GS6MrcZ00WGgT5DrOa88TXMfzqeHb
nE6V6/jb1J93Heuh0G++OvWERnajiDNcR6MItnmX65ixZ4z/MTo4NWXt+MxCLtcxa4MewXIdM/aM
RnanBOjeRPWNw7Ko4/JIsxJo1Zg8UoOFsf0o9DNKgEEhNbIbLDwm1MhusHTdRv2gwWLXMfyQ8z9Z
NLI7LHQdoxHHYZmpUaGfwcKOFjWyG+wZjewGC+te1chusNR13G1e+MmiUcZIi13HGXo1WGgT5DrO
+QNPcB3Pp4breDpVruNvU3/edWzHqKP+cHrUMYt8huuYqUdn7IF733IdM/aMGUhuMRwcXR51zGLT
s3KeZ09Yw0WuY5YWVnapkd0pmfp4cbJnaaGFVCO7wVI/JEpuDPaMRnaHZaFX2fPp7D7Bnp9PDcWe
TpU9/23qz9vzcQwF6A+n2/Ms8hn2PFNPsecZe8ZgErcYTrXnWexT7Pn5WNlzgz2h588pGd6Co+fP
YM/o+TNYWC5VoufPYeGhpttE/mTw7rOySAYL61R1Z8/YM3r+nG5ZSY96/hyW1TWp589h2XZQCaXD
wnul8uD5k53R8+ekhbqNnj+DhddV9fydj5XXNLtanuA1nU8Nr+l0qrym36b+vNd0O96C9YfTvaYs
8hleU6ae4jVl7Bnjf9xiONVrymKf4jWdj5XXlLFn9PwZJdPGluj5M1h8XY3LtVHCYUk8EsaZRIuF
WaTo+TPSwspP9fwZLKwKKNHzZ7DHQ+2nrKTOndd1t4zhDlX/fKaR1E+YVQefTrZ2qPkjYTIJnfHQ
PnwNNZ9OfQ0FZyqMkb15KsyklGsYhyws9c+vXrP1sBweMQ7xmoSTlvmQJV6TcFh4U5NrmnXboIWM
RkUj7dE4PKLbqOQ3WLjFSgyHNli4G1aJZtYtbVmNye5GWoqN93AcFi6w+b6bw9LT582vBLjA6sbU
HLHXl3p5/7+//3L53ct4XOJw+cNs9KnTQrR3r2T+Hpdvv17+eL0+9PL9nTpzCI5aH9nJB+pcFUbW
h2pW79Q+D4onUL1eH7pX3GWNLmYnK9PrHNVjqY9kPO6yhmPqZH3kSLtTo2/GUR850Q7UjQYeqT25
U6OZ0Mj6kLm5U9+mq2CoDyXp7tQSvYQOyxbBfJ7RYx9pTDtIGzE3Jy1bBjOd6LGH/UW88ohwt9lE
JKd//gbfjS10GbR9DZW9ThjVMk7WRzTcvh837RIteo76iFG4U6Ny+ynY2MBZsxV2A8f4EIeF4e1w
9n9gp57PWV21zhvPD+x90VYWYKjh7Dsse0ehhrNvsNdHzNhhgUU3sMOy3VBjxL/DPmIdD9LGhACD
fejgOWKPuj1vgcWMEyPtleVUa1xNDBaWxtd4dMpgYQCgxtXEYeFKmJ3mFsvOhiof5N0wnrYS2tWf
jzBz0KIE2Oi2sNtkK/6EhNWvLWZ9Gmmv7Ihsuui9f7K7GYf5k6abnsEyw9h0KctYaMHazt6y06HN
5K/9ZI9cH+72tg2/wGCdRYvQs1tgrHKhRcjZYeG63dhbaMbbzt5CaXXly+v2CnU7iVa37HToMVvZ
fDKo2371Jy8MCvYP/u1pFqxHcvIJSojH3Q0W9sT3KOly2MMN9XdHAe+mpseoKodl26E/Z5f1zS6D
97IecVyjhIeilnfdjojjOiyrvRqbXQbLn8fGq+nMYxyRMjJK6OzkHfEYsMFC125ECYDBwkzU2PgJ
0GMcw1sw6DGOKJw0SoDux4jhTw7LnKURBQsOy4IqI+oxHZZdTsfuXsbM+PhwLzsckWyX3TZ+AjzQ
bxsLBpt0bzs/gZ1lt7pxllj16G3jfsDox+057kcEsPsM6X8OYDP3NgLYjsq828g/OSoL3t42srJo
aBTWOFmZ8Qrvy1GZXsN0OSrTQFguR2Vfq0REyWFZeEJZLYdl5nvORPTSMstVIqLkpIW6jbniDgt1
GxF8h2WrtsT0JIdly1blOg4LdRvzPB2WOUnlNr0Zh4ULLCJKBgvjtmqxMVgYntCgNodlN5zyuvlk
cIHFs1pGWuiFl5i24bDsJK/X6dw7LFtgNaoIDBaGgzXEw2BhjCaGQThpoUun4edOWpbGqDvDCD9Z
PKLrpGVmPFqMLJZt3hqhdictO8s0U91hoW53Tii7iii16aRld12lNg0WDpqozzGMdWcY2cnbosDb
KAHGaFrxpwPsrNGodictVMLOY2Ruc9t4jLBkWqPanRLYdmhRnOGwLEbTIgjosPCTxQR4h2VmvEV1
mcMyw9i+Pke3EVt00kLdRuOLw0IlvG58MObatciOOGnZEdkjO+KwLPShHKTDsnXbo3TPYdnmVWrT
YZmpUWrTYdm67RFbdFi2bnvz67azdds3jiici9KjT8coAc7W6MMrAfoJPWrsjLTwStKjxs5g4b2s
RymJwVIlRCmJw0KbECkih2VXkr6Ls0J7uwu0ss2rJLdTAtu8SnIbLHTtRqSIDBYGVUbkchyWnWUj
SqUdlh06I0r3DBZu3hGl0gYLK7CVkndYqNuNGYcxxrEz48zUjF38Fq6EXaqMuR9jZ8aZ+zFiJIpb
CdCCbbJlcOLB2LnN7HS47dxmdjrcolTa6RZ+sjjPZwXQ57QxC43LpzFUduToZmqoTLHR9+Q0wCIf
SjkYWdlOiGEaRla4EeIJREOFx4KidUYDzM6W6CdzwrJNW8pmH7DvVeTNGCWwxECpYQsMlp0KJSpY
HZZt26JrnpEWrgTlGwwWfjLldzMW+l5FaQyDhet2Z2nhStDtMUsLDU1RMU3Gwhr8Iv8gY2EcoUQt
s9sOcIHF+BuDLezI1UwKg4VdRJrM+ARs1DI7LHOX55NDHstMjd5+eIa0mwXGNq/ezHbSMk+xbsw4
vI9VFS7mzUuf64gR5EYJGOs/GRxst7LRWQlwyFRVNjpjYbROL70Z3cIBXjVGCzksOyKrki5GCeza
UN82jig7HeqbVwKcidyioNvoFh46arQ1WNhy3ebXctLCBdba5nRgC0zvkTslsJWgRluDhQ00LQYV
GSy0CSvJbXYZuzs0hdUyFkaZ284wMpvQdv4ti4SqI9Z9MuYstU00Ad50mqp/8ieD4YS2s7dMtyvJ
naWFXk1XtC5joQXrMVzp/JXQd944c0RDUCstc0R7dBY6JTB7q/5dh2WBQPXvOiwzNf05YYq+CVPA
zbuS3GY7wJWwCVPAZGFXNtpIy86y/pyYcN+ZcTauqcdgA7du4S7bhIXhi61jY29pg/jGMFZ26Ixd
mILpdiW587qFB/qo/u4Aa/HVIG4WGDx5VzbaKIE5S2oQN9I+NNvxMIFARZxZWmjBRszidNIyezt2
N3QWXhvPMYxjYxipbneGken2dt14NczU3NSfYxYYc+1u6oc0WOYs3WIUllu3bPPedvky+Mk2+TLY
Ja+A6Gz9+ZSSp1Y8NJupsMxQ5SmGynosdTs3VHY8fo0NZqjMeMkkGirbX4pZZipszFHBS6ZCg6iH
F5xi2e4qcumMtMwLXyl5g2WLq8ilM1hmuTT22OkWKkGRUCMtxUZWz2BZarPECCyHZVfooiu0kZad
YauT22DhAlMnd8bCY6HsbC2z4EV9OVlaeNwU9eUYLKynkUtnsPCT6a5rsOzE0Uhttx1YGqOqBMpI
y3bZSskbLNNtVUF3xsKEVlVsMWNhQqvG1DL3yeBKiKGpDgtXghoWjRKYT1N11zVYZmqqykINlp28
VVfojO1w3SpFlLEw6lFfN0ckXGBvEUfI0sJwcN05omyBNVVeG2mZI6oh1U4JbCU0NSxmaWmDeDwK
4KSFStAVOksLy8uartAZS/O7O48RLrCdx8hMTVNLSlYCHOIXj7DYlcBswsqdG2nhdthdz6Fulcsx
0sLtoJJTg4VKUMmpwcJPtrO3zE9YuXMjLfMYV+7cYJluV4N4xsJczmoQz1iYGOgbewsN40pyZ2lh
WWScN9bUsM3b4yFHd5axmHhXCVRWAvRqVkreYNnm7THs1ykBboeNN95Z9GM1iBslMCe/P8dt7ju3
mZ0OGlfuPhlcCaoNNbplK2FoEmfGwsjS0MA5g2WHzsr0ZyyMLGm4uvlksONlKKFlpIWfbBe/ZYHW
1SBupGVh4bHzxtnpMNQgbqRlm3c1iGfsMas3XxrU86798jNPux7S/tECNDsUlOKbMZxz3oNTL5ih
sg2nGqvTqXLLDZUtCXnlhsrWrxq2DJXt4RKj289fBEWV/kZadq6vtJnBMtUWhXENll3Ui+YgGSxz
HNekYoNlZndNKjZYmNVQWMFg2fWsKKxgsMzsrpHC52M1kuIJ2HDKDRbqVq34Bsscx5UxMli2y1bG
yGCZr78yRgbLXuWpKmM0WPbJVrdlxtKAvrotMxYWXa5uS4Nl527duR5QtxvfA95M1jRdowR2Oqxp
ugbL/IS6cz/Y5m0b9wNGglajYVYC/GRNgzQM9uDbkue/2wc/ZMbN3z1y9u3aB5tzwLJ90TSP8V0b
Byw7gtsHm3PAsn2xxuoaaeEC1ts0Bssc3TX/1mCZhWxKJxss/GQqP8zY42X1gUcHm+oPM5Y2iSqd
bLBQt0pvGCzT7UpvGCyzCf0aqXqDZTeprvIdg2Wmpquu0WCZTeiaN26wzNFd828Nli2wrjHmBsss
2EpvGCxctxpjbrBw3U6iW7fw+cl+ixxPlhYO7+mqCspY2D3fNS0uY6m0X2OgV8ZSadUBk7FQWjUo
zFDbpwaFznaD1kGmXg8e3gMnmcbOGyqzivpchso2rr6WobJ9q3b8TIUDRVbRv8HCUJjalTIW1l+u
59sMlh03qzrfYNmaLZoqbLBsIRSdYgbLDseiqcIGy/yZaQ6nSTRYqARNDTRYFlxa4/0MltmZoqJ/
g4WfTHEVg2X2qyipk7HwMrLG+2UsvIys8X4GCy2YQrgGy7ZDVXuowbIFVvVKkcGyS/R6Z81g2eat
NXzFjKWx1p29hZ9sZxihEnokj40S2I2sqijKYNkYiarqpYylceydt8gO9LozjPCTady6UQLzmKty
WxkLY60rjp2x0N5W1bZmLN28O3vLzrKmOdNZWqiEFR7PWNi2tObwZWxl22HN4TNYZmpWVDxjqW6V
9DdYqAS1KBgsc/Lbxr+F26GpRcFIC5WwM+PMMDYVoRppmX/bdm4zO9DbzoxDJWzc5iu7kqypgUa3
zL9tSkcaLPxkasHNWJqOVMlsxtI5fDtvnK2ErqdIs7TQJvSyuUqzOo2VGsjSwkrcrpypwbJ1u96w
M1jmJ6w37AyWXaD6JsYKj8j1ht350qokzGCZTVgx/IyF/m3fxIQxdrPL2A19TQ3MSoAXqL7xxuEs
mP4cb3zsvHHm1axeAqNbZsaHOnsNlq2Eoc5eg2UWbKjTzGCZkz9Uo2Kw7M47VKNisMzejp29ZRZs
zNybi9XAzt6xiX7AQKt0MGeWfMrrQV9JE2UNlW0GefiGyhatHHxDZVc9hWkMle1bGXBDZftL9jtT
oRs+gaVnKvQUi9zljIXboMhdzljYHrpykAbLNkJRh5nBsrtu0SCcjIUvkqwnxjIW+rXzYUS/wKAS
1GFmpGVXkaLGDINlxqvoVDBYZr2K3GWDZU5SUSVNxsK7btEs2YylT4ypctFgmRLWw1JPwHp7W9mF
v+pZ4iwtLPypioQaLNsOVZHQjK3M3q4pVgYL82S3GOVlsFDazS6Dc9Hrh102fdz3cvnyz5dvf778
27fLny4PFGutFFFWQmOeUlVsMWPhiI6Vy8lY6Cs1peQztrEF1oq3CRSrQt53aU9bCU25nHfsvRUB
FkS22dbtdlmDofaNn0CxGz+BKkHRuqxbuhI2lyeqhM3tiUq7uT515jG2zf2pMR9stSLkTwa98dWK
kLHQG18DnAyWBVNWh4PBsiDgevzIYJlr1xWtM1ioBDWqGSxbt10lUAYLlaCSU4NlB/pqnDBYFvvo
apwwWLjANmac7jL13BppWSS0qwTKYJkjut5UMli4bj84onc/AcZquvrfjLTsAtVVi5+x8M4b1wbn
1cACgrELr7GzbKjEPysBZp6GXiQxWGbBRo1qy4yFycI1FypjYUR0bG7oMFk42maBQd1qvF9WAtwO
Y2PG4ejEoX5jIy0LUww1qhks3GXqN85YaBiHprQaLFTCxsmnK2Hj5NOMlvqNjRKYazc2dwdoE27K
nRtpmQ8WycIxnyP9nCxk3kf4NI7KnI9waQy1Md8jQmuGCs+xcGgMFQaVwp8xVLi04kleQ4WGtsQ8
SoOFii3hdzgs8+mULXRYtrhK+B0Oy45cZQsdll1x1LHosOxCVsLvcFiohPA7HJYduRNpsfAQK+F3
GGmh9SqRcDBYusvi4R+HhZ8s5pw4LFy3G2sL7WKJe56TFioh8hgGC+2tWgsdliUc1FposPAuUmMS
lMMye6vWQodlnkeNuJrDspVQI65msAUqIToWHRZK2+ezcA7LfMUalWUOyw4dvSdksDBcV6OMwmHh
AotRFA7LvPsasygclt3z6sZjhPa27TxGtsDazmNkn6xFpMrpFkobhWAOyzZvi1HjDst2WduYGhiz
bPEimpG2s7OsxdQIg4XOUttYsCvbZXr4x0nLnCU9/OOw7NBp0f7msHDdRkjJYOlK2HmMrCSw7TxG
qNtofzNKgAGwHu1vDss+mdrfHJatW+WNHZZZMLW/OSxUQiR4HZZdTjUZz2Dh5TRezLDSMvejR0GN
kRa+Nqf2N4OFwbW+uaHD00Htb0Za6Iiq/c1g6UrYOaLMMPadIwptQnQxGyXAaXMjhio7LDM1I950
cFgWulSfmsPCPMbmhg5fTh0x/MdIC9ft2N3Q2QJT+5uRlubfdhFRuMA2N3Tapxbtb04J7IhUJtZh
mbM0dhFRuBKec/EfG3sLg4FjY2/pyNCdfwtXwiYiemV16LddPIH5YLddPIHZ21u0Gz9hO8QJOXuD
Pyd4WfBDCd5MhRX+UUPhZGU7NwqaHZVpQPfSrAFoaqPSwcnKTKK2l5GVLVhdSg2VnWEl3ht0KmBX
kTJrHCyWWS51gzppWRBw5XeNbtmaLVFX5qRly0ttmw7L4l+z495Ly9zlEg1lTlq2G9QN6rCsJ0XP
dDksXAk7owhXgrwZs27hLlO0LmPhnWHldzMW3szLztyyd+Cqbo9GWrYSViI2Y6Fuq+JfGQvPxxoN
ZW47sHVbdR8z0rJ1W1WhkrGw6rjqmpexMP1Wdc0zWGZv9aiY+2RQt9H+5rDMWay3SBEZJbA7Q42H
rx0Wbt54+NphoW5fN0pgB3qNylgjLYzb1lkU67AwRrOy0WYlsE+2stEGy/zblY02WLYdmqJ1BssW
WIt2Y7MSYEJL7cYOy64kajd2WKiEmIHlsMzeriS3+WRw3SrJnbGdJQY049UpAWKjwcFhoRJeo/on
KwGOJWm7az/cvNHg4KSF6/bNb17oMaqL2UnLDGNXWM18MqYEtRsbaakSqj/Q4RGpYaxGWmhve0yX
cli2y3qMgXJYZhi7iorMSoALbHgzTldCzNR2SmA2YWWjjRJY9KNHn5qRFla39+e4zf05bnPfuM3w
utd3Zpx5NeP6lF02dvFbFv0YMffGLDC4y8ZzHNGxC1OwQ2dlo/PmhQtsqPonY2E8YTwnfjt28Vuo
241/C/scxs6MsyNybOwtdETHxt7ibLT3augC2xlGdqDfdoaRfbLb1Vsw+snCTZg3yU/5XWoSIlKT
qXAz3OLEMVR2kCliZ6jswHn1eoW5ATXwGlmZU6eqDENlMUuF1QyVbQNN+3WLgJnvEuP2HJaVkKz8
rlECW7Irv5uxBepW97GMhRWsK79rsMzOznks/pPBlSD/IEtboLQ740WxGyXAAgId5EYJLIJfdHHK
WHiQFx3kBssupUX5BoNln6zGJA5napgRr/IPjLRsO1TFvzIWXpxqzMVzSoC6nbcQi2Xbocbjb05a
qFsFqrJu4UTaqoiSwbLTQSOPnRLgulXVnpGWeR9Vc1kMlp28GnnslAAX2M4Fg3UJqrEzSmDrdqU2
MxZeGppCPxkLT4em0j2DZeFgTVJ2KwHqVhlTIy3bZXps00nLdlmL530clpmaNn9/i4W6VUTJ6JY5
+U2FLwbLTE2LhxyMbqGT3xT6MdLCT6bRLAbLDvS2u/HClRAPOTjdQml39pZh+84wskOnbwwjjNZ1
zawyK4Fth64JBAbLnPyVgzRY+Ml2rh0z4ysHaaRl26HHq+9mO9D87nMMY98YRhhbW6lNo1tmGPvO
EYULTDXNRlp2Q+8bwwh9sL4zjMyCrWShUQL7ZNFFZbcD22WaTex2GbNgehDSYZmp0Wxih2VXkrGL
MULd7m7ozMkffRPGhwtsZ2+hbpWDzNsBHugjXll0K4Ed6Boi7LDMMA7V2GUl0DyZauwMFq6EXYyR
rYSbRrMYadkuu8UsePPJYDDwFk8tGiz9ZLF351COz6lNZheVkDdUZmhUb2qorPtLTaaZCh2l+eyu
0yucyqJRHEZWZmSKRnEYLHOTVhbSYFnZ8ZoibLAsF11qdEIaLLNdRcEfg2UGvEyzZaVl+3alC420
zNKuvk2DZZa2qEM+Y6GlLZqBnrGwra5oeJvBMve+7CwN1K2O8iwtDF+X51iwurNg7MCp1zhzsxJo
7klTLTO2sTvOmsubsbAyYc3lNVhmwVY7qMGyQ6eqAN1g2RG50oUGyzbvShcaLDt0qsLXBgulVfja
YJmpqSoDy1h4I6uK0hgsm29aFaXJWFi213QZyVh4lumF1PMtWFPneZYWmprVW2iwzKtpinsYLNtl
LR5jdrplh05T3MNIy3ywNUA3Y+G0qqaSrYyF16fVsmiwMAupkRwGCzO8uzskO9CbwtdGWrgSNoaR
fjINLDfSsl3WNWAsY+EYLD286jYvMzUrXZilhYZxpQsNlvlgK11osGyB9Z29ZdthDdA10jLXbg3Q
NVio23jK1C0w5iz1zZ0XXkn6LrbGnKWuOHPWLSzP6JvLKd1lijNnaWmIdePaQXurN0fdAmPrdijO
bJTAdtkaSWuwbDus3kKDZbdIPQ5qdAtbxMfGMEInf+wcUWZvV2+h0S0LtI7neIwrAWekhet2Yxhh
MFBPQs73vz6lXeAlUqlNQ2UemDKbhsqcBHnimQov/XLEMxVWZui4MVRmaXXaGCrTa9FpY7BsEaze
L4OF0ioUarDsWFhPQmYsjV7r3aCMhdt2PQlpsMx0rSchDZbZ7zkhYDq2Bgs/mfxlg2UXsqLTxmDZ
jb+oIdZg4S5TS5nBQt3KDc/YAjOxCiRk7JViIxNrsGwlrLcbDZathPV2o8GyzVs1i8NgWXBxjQw1
WOYqVo34yFj4jkXVLOWMhf5yVcFaxsJK3jUy1GChbhUPNli4wMZmlzGnpuplCCMts2Aro5WxsOG4
KqOVsdC7r2rIMFiYf1OENWOhz7w61TIWOs1rCKfBsu3Q1GtrsGzdNvXaGiw7dNrOY2TbYb00aaRl
NmG9NGmw7NBpGtFssFAJGtFssFAJasgwWLgSFLg1WOZ+NBUrGSxzRNdLkwYLV8LGEYWh0KaRCUZa
qASNTDBYZmq6Zh8ZLDsdVkYrY+HpsIZwZiw8HbqGcBosOx3WEE6DhZ9MVZwGy2zCGsJpsCyosjJa
Bsvsbd9d/OG63RlGtnn7xjDCEFDfxC3hIPTVAGc+GVy3qiAwWKhbTWIwWLgSNA3LYNm6HbuIKDM1
q6/OSMs+2eqrM1iohE2gtbBPNlQ1n6WFkaWVKMtYGFlaiTKDZWZ87G7ozLUbmxt6YfHb9XZjVkKF
C0w1pxkLXbuIA9pgINy8u0ArXAkqZTVKYAe6Dt45+PhztpBZcZ27mQoLqzSpKFNhbE2nrqEyDShb
aKjMgitbaKhsDejBK0Nl+0DFzIbKrtDrfUGDZYpd7wsaLNNsUegnY6FBLLrhZCw0iEXT2wwWfjKV
phgsu/AXhdoNlh02RV0eGQvvurO/dh42GUvzu7MqxWLhJ9uYWnjDKXqE2SiBWZqigzxjYUlV0UGe
sbAUcA3hNFhoatT+lrHHIvzrS728/9/ff7n8bf7h67zLXud//rD+sb6+aPb92/Xl9e325Ze/Xv7l
21xg638y/ztizrf3Sqg5H+vy7dfLH6/X8sgHvFMjF2eo9ZELxIE6s1CGen2kfu9ODavzBKrXa2V6
jaItJ+sjrs1dA5GGc1T2tWJMj6MyDYQb5qiP7LW7BsINc1SmgXiXyVGZBko0OTgs2wbywwz2Ic/m
rtlSNkpgH0wOk5H2odP3IO3GcD10QhywkdRy0sKVEOMXHfaRi+lB2rhCOuwjLsgBG3dIh4VKiJJT
h4VKiKIth2WmtkQRgcMeLE2c3tfLzxzn7ftx3i76dLPU6vPtn7XChU96M9RHFsRd1nBJHZW5++GR
Oiq7m8Q8Bkd9ZDXcNRDjGAwVPuEYfqOhwnioBr84LFNBiVe0HfaR8+GuWQ1+cdhHrMIBW8OGmZ3A
1myJFmmDhbVrJTx/g4UVSyWep3JYqIQYU2OwVAkbk0jvklH5YaSFsUuNqXFYuMsiwemwzCqWaHhx
WBi7i8oPg6UrYd6lHZZ+sqi0M9I+5DPeTU2Vm3+6qakx+vgJ0saET4dlK6HG6GOHfeSuc9BtxEUd
ljk0etXCYQ/O3e8O0RykjZY9h33EcT5iNzYBfrLozTDSPhRROkh72ywwdujUjWGEcdEaOSijhIeu
pwclRADTYeG6jZI4h2XJY02/cVj2yVSC7LDMtWsxitNhWWK+RYu0w7IDvcWrFg4LdRu9GQYLKz80
VMdhWfNPi8yOwcKbTovMjsPCBba7RcMF9pxrdNvco2FBSfu6OXnhuo3aNffJWNyjTffLYpm9bZFJ
N9LSSRcxgdBgoSPao4nCYZmf0COT7rBsJahW2GBh849etTBYeJVWUa/DMo+xx0uOBgtT3l3pJ3Ml
YduhK4JrsMy/VVGvUQL9ZLtQIDsdNP3GSPtQ+uXuMfadawd32XOu0n13lWZH5NhdpZkPNsrmdGC6
VVGvWQkPpbnvK0GvWhgsjIONTegS1rhrVo+RFp5lo22OSHaWDeX3jAVjNkFDdZwS4ALbRETpJ9tF
RKFu43EipwR2RI6Nf0uVEJVLTloWsNIbHAYLI6JRvmalhet2Z8aZvb3tzDhLFd3inV+jW1h7edu5
zUy3t+jNcNKyI/KmOjBjwdgnC0vzdV5LPqej2d6NQgJHZbJGJNBR2eqKKihHZb5tVBE4KkvnxCXa
UZleo//LUdkaiPYvR2VHowZiOSxTgQZiOSw7GkvMfXFYdtiUsAUOy655JWqrHJYtBFWNOyzbYSWS
Lg4LP9nwewxmRzS5ykkLt0PczB2WnWET6bHsDFNtlZOWWcWyM4twO+zsIouJl41hhAusRnbE6ZZ9
shrZEYdl61YDsRyWfTJNrnJYZhNqXEodlh06NS6lDgt1G5NUHBbqNm6PBksTsZF0MVjo3Ne4lDos
M4zKRjss3GURsnRYuMCifNFh4QKLYnyDpSshyiINFs4mafGalMHCsJqeeHkGdrMS2OZtUf1jpK1s
3SrJbbAwRqM5Ww7LzHjb+Lfw5G3Rn+SkZbtMuXOHZTUfbWdvmalpkeR20jJ726JMx2Hhuo0mJYeF
u2xjGOE7oS1mSztpWeCjxyQVgz22Lz5QDNd3jijbDr34KAWcTdKjXtwoAVaoaHKVw7LtoCS3w7Lt
oCS3w7LtoCS3w7LrXo/qH4dl8QTlzg0WTr3tURZpsDAxoMlVBgtLpXvULzos1O1z7K1ejnHSMj+h
7+wts2Bj54hS7OYCxQ70EW2hTrds846oFzfYxs6yEfXiBouz0c9Rws5jhEqIoiKnBLjAdhFRiI1n
5Y20lfm3Y+MxwgLZEbOgnLTwk23uvOXXf758+/Pl375d/vT7Z0YcSkk2McbKQpdKFk6H6XOykOpg
atZQmay6j2QqLLBTsvB0quLXmQoDHwpfGyoz4DobDZU5tiWm6LpFwGxMiYJbg4XOV4nKAYdlbngp
cc/LuoWRqpWEzFgYYS3R4GCkhW8XlhjO67DMnSnRu+qwcN3qyDW6hSsh6nidtOxCNucaeCxM8EaT
qZOWnQtFlwajW2gTFBQ3WHbkFp3kBsuOsapLg8GydVs3hhHahBqVWmYlFHbm1Pn7O2xlC6w2jy1s
gdXmlXBlrS41eqmMbukni3G3Dgt1u7NgcDtsLBh06+rGglFstMk73TIzXqMo1GHhLouiUIeFpkZ3
EWPB2C5b+beMha5dU5g5Y2FcrW1cO7h528YwQo9xpfWMEpgP1prfDvST7ewts2Ar/2aUwLZDG14J
dCWoOsNIy0xNUxmFwbIIq3pXnamBCyx6Vx0Wmprd/RwusFnMbaWFnyx6V89XQo/afodl22FlC80C
YxeorrK1jIWmpu/uvFAJ8e6C0y1btz2mSzksW7d9Z2+Za9dVtmY+GauV7hvDCF27vjOMbPP2aHpy
n4y5dl31ZVm30KtRS6yTlmYLN44oO3T65oYOy39WWs/olm3ecd0ogW2HsfFvoceoltjzV8JKQhrd
Mj9hxDB/Jy1bYKNt4mDsdBhtczowM67nc5wS4LrdRUThuo2hVUZaeKAPVWeYBQZXgpKQBgt1uzPj
LHQ5dhFRusvmF5uV85+zhXAhhItvqOzcVbbQUNkyULYwU2GdtC45mQprbpXfzlR4OOqKk6mwuk43
HENlTtJqLTRYtg1Wa6HBwqSLWgsNlpmYldUzWHaGFd1wDJZt25UsNFiohJif64wMXGDqWDTSwgWm
+pyMhUOqV8dixsK9O1vjvW6hElS4aKRlTlLR0WiwcDsogm+wcN3GE8du3UJpd/aWxWg06NZJy1ZC
VavL6bqtMdbBSctsQlVEyUjLrtBVHeIZC4/zqg6ajL3ClaB6SINl67YqomSwbJdVRfAzFrp1VYGq
jIVVYKsR0mDhutUwDoNl1ZtVGdOMhde8lTHNWBj/qsqYZizsoNFYXmdq2LrVWF6DrWyXtRiyZrDw
k7Xn2NuV2syfDK6EtvNvmRlfGVMjLbtDN0WUDJZF8FfGNGNhbLEpomSwV1Qj3VShkrFwAnhTWbvB
ws0bT8C5XcaKipoGfRhp2b2safyRwbJDpykRa7Ds0Fn9lRkLLVhXBD9joanpqrEzWHbT6apQMVi2
bld/ZcZS3W7sLWwj6lNQu8uYqeka9JGVAEN2XRWBGQvt7WrbNFiohJ29ZcFrzSZ2hpFdSTSb2GBh
Q9lKxGbdwuqfrlLpjIVXkr6LfjAz3nfRD3bo9HjN030ydjpoiLDDMsO4Mqbmk7FdtvorMxYusPGc
eMLYxROY2zzi+XPzyeDpMNRDYnTLAlZDbXUGy5JPos7i7k/pNzgv4Rb1KZkKg8KKCRsqu5nGpF8n
KzsZlCgzsjLjpUSZoTJL+xbujKGy7aVwcKbCQQmrVy9joae4evUyFnrhReEJg2WqLfHmhvtibHUV
tccbaZmJKbKzBsuOxtK9EmBfTpmCWt0y811GJAaMEtjWLSowzFh4hs0edi8tVIIu/FlaGExZkz0N
Fi6w1/APMha2qZWNYaRtavEAr5OWKaFqwEdWAm1Ti+cmjLTQAa268Btp2e2xqtvYYNl2qPIUDRZ+
snhO3umWlZJU1dYZadmhU1VbZ7AseF1VIm2wLHhdVVZlsOz2WFV0bLBsga2hlgbLDvS2MTXQWWqa
l2CkhUrYOUtsO7Sds8Q2b1N1cFYC9G/bxlmCj2itpEuWlo4yVBDQYKFuN9dSeKCv6ZNZWniHbkpy
Z2yFm1fTJzMWnrxtZ8HYyds12MBIy2xC31kwtsB6iVYqIy0zNSs7YrDsFrna1AwWpog0L8Fg2YHe
d7dI5n50VVtmaeEFqm/iajQxoCdzsrTwArWyIxkLD52ueQkZe4U2YWMYaUJLaQwjLTQ1O8MITY0m
bBlpWTB0aMKWwbJo6FA22mBZ9GNlRwyW2YSVHTFYdncYG8MIqy1X45eRFn4ypY0Nlq3bMYn2iGSH
zth5jHAlaJCMUQK77o1dHIyZmvEa1T9GWvjJdlkHqNtNHAzeIm+aV26UwLbDTR2xBss+2U39OQYL
DWP4oXPtfsrqwaF72gyGylQgJyFToe8hHyFT4X1XJQmGyoyXjvJMPdYHX1/q5f3//v7L7x/2Oi7X
+Z8/zDkXkZp/fU8fzwaQy7dfL3+8Xh86fO7UyMwban3kwnOgzgCmoZZHfJs7NQ40Q4Wyzr3rqA+9
8nyXNYbXG1kp1eu1PnIzu8saXbFO1kfMwp0aTcyO+shZdqdGWt5QC5M1EuiGCr9WTEQz1IemM981
UMIVN9iHGkgO2MgTOSz7Xmo0ddhHfI+DtDFjzGDhOtD4WIO9PnI+HKSNYILDPhL/OWI3nwxKO08y
K+1hJcShdL38zEF2mFoeyph17p98m4eM2IEaQmcq9BciO++oB1U88HaODK6R9ZHj8a6BGEbhZGV+
c5ScOuojS/cua1T4O+ojK/dOjXuOo7KvFd1fjsqukCXeT3LYR06yuwpKTERzWLa2yhxyYrFscWle
gJP2kdPhoIRI9zvsI17tARvpfoOtbH2VSPcbLEzoFB06p1uZEoEaJy1cCTp0jLRwO8Tl1EkLP1mM
IXDYRxzxwwKLCLbBwsB4iToog4V9KWVnbuEni7CSk5alTTWGwGGZYawRVnJYtsD0HrPDsgOyxrNM
Dss+mSasOyz8ZNG/6rDMjGvCusNC3cZ8FoeFK2Fnb+G6jf5VJy0z4zXqTh0WLrCItzss1K2iCfnQ
gf1UNcL4Tlrm1WgMgcHC06FGP9X5WJWuGexDYYr7EanSNYOlLxwr+pFXAjwiNbjdSAtvpRpDYLAP
xYIPut25zWyXtRiz5aRlZrwpcJs/GZ1zEXX+RlpYL902/i2MerSYz2Kkhc/gqbHfYZkFa1G65rAs
L992FgyWqURjv5EW3stUumaw8NBR6ZrBQnur0jWHZfnNHqN5HZYFVfrOY2QWrMfgKiMtHS6+sWAw
c9p3Fgx+sk0slEobdf5GtzDVrZ52h2WOqIaLOyzzxtXT7rBM2hHPfzksWwlqlXdYtstUDOawLNSs
4eIOyy6nGi7usFAJ0ZVgsHCXqVXeYKEjquHiBlvZuCK1yhssPHlHNEA5LNwO0ZXgsHDzRre8wcJ5
r2MXumQ+2HjdmBqohBh1apTwUEL2ftO5RVeCwzIzftvZW2YTbsr455sOLbSLCapOCczJv+1ijFAJ
qn86XwkqJDBYFge7xeM5TrdwO4QfOivjPqXO4d10hKyGCtdBhJUy9aEKjfvOjWEfhgrbMhQHzLLC
01H5EUNlG0Hp6EwtzJ0p8e6XUyzExtRQh2WxH43lMFh4ISuyMVm38A5dVGRpsMyx1VgOowS4aks0
VDksOxs1lsNh2W4oKrQ0uqXSPsUmFlX+GGmhEnSHNli4wHbGFtqEnbWFNmFnbqES5IEa3bJUvx78
NtsB3vNq9MUaLHQVa3T2OyxzZ2p09jss2w5VwUXzydhK0GwSJy0zNTUGBjgsTEcr62KUAHWrGiiD
hStBxUoGy0xNjXZbp1u4eXdmnHnMNR6SctIyw1hVbGl0C7eDstwGCz/Zzr9l0moqvtMt2w7tGiGl
rAToiDZdzTMWtom3aFYz0sLbU6ubqx6LAmoq/hOk1dX8fN0+xzC25xjG9hzD2HaGkZ0ObWMYjw12
j5Thz737NmNrn6IpMBEbFVCGCu+QUQDlqCx0HSeDo7IsbLRDGip0bUuk4w0WurYlLPjbnGb3eRWw
Q7fEnH2DhdUpJcbuGSyMAJaIghosrE5R4MNgYXWKurQclrlfCiU4LMuMaMKnw7LqFE34NFhoE0vc
+Q0Wpt6K7FfeZXTdRtbJScui9yXu/A7LjrEas1kclvmgNbJOBgvPsRpZJ4OFB5nmkTosO8lU2e6w
7Cirs+HeKQGeZTVeCnHSwlBCdBI5LFxg4YMaLLzk6HLusOxphBolkQYL7041OokMlq6EeRFxWFj+
pFpxIy296UWWyGHZum3RC+mwzN626IV0WGZqVNTtsGyXtZ1rx+KAukUbaeHmbXGLNli6wOItT4dl
AbsWWSKHhUGl6M0xWHjytigoMljajBCDmh0W7rLoO3dYuG5jULPDwl2mK69xRKEFi8p2Jy1zRPVk
ncOyT6Yn6xyW6VaV7Q7LNm/fmHHY99TjaQ8nLbMJPXJaDgs/WdSFOiyLtmsoq8Oy7aCCeYPtLCKs
Wa8GC6sBNevVYeF2iHJTh2WRpf4cM96fY8b7zozDXRY1BE63zLXr0SnvsHDzxnwph2UrYcSkRIdl
63ZsvHHo1YzolHfSsqjdiJyWw7KVMHbeOIsnqA7fSAtvkarDN1gYG9esV4eFC2zjjdMFFn1PTlq4
wGZxsMWyBbbyDvMW9SnvAMMURbvMYJkFK9plBsucfBVcvmUsvJyuvEPGwtBliTZAIy0tuIw2QIeF
utXl1CgBroRoZH6CtHI/jLTM1MwhulZaaGpKTEVzSoA2QekMowRmwaakXlp2lmmijlMC+2Q1SsYd
ll1JNFHHYdkNvdaNbtkuq0rImpUAdat0hsFC3UatodMtW7dV6YwsLWwhqWNjweAni/5opwR2Q9c7
aA4LV0KU1DgsVILCa/mTwSOyvsXdwWDZBarGhF6Dhe7HSmcYadl2WOkMg2VX6aY4mMGydduil8bo
Fl5JVjojSwvLHtrOMLJdtrIkWdrOTt62M4wsc9oUsMrSwkBri/5CtxLguo0JZg7LbEJT/V5WAiyA
aaqryVj4TJXemDNKgPGEFu8kOCxzlvTGnMHCZ+X1xpzDsrNspTPyJ6PRZqUzDJaZmr65ocOV0KO2
2+mW3XR622xe+Ml2jijUbdR2GyVUZsF697usMzO+0hlmgbF4Qt+ZcebV9CgZN7qFHmPf+Lf0k20u
/nAEtKYVOSXAdausdF4JVAmbeEJjHuOIoRxOCcxZGtG7aLDQqxkq8D5dt0PpY4NlK0HTiowSoFcz
lJXO0sJDZ2VJMhbahJUlMVjmMY4Y/PsE3W7it3Dzjo3bDCOiQ1kSo1t2OoyN2wyzJENZaSMtNDXx
VKhZCfSTxXxLh2U2YWWgZi7ucwaKBQNXBspg2d1hZaAMli2wIv/WYGHTh+IJGQsn9BbVjWfsFep2
RHjNYOECU6DVYOEnU6DVYOG6Vd24wULdKgNlsOymU+KpCPfJ2L2s6OJvpIUrQR6jwTIlrIaajIWO
qIZoON2yBaYhGg4LlSCPMSsBOktVrp3BsltkjRnjTgnsKl3nWW6xzNRUlaMbJbCbzspAGSzUrVw7
g2Wbt8q1y9jCTE2NQZRmJRR28urxBYOt8JPtLBjUrVy7rNsru5I0tQQaLDM1TVfpjIV3hxaPL5hP
Rvsd4s0yh2UrQY8vOCzU7c4wsgWmxxectMwwrgxUXgk0u6ertMEyH2w11Bgs/GQxodfplhnGlSoy
0sKVoBbsjMUZqCgkyFgYAmobewujdquhJktLTY0KCQyWmfGuSmyDZSuhq0Y0Y+FKWA01GQtXQlch
gcEym9B3/i1zP1ZDTZYW9kWuzheDZR7jShVlLKymUL/47ND4FFiC00QUTchU6Hwoq5WpMDCuEIWh
shukIhSGynaCAhSGyg5HxScMlZkuJbQyFVoutedkKjRcRe05Bss+1wrbZiwsoigxcu7NYNkyKDEN
3mHZOliNA0Za5tauxoGMhTamxLNET1CC+hGytNAJLwp6GCxctxv7DU/GNV7JSAsXmMoSMhaWhhaV
JRgsK/koKrvNWJgmm7Mi7bqlhlED4oy0LPu2BhYZLLNga2CRwbKzfA0sMlgobYugh8GyO+mag2Sw
bJetsK3BwmjwzjAyb7mqXstIC5WgoIfBQmljxKdbCXCB7ZxQuB00XskoAepWQWaDhdJOotUtcz9q
jLB3nwwqIUYqGywsS1jdE1m3MPumkcpGWjgRS7OPDZYGlDb+LdStRiobaeG1dHVP5E8GD/TV5pCx
MAXZdo4oi6q1nSPKdtlqczBKYKamadyHwTJvvKnf1mDZ6dBUH2uwULebaAJdt6rXMtLCGKAKWQ2W
rYSupJ7BspXQldQzWHaWrTlIBssc0RUNNljmMa5ocMZ2tm67knoZC9dtVz9CxsKL/+pHMFio2004
GE5j6Dv/lqV3+86/hSthZ2+Zk7/GK5lPxsz4moNksHDzbuwtDN92Zd+MtEwJaw6SwTIljLK5O7AF
tvoRjLRsgQ3NNzBYdkQOzTfIWBheGyoDOx+7c0TZETl2jihcYDvDyNyPocEvWbewHXLsDCPcDpus
VoFKiEePzL0M1sINlYFl3Rb2RoAO3on+lIeFEXctL0Nl566OXUNls0MVbjdUtnEVbTdUdi/VjAtD
Zd6XYj+Gyr6Wnot9y1ja36DZPxkL2ytXbjNjYTRFr9AaJUA3vOjINdKye95648VgmZdUdOQaLLPf
q9MlY+HNqajTJWNp8lxVJAbLTpui2I/BwpWgI9dgmVVcQ9EMlrkzRUPRDJbZxZXbzFh445+lkNNB
yFi4bqtqSTIWmprV6WKwTLdVBYYGyxZY1YgLg2VnWVULoMEyC7ZGuBksu5BV1ZIYLDPjtYdja7Bs
89aNvYU3/qpRr0ZaqAR1uhgsVEI8z+10CxfYxrmFd5HVQJOVUOG6VdFHxhamhNXpkrHwYbGmII3B
Qmk1NMJg2QJragE0WLYdmkqkDZathKageMbC2E9TUDxjYZhZD7C6zcsOHT3A6rDsDtl212i4bnce
I/Nvm6ozzv9kO48RKkG90Vla6Nq1SXzC6dD12GCWFp68ayhaxkIl9I1hhNUZayhalha2+3QVfRgs
27xdtXsGy9Ztb1H+Y7Bs8/bdxZ85+V2x9iwtHPrbZ5OLVQI7IrtarrO0sPKlawilwcKVoGk6Bsvc
j5WENFioWz3GkrGdpZ765oYOQ0DrMZYsLQy2r1dTDJb5YENDfw2W2YSVLTRYtm7H5oZeWRxsbBxR
eDqsJKRRAtTtzr+FStglieAn0yzhrAToJ4xdRJR54ysJmaWFCYKhJGTGVtboMJSEzFh45x1quT4d
e1M1XMZWth1u1+hNyVj4yW6bi39hn+ymWRRZ2sYSvLfqlQCx0yTM0Uqpfxd2E815hpbKvIRZlWCp
7Hyc911HhSGKWRzrqDBCMZu0LJWZxBmus1Sm1+iJtVi2CGLmoMPivPFmcbGzMUYZOmnh2RijDB0W
WsTIG1ssq8yInliLZdfHMvMYFst2Q5nXR4tlh1iZeWOLhdthNq9aLFTCTDhYLFTCzizCXTZ7Bp4i
rf9klT1tWzb2Fp449bpRAltgdToHVrfsk9UZBbRYZhPqfMvTYWFXf53Ol8Me7e31cn2p8//65e+/
XP42/+HrDNDPv7z8Yf1jfX2JlxDG2/Xl9e325Ze/Xv7l22U2ZOh/Mv+7zv/f+8+YKdrLt18vf7xe
oatf5zsJFsvukvFg1zOw8y5psbBKYd4lLZa5OPWD73j4ZHBvfLCSByyzO/WD93jAslB2/WDODlim
2/bBnB2wzEBEtteuBObitHnps1gWwIwBhBbLrqiRlrVYdkWNtKzFHjZvWLvrgxYy8rN3/gzyf7eQ
0PWPt7Ac9mjcH7DnkfZ1WOj6R9rXYWEaos34lcUy49B2nhmzkO2DKTusBLgv3ja6ZYY3ujmtbiH2
gyk7KIH56P2DKbtj4XboG8/symxOvC5ldcuOif7BazoogW2H/sFrumPhjaLP7iKrBLbL4hkoi2Vn
ZZ+ldxYLP9nMeFosuwn32apjsXCXzYynxbLbWmQ8LZYpITKeFsuUMGZg32LZuo22S4eFJ+/YGUbm
6EbG00kL7W20XVoss2CR8bRYtm7HLAWxWKjbXSyPWbBx2+iWFVfEw0pWCQf/+QFHdMzZ1RbLTt4x
K/osFq6EWdFnsXDdzoynxUJTM/N8Fss+WSRSLRaa8bCL80r5qUkU1mVrM2QqrIbRojVUtnN1yzFU
do69hjkwVLYIdHUyVOYmzbkMVla2sooWrBGWba+iIFDGdrYKihyEjIWzsIti2hnb4MRP3Zwy9ijt
9eUGAivxRF6bnqPswmxgeY88s/UbE+4MFaY5YqU5LGyPK9eNDlgAr8QL0EYJMGRV5pJwWJgrKNEF
YqSFjrNmIhsslTZeyDPYwgxkiRmdBguHEkb+12KZu1SiC8RJC9dtlA87LJQ2xik4LHOcS8xTcFgm
bd2YGliLqtlbRtrG1m3frFvYzKeydyMtrJztMQTWYGEXSIkZGDEk6tNRBmfBRG7dYtm61bxpJ+3h
Zvan/w8wWhKjCmVuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMTgzMjYKZW5kb2JqCjMxIDAgb2Jq
Cjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNCAwIFIgL1Jlc291cmNlcyAzNCAwIFIgL0NvbnRlbnRz
IDMyIDAgUiAvTWVkaWFCb3gKWzAgMCA1OTUgODQyXSAvQW5ub3RzIDM3IDAgUiA+PgplbmRvYmoK
MzQgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA4
IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczIKMjYgMCBSIC9HczMgMjcgMCBSIC9HczEgMjggMCBS
ID4+IC9Gb250IDw8IC9HMSA5IDAgUiAvRzQgMTIgMCBSIC9HMyAxMSAwIFIKL0c2IDM2IDAgUiAv
RzUgMzUgMCBSID4+ID4+CmVuZG9iagozNyAwIG9iagpbIDM4IDAgUiAzOSAwIFIgNDAgMCBSIDQx
IDAgUiA0MiAwIFIgNDMgMCBSIDQ0IDAgUiA0NSAwIFIgNDYgMCBSIDQ3IDAgUiA0OCAwIFIKNDkg
MCBSIDUwIDAgUiA1MSAwIFIgNTIgMCBSIDUzIDAgUiA1NCAwIFIgNTUgMCBSIDU2IDAgUiA1NyAw
IFIgNTggMCBSIDU5IDAgUgo2MCAwIFIgNjEgMCBSIF0KZW5kb2JqCjYzIDAgb2JqCjw8IC9MZW5n
dGggNjQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AbWd3YpsyZGl789TxPWA
Tof/RWZCo4sZxFwLCvp6RtPqRkgDPXp/mG3LM3LvSF+mUu0vQoWoOsnJFRbm5vZv5v91+ePlvy71
/Werl/fSft7eL3+7jNv4+fH157/e/7z9rbf3fi2Xv37+wvcf/PhE+OvlPy//9t8u//dy3f4ZH+Py
3uvl//375d+2H/3L//x7ufzH3y//8j+2f//p75frz9u1fdRyc//14+9/uvT3n/X9/fJ2vf68bn/r
b5f+8fM6bpfbx8fP2t83YkYfP8t7//aTj1G/fumvnyg/7ihB4Z+3T/xo+p/9r/js+0e9/9w+afvo
Scvt4+3nW6k/5kfHB33+5IEY/c72yQ8Y9w9evvSPnRH2Sz988vY532G//iyubKR949v9g3/lG3/n
5d9+7D/Rl/78iuuXfuT3/lv3U/rPH8Hw5XsffrZ/774Rv53511nHn0upO3t/PP4kPvvzd76++Nef
f/WkJWXzlHp/+9l634+699vP8XY7fOvHn4Tc3X/pfigbcRPlzvPf+qXnWX9+UBzlI3GHH9zZ8nnY
v/adNyG7n//G7PsZ3Xm5XfzPm/T4HSd3v/FBJ7Cd0X797jC/7Vu38fHz7aP++Drr+MG19gPw40+C
ms9f2v7O5xfffzDF7P4t9++7/9d+r9vYOL2pkq+L3cbbdtHvX2r7pB+PP4nTvv/S1ynsP5iS9g9O
+6DP7hSbz/487h336wd3zsxvvREn3m1s+FUZvxzOO34tOLyf9+e3PCi0x+/9yPO7lNxx7h+/fHGr
08pH+/lx1RWbYh0/KO1+xYLFjz+JD//8pV2t3VHun/3PHXj5qD+bTNwnB8tH+Xn/5Pk5+58nJfMX
vg77jnD/3N/8nefdvn/u58nuqF8/EE9Of9/7Ed05uavx+yfH3/j+jQ+cPly/O8a3r3w43F2t7yr8
Vn6+X983Z+HrYm8/ufar3Ic7efcfHQTv6/e+7vbhJ/+MmP/4ZOHt+rO+1UnAZPom9mOjIPyX+7f/
9qM48q/f++uC9I0DB9P1axwQAT8On/adyC8Bu7Nk123Z9z8o8wfl9p25h3t+IOA7B/wRLFhfLJBv
F0ql1p8fm2m+vW/+2eYk1RJMvpTtX/XH5vP9+VL0z/ZX/2tj2Nt2+8Ir/N38z+l41vY2wghc/vS3
y3//5VLiL2x/Zfv3bbPFtV77j1/+tnmOgfTLny//et2k6PeXX/5y+cMvcl9PwL552MpgR0JtY7C3
6qntEPbDwx54u8m1zuJw0H07szjw40GHc78d9I84IHDQo23nq4PekJ530BvsIj9POGgH+4SDdrBP
OGgH+48PurWPn++bm/CCg771t1cc9Ab7ioN2sE84aAf7hIN2sP/4oMvb5pFtDtgLDvr91l5x0Bvs
Kw7awT7hoB3sEw7awf7jg+6bTyYP7Pkn3a5tvOCkA/YFJ21h+UlbWH7SFvZ40ncT/U86WD9K+3Sw
2ua+XWpk02R2N7ft0+zW99/gWvz4dNsOqMOilgPRv0qrQd38FUPrdSBaNw1lUf8PQ908YUfrb/E7
Vg5siSiL+r8RrVvQY1EZX7c0ikNtv+U+rBzYkskOtVwRB8rVC0Fhx1WuyXl9MGpLcmBMDEr1ugDe
r1ITJrwxJjTPBKhjSvNiS5mwFUCc3F6ZlimbH21hodwOf8uuUMAyVcsUTbl5JhRmw8qbZwJVNe9e
1Vz/nV2HRN1Saj+Sy/u/ELX1mphyJmC1eEmAt6xmihFS267+8jJJqJsjbnUCu2W1JUf2W9zm1Z7X
TDEyN6H2hFrIhJFcXkjtLZEEKGBbrtVKAjM69S1hAuTt22su73tieZn7UT+SI4NM+PBeTYW37MNf
B+gsbYGpFzDG21aKh2WKsW3dI/Y6MFvWquctPLKW+LfQEW2Jfwv9hNYT3v4J+QktCioujL4x2Cio
OFh2edstYQLTt+0tuQ7MyW9vXm6hk9/eEzUOefvhmUDlNlGMVxah92vCBCYJPcpuTm6ZJPSa2DKm
xrdCoaeWqfHeEqPDTGSPAojhbWdy27unFsptH/46wEinb5lgx4Qr5O1IVA0UsCTwvzKj05PAH1re
nulbFjv09+TIWOzQE0cUpil6om9hVnhkiVbGhJElWpkGGyW5DkzVjOpVzZUJ2MjSFMxEjswRZVm7
kTiiMBk4MkeUabCROaJQwDLFyNyP8Za4H1DAMsUIr0OSaIUx78j8WygJSWEL6tvbNXHtWMyrqvEW
lnyrGsPQQVkwg8rMuZJgBpXpGfkIBpVJgUTWoLJwV6GTQWVOnRwEg8pOq1xDx6ywhRFbtl5SB1uZ
jilyEFZqoatYSkROBpbp7yIHwcCy8LFsXZuWWuZ8FRUcDLXwyBSQrbAwICsKyFZYmEgoipwMLJSE
W+TVDCyUBDkIBpZpxfLuLy+0jeU9CmWGWqhqVIldYWEiochBWGGh3Fal8FdYmEio10SDMd5WVQYM
tUzAqgIyA8tsWa2RBTSwTIPVTN8yN7wqIDPUMjVeFZAZWBbi1ETfwkRCHYncQiaoMvB8JmyIrxCw
xLkt8MiUqVqZUKHcqkVlhS3slrVrYh1YD2tTCn+lFnqMs7ZpYNmRtZoIGLsOs2RqqGWS0JTCX2Fh
7ifmwe0tY0anZUE0Mzoti6JZDBlTs5YJ8JZlHiPzb5t6SVZJuMIjyzxGyIT3yAev1ELXrn28xP2I
AVpHLbS8PfEYIRO6mj4Mb1mk0zOPkfm3XZ2GK7VXdnm7UvgGlsltV4uKgWWXt2eBP7u821IOK7eF
2bKuyoBhAoRVZcDAMuvQ35JQGkrCW2IimfsxS6aGCZC3SuGvsJ1VtHoSocMU0MgidMaEkYXSzAcb
r0ldztrmemTQbR5JhF6ZdRiJIwrbKEamGJm+HZl/C5mQ+bdM1Qy1qKySAP2EkWVEmb6dJdOVWiq3
GgRcYSss6yUR+m/atrH2+I+PaExYqYWws7a5wlZ2HW6JIwqP7JYE/oUd2U29eysT2p9Rh+xNvXtP
h5VK2ITse92YuQkjHDuDygzkLfI/BpXZR8W7KypMUahAsqLCcFeFDIPKVKLSdQaV8XVO8BpYJgRF
XtIKi+vGiXAx21gUla7UQttY5CWtsFAjzrqxgWWdGXOC18Cy8LGojmFg2W0oCh8NLDNis25sYOF1
UGOZgYVMUMHBwEImZGoR3jLtS3gBtZEFXGErKziURN9Ci7PtZLPUwhawKi9pZQJUNbFe2PEWGsga
27HMkcEWwyrn6x8zYVuQ97Nu/+//1L611Sev277nnfTb1+IX6JPXHvmlO+kHWBZLxp7nV8AqljTU
sixuVSxpYJmLs22z9Exg6qw+aMnDkTG9Ezu77ZGxVHZ9UGcHahlv24M6O8Ayp2FWe40kMBenKegz
sCyB2R70zoEJLESdZVlDLfNFZlnWwDJfZJZlnw+rsuwLYJNbBnmr/JKhljlk7cFzOggYvGXb5lir
alhaYduU52FZamUWOg1v2ZHNQucKC32R/uDiHI6MabCeuR/MlvXM/WACtm22t5IA14PNacvnH1ni
fhypnRuW/5lVvavr2B/8kMPOQHh2Dzpnh4Wuf39wb3ZYmBOJVwJ2nbPD0tnTB/fmAMu8ptjIball
RzaUKr8L8E4t5O3IojVm2ceDKtuphQI2HrymHZbWYtSOu/IWBmjbQncvCczbH0lmH9ZixoPXtPOW
HtmDhjzAMss+i33myJj1GYkGg01BI9FgMN8Uzz29QtVocNzwlvkhNw2OG1h2ZDfNhRlYpsFuag8z
sMwtv2X5feaR3rSIzlALmaABLgPLmBAKLIYPv5UmoSkL/WVQ4Uh+ZOEdKrPmW7XXojLXI4a7Ha1M
tqKDy6GyLFCMtDpUpmNKNMw6WBaearmwg2XJyxKrOR0ss40lVnM6WCYHpW7WxsEyoS2xY8jBshtW
WsIEeGQR9TpqmaItes1nVYnQ+SqZpoW8vSW3DArYLbkOUCdEsOuOjBmx8p4wAQpY5O0ctcxL2l49
87BMbmvk7Ry1TMBU8TSwnUmCKp4GtrKN9qp4GljYbqaKp4GF1EolbEMK35yvJ7xCUVZUmBGNiXyD
CrVirEZ3qEwfxNCWQ2XVWOmula+w9C8dY1DZrY0g13AADitFjGtQYbCgHjYHy45rOoqGs6xaqN0n
hlooBnqFwsEyOdArFA4WmrAYgTKwUMeoh83AQiVTYtm6g2VaRq9QOFgot/EKhYOFzkyM+DtYFjuW
6Bd2sFBu5X+ulxe2b5UYkDXUUg0WA7IGlm5qiWXrBpZS+5FIAut30JISQy1UjFpS4mDZ5Z0e3Spg
lNoo8DpqWdJjeynWw7JbVnvETYYJTNXUmKxysEzVaPeJg4VMSPQtXGRflQNdedthgJN5zJC3MSDr
eMv8hPqWqBoY6m5pcEctPbLYGOiYAAUscZthF65eoXDUMlXTorjtYBkT1BLoYJkab8qvrrfsynyw
pvyqgWVZtab8qoGFvE2sA3SWWtTMzZFB96PFY0IGFjpLLfFvKbWxwspRy5wlvULhYKGAqUBkBAze
MmUsDSyjVp2GjglMg/VYYeVg2S3rqhAZJjBnSY9bOGqZQdemFgcLmRC7VB0s8xN67PZzsOyW9cwR
hUcWK1UcteyW9SQdDHdS9pgTdtTCy5sF/qwE2eOVNUctlNsk8IfhXs8Cf+bf9tgc4JgABSwL/Nl1
GCr0G8XI1Lget3BMYHKrxy0M7LFN+Mwj3YkjStvKonnTUAsHsdW8aWBhonVk2Q8mtyPxb6GTr55Q
xwQoYJl/yzTYSNQ49G9HpsZZlWRkahxKQpZPYOHeSPIJMEIfaqx6vmKMnlAnt0yN3+IJAgMLF3jf
ErcZyu0t0bfQWVKrqWECXGF1y/IJzG2+ZfkE5n7ID92C/29tCbB7Uw0EBpVpW/WEGlTme8SoT1lR
YflcPaErKvRBFfIbVMYBRfwGlRmxGPMxfIUbtks8O2lg4Ybt2bu58gBu2J4l+RUWTrjM3k0Dy05s
9m4aWCZesyRvYJk2KCPKGAaWJVOKfK8VFiZYZ+18hYVuR5HvZWCZVZhNlgaWBfwltkC7I4NyqxDa
UMsc0KIQ2sAyQ15jHuf5TNjaQS0s9L1qLDt9AbUx5mNgodWt8VC5gaVMUFC6SgLMI2iTjKEWOqA1
poccLLu8syS/MgHmEapK8gaWXd5Zkjew8PKq3XSFhRu2a2wHc0fGTGSNx/YcLLMOVbXzlQlUElQ7
N7DM/WjqlTewjLezdr7Cwg3beuXEHRmkVrnFlVq4uLspCWhgmQ/WYgu0YwLTCVqn42CZ+9E0RLQy
ARqdFpu7HLWQt2oqWqmFl7dlwTkzOu01irElihH2NLcsPmfZuqbeUHNkTI23zL9lqqZn/i2ThB7z
5u46sMvbM/+WHVmPV6UctezIeuLfwsvbX5MB6kkKqDKDPmuQ63Wgo1SxQObryMaz1kUO5cQNtbDo
EnuQv6jd93vgKbXEY2TXYdTEljFVMzSasvIWFgb0CIXhLbQO4yEue56AJe4HzCzpEQrHBNbTrEco
DCx0RLWXxsEyj3GolcQIGK1BHsO950lC4ifApMqIR9YMb+Gc7U2teytvG+PtLcmDHRXj3Cscu4Xr
b9otPC6xVO53ZTu9TZ/V7d8qm7UvW3HqCfcdNdSZQa1nPKcD6pbBM6iQ1tgVb1AhrZHTN6jXMwPo
OwdiAf0LUD1fT9V2dlpjGM7ReqY7ckcNPfZ81OiIc6hnItSd1sjmG9RTBZgdNSb6HeypZOsRNuEs
k1g9ymGYcGrj3oHaSLsb2FPl/gPs1vdiYc8kW4+wyQ07E0QdYKOl9wVMiES2gz0EqGQnaXRqxEvj
3zo1aNQTRK+ocMdn5Jgc6oEVJ/ouI8XkUJmPF/0fDpW5IbHQ0KGyOCrSVg71jMJtn85Mu4Tb6FDZ
aUVDnEM9Y8h2WtX/4WBZJFnCp3OwTLZKbLF3sEy4SuxjdbBn9O2Bt/Gmo4M9438eYGMyw8DCvmbt
7jKwMBem3V0OFkpCtJU4WCgJ0dLrYOF1iLYSB8tUglYyONgzztJBwGKvjoGF5fkS2XwDe8pjPFCb
qVt4ZJHNd9SecZZ2atWt4mDZddACCQfLBCzcL8sEZiCr3GbjJbEjq3KbDSw8slir7XjL1HggWljI
2xihcNRCSUj0LSzK1kzfwiN7jb6tCvtXATsVRR50QqYY2YL1mnmMDLbFyJoRMLi3vUVdx8Ae3Q/6
glkrx7uxv0xyKnW3n1+L4uQX6TvskfQT4VmL4uQLYKP5zsDCaow2HhhYOGimjQcO9qB8SRagxQ7Y
L/y97kfPLtNrzD1tmV5jhrPFDljDBKjcW7QnG1j4CkGL+omDZUzQ6gMHy6rrPeonDpbZY7VvOFjm
R2r1gYNlkXCP5wIcLGRCrD5wsCwr1FU3Ws08TOL1WKXoqD2oshNmoqvGY6iFTMj8SBZb9ljtZZgA
VU2PPmIDCzsXtFHBwUJVk+hbaHS0UcFRC3VCFmBDnZAF2EwnDNWlzHVgTBgxJ+d4ywz6yAJsJmAj
Vs04aiFvEzVeYO9VlieFsEmeFOqE0ROvBkpCEmDTtqPMEWVezYidh07AmNHR6gMDC+fo9RyWgYVG
R89hGVgqYCrYGw0GeRvdo45apsZv0ebpYFkGR9XZ2/q2ElNgCvZWVDhFrhYTg8qu2FvwdUWFzWfy
PFZUyAEFegaVcUD5K4PKZEBux4pamfqeddQVFqY/Zh11hYWaq8g/WGGh5pp1VAPLTqzEVJS5ClBo
S7yB5GCZ5pp1VMMEFjgVtcMYWKa+i1pLDCwLSku8DOd4y2xYSZQijMzLuxcwmBcuCpwMb1mFpyj/
ZWDZLavK6xtYdmR6A8lJAovHqsoFhlrIBFUIVthTzZJ7hWDrY/PXgRnI7YZ5WBY9VuW/DBNY4aiq
jrrCQjUevqdVNZC3IzkydnlrrFp21wHK7cZWBwv9hKowzxwZZILqqAYWMiFzbpktq5l3C29ZpsYZ
b5viMcNb5n60klwHdss0nu+uAzM6Lab5HCx7kbQp/2V4yyShxavHjlomty3m4xwsu2VN7d6GCfDI
VMYwsMwb12r7FzBhI9Tylnk1mvp31LLgVFP/DhbKrdqnzZFBAVM7zAoLu2xm2XiFPTVftLt2PdO3
zFnqib6FXTazvmuYwI6sZ/kEZsu6GvpWaqE33l/jiPbMEWWWt6sQuzIBts32WIdidAJsA5r13edT
m6UpIG8T/xa6zT1WLRvewvRaz/Qts7w9Njg7allmqWfpW2bQZ33XCBjTYNqYb5hAd2tkapy5diPx
bwvkbeLfVuY2a62E4S2cTNdaCQN7nEw/0U+jytOWuXvBXOCKCrVt7IWuKyrsI5GuNajMt1WHjkFl
rm08LO04wDxbDcAYWpmOiYelDa2wohdb/gwqNGF6WNrBsuPSw9IGFq4r0cPSDpaJgR6WdrBMDrTF
2sEyg1uUtl2lFuoYPSztqIVMUDfkSi30kfSwtKMWyq2qb4ZaKGCZqoW81WS3oRYyIZYHOt5CJsit
XamlGiy2qjpqmetV4gURB8uYUNVfuDIBvuxYS+SpDCwTsFoSs8siEb1X7ahlbm2VW2uYwILHWSZb
YeGYrN6rdkxg3ZB12wxlJYFdh6rsxMoEWtRTp5aBZQmlmjmhh+tAh8yqFmDcST9Mg7GEYNUGDAPL
dHp9cEoP1EJYNRsaapmCmMUtA8vEQg8sf125AxMOYnEikmzaVmGoZZLQtK3CwLKb3NSFbWAhb9WF
bWCZs9sewvTDkTGd3jSeYqhlyrc96J0DtWx5S3uIfg+wLF/THsLfA+zh8qKZy1iP+3Xdnjdz+aBz
dljoR84Cz10kdljYc6a3ix0T2C3uDzrnQC1TZT323TtqWU5I+5cdLLM+XSPO5siYj94zFwryVgMl
K7VUbjVQssLCVEvXQImBhZKgSoyBhZKgSoyBZdZnlkwMLOuG6VnIelC8J/yQWYlZqaVTNWoYXWGh
3GrBt9MJTMD0drGDZbwd8Zamg2UCNuLRSwfLIuERj146WKbB9Miwg2Wu43hwHQ+2jKnx8eA6HmDZ
5dUjw4YJML2vBd8GFgbYWvDtYCET1Nm56gRYkRrq7DSwUMAegt+DJDBvf2SOKItN5qTdygTYDXPL
UoRMg90yR5QJmF4DdnLLrMNNnUYrb08t8t2bw0LTtO39lm+15AKJTVAZZ2O1jKOVxZKRtTKoUB9E
gOpQmWGIsNShMptb4r00B8u0gQYOHSy7tho4dLAsLNXAoYNl3pcqqQ4WHllUUg0snQeLkqeBxYtb
t2KMgYV3TO8BO1imvDTH6GBZoKc5RgfLVILmGB0sc5hLVFINLAydSlRSDSwM+UuEpQ4WSkK4SQ6W
SYIGDh0sU4yqpDpYZnVrxI8OlinGGt6XgYUhvyqpBhbKbY0BGAMLe0H0HrCDhbyNuRoHCwUsBg4d
LLNlNXoEHSzTYDU6Vxwsi8g0cOhgmRqvkQZ0sPDyJvoWhvwR3lhqIRNi88XzmdCuiSQwAWvREGOo
LezIWrxPaWArk1vVZA1sgUyIQoaBhTNLerjXwUJq4+U8BwuPLFpMHCy7Dtr86mChJESp18DCLI1K
vQYWrgdTqdfBMqPTslCaRZE9C6WZ3KrC65jA/NseKyocLPMTeuYxQibEigpDLXTtVOE1sDA47VHI
MLDQ8vZYCWRgKRMSxQg7BXvmMTL/tsfzfoYJcG1z32a2LCyU21sSRcLLGwuMHBPg5X3zOqEwW6Z6
tKMWwsYIn4Nl1kEjfA6WSYJG+Bwscz9GjPA5WMZbjfAZ2A5rT9HrbGBhCmhkETpkQhZKMx9sxC4J
xwSmE0YMgThYKLdJhA43Eo7EEYVz4yNTjJC30croeMuSgSOrFMEji8KxoRb6CSocG1jYaqjCsYNl
TLhdPRPgno5bEqHDmFeFY8cE1ox9i92UBhbu6VDhePPIvxeOWb9wNDfHYzXfUBsr8UrPPB1V+mBF
hXGDytEGlbkI8W6z4Sts0Yk10A6V2cZZjl5ZAPMTRcpghYX5iRKDZo4JzAMt0c7sYCFv4z0SB8u8
pNIiaFh5i+vGiYAxs6AJXEMttI2zbrwyASqEIufLwMLuDEWlBpaFj9p/a3gLHQTtv3WwzKfTg58O
Fl6H2HjgYJlOqKpjmCNjTKiZYmS3bJajn0+tkosrbGVe0vZAgD0yaHQ2KbCw0PDOuvHKBKhqarQz
O7llOqFmviI8stgP5qg9yC0elX1wSA+DZpD0B4/0AMtiyfrgkj4PViHqXdoOsCyLW1WCMbDMxWkq
wRjYg1icGFFpD1rywAQmCVov+yXEB1hWh2oP6uwAC3n7oM4OsExBNBU1zJExF6epqGFgWQKzPeid
AxNY6NtuR+V7gGWxb4thfydgh8uLRmWTgBW6/rPsez+7w+ADvMVKi62w0PVvahRcYaHXO8u+BpYp
Bw32fonE03jbk0gYZtt6PCHgqGWKd9ZnDW8h7IMq23kLs239QZXtsNDh64lndmU6RytW3ZExM6En
NB0svA4PXtPOWxhRaBeqo5ZpsB67px0ss5WawHWw7MhmIdXcMhYJj3iy2FHLImG9delgWTpAb106
WMiELJcHmRBbVhy1TG5Hohih5R2ZYmSO7iykGrmFTMhyeUyDjdim544Myq1mQAwTIG/jLStHLdNg
Ix5BcbCscjLUYWKYcPCfT4STI95WcdQyy3u7JplHJgm3eHTKUcvk9rax1cKyWzYLqU8/sltstXJM
gGo8bsPWRf2t5An7smM7nUGFecd4R9Shspsr/2vlAJytiYF8Ryu7t0qFGVqZm6RMmEFlkjULqQaW
Xa8S74kYznYmBSWm/A0sXJY+67MrE9r195df/nL5wy+XP15O6O9Zn11hIbWKx7b9Rd+UQWWsVVfY
igrXLsuXWVFhSKqpLYPKnFrl2w0qy7dLcRlUZmylYgwqu7VKfK2osB1dhc4VFTr1Wu3eDCw7Lq12
N7Cw81Sr3R0sEwOtdnewTA7mQoKVt7QNRgsJVlioY7Ta/QVM0J6DlVrocszGEgML5TbR39CZmwsJ
DLVQwBSMGljIBAWjBhbeMg3IrrBUg2khwQoLJ1S02t1dB8YErXZ3sCx0nh0ghglMwLTa3VHLPHut
dnewzAmfCwkME5hLp9Xuhlo4sKXV7gYWmkitdnewLH+g1e4OFl4HBc/myFjeS6vdHbWH64D7VVTt
vZN+KCKzqpZWu3+RfoBlOl2r3V8Aq2qsYQJTEFrt7qhlYqHV7g72IBYnAlStdnewTBLmGgHDW3aT
tdrdUQt5q4Y2Qy1L12i1u6OW6XStdnewsF/lIfg9XF7Yr/IQ/R5gmfKdjR/myJgZnvP+T4ed8/4v
gI1Us4FlvJ0dGgaWJVe0et1Ry25ZV7OZoZZ5pXOC3sCyysvs0DCw8MjUbLbCwri6q9lshb0yDdYz
94PZsq4eM0MtFLCHnNiuwaAP3RP3Ax7ZUNp9ZcKRWtLIN5R/v+PvbTAwnzvUFbbCwgB7qMF1hYUd
d+NB5xyYwNyb2fxgqGX3QuvHvxTvgVqmz0c89+Bgmbev9eMOlmlIlUy2Yt+3kgmUL/X9r6gwDpYn
ZlDZeWkvskFlx7UB1mZQmc5Vk4ZBZTZdPRoGlQV8atFYUeGGylk+XWGhwM7y6QpLU9oatzKwjLVF
2z8NLJOuohYNA8uCh6KWOAPL1HdRS5yBZUHvrEIYWKZn53irgWVXtySaFhYmi6oQhlrIBFUhDCxk
ghxcAwsFTKVkAwsFTMUNA8vyFLO4scLSEUyt6Xw+bIlOuxUW1lFrjU47A8sErGaKkXkeW7+Op5YJ
2BxvNUxg12GOt66wMDCrakFeYakkKPI3sFASVNwwsCwbWN+iKczAwiPTWmQDy9R4fY8edwPL/ISa
+aEsq9LiGTNHLXOWmrZ/GiawWLe9xmOc9QxDLTuyWc9YYeFDGrOescLSqcjMY2S3bG5bXqmFsUNT
HsHAssC0xbOR7jownRCZCQsLeaue6ZUJMNxr8YyZYwLzwZoWRa3UUknQvngDCyVB++INLFOMfXsP
y/KWWd6uNZ2GWhZK9+ItL0xTdM1mrNRCuZ3blldYKGBd7YcGFvJ2a/C2kgAFLJ7pdZeX2bKuNfSG
CUyD9UzfMid/lqAMtUyNzxKUgYWXN9G3ME3RswgdMkEDJc9nQpIRpSWixL+FD2nMgtbKBPiQxqgx
p7LCwoGtoWneFRYuFR0tOgkMLNMJQw3UBpbdstETfcuuw5zmNdQyDTa0L36FhQmrEQ+NuyNjRmdk
oTQzOiMLpVkUOcduV95SVZN5jCwPdtNmPkMtO7Jb5jGyy3tLUpfQtVMhdut9+FaIhRZSU2YrKqRV
1QGDyuIRXdwVFe4zV3nXoLILtglrjbVF304L3i+FjwaVXS9FjwaV3S6pghUVPnRRNIG/wtJhHU3g
G1imvYuiPAPLNEypEeAYWOYelHgD28Ey92AOma3UwocuSo80wgoLe0iKHr8xsJAJcmYMLPORitJf
BpZphLlm2MBCuZWPtMLChy7mmuEVFhqGkulFyFsN9RpqmXGc24sNLDuyObu2wkIHocpHWmFhf+Es
7xpYyAS9qbPCwtV7cxpshYUx6azDPh9Wj42tsHD13nyedoWFntJ8nnaFLbQO6/06+IJG1atgK7UU
VsvsVljKWzWoGFjmftQN0Rp0ZnnnXJmhllnepuBxhYXZiVaiOXiFhd0OLdFgUN82vQpmqIW8VfrL
wEJJ0KtgKyytGmceIzM6bURqcaUWWt6mhylWWKgTWhacw94M1QUMtSw2nXVYA8vCvaYXewws8xhb
EkrDmHfWYQ21jAmzYGpgGRN6phjZLetqCHw+tWoIXGHp0ttE30Kj0/UK40otFbDEY4Sqpmtfi6GW
6YSu1VgrLGxf7Eku9MgEupag60nGO+n7pB0MJPqDV3qAZZHqXLFsqIWwD3H1gVrWozBUezDUMhdn
PiprYJk6m4/KGli2lmA8uI8H3rIk+XxU1lALefugzg7UMgUxHtTZAZa5OOOhBHOAZa1mc2mx4S0L
gIcmNAwsc82H9kQZWOaLjIdI9cBbCnsM0p4Ge9MohWEC5O3WUBFvUqgUdSCW+WMxV+RQ2R2LCU6H
yjILsUrDobKVBNFb5FDZaUVrkUGFUZ921RrYK2OsHv10sMzmaqmsg2Ws1VJZAws9vBJD7QYWLnvQ
+KKDZR5CiXEaB8subolxGgN7XJ9wYs1SiUUaDpb5MyUWaTjYgwtKlj2UGDj8wt83B8BMU3lQOTvs
MZY4w+RY1GGopTpns2QOFuYcayzqMNTC3Y/apuhg2XXTNkUDC3mr9zQNLOXtgyp7moBt2y7skdH6
WXQAOCYw5aC1hy+AffCYdt7S+tmDy7TDQp1QHzTkAZb5TNp06HjLrI82HTpYFp+qImVgYRavRUrB
wMIjaxE+OFgWn7YYgHGw7Mha9Hk7WBaatehhcrAs2lGhy8Eyj7RFpsLBQiZEpsLBQiY8+HgHncBM
pPYyGmqhiWyZYmTJpRYJEEMtvbyRa3WwTIO16ABwsFBuI9fqYBlv+zXRCUyD9ZjEdtSy4FeFLgfL
gt8eA94OllneHj2jDpZJgt75dLBMbntPNBhTNT0mAx218MgeYuqDYmRqvL9G3+r5UMMEOGHVoxXV
wNIiYnQAOFioE7JQmpnIHgvYHLVQwB6yggcBYz7YiLfcHbVMbke85e5g2eXVwKGBhQ9jjdiVZmDx
U1PebYYNiNqg+QpqNx5sOvfbuMoTHsYyqDDfGvUygwodsKj+O1SmD+SDrny9HvKMJxJ2qmcYVGbK
pRENKru1yi2uqHBsTf7nigpDBj2MZYSAJrFj4YWBpZMqCsxXJkCDq4exHLVMDvQwloNlJqzEZgoD
C3WMZpYMLFQyJRpbHSzTMlpJ6WCZmtFKSgfL9IwexnKwUMCi0crBQiYo3n/+LYuGB0Mt1WDR8GBg
YXFEuyMdLJMEDRc5WBaYz1KOOTImYLOUY2CZb6+HsRwTWC6l1sToHJhA+w6rkq13jhxaS2ABJpZq
fHHkAMtuclW5yFALYaP931ELxSIGRh0sFIvo03ewB7E44ZHWmOx0sFASYvuFg2XZJS2SdLCMt03p
SyNgzMVpJTkylgFpJTky1nfYHvTOfnkL5O2Dn3eAZXLbHhyyHZaOW8WkkROww5GR/hLNBn3hH/JB
kBsPOucACwX4QeccYJmZn5WY+3U7wEImqBJjYFlSbFZiDCzkbRIJw0ClffgkC3RPu0rUhgmHe3HC
+sxKzPNhY3uHu2XM69WORgNLh3himaKBpasfHzTk025Zf3DGdljKhAdnbIeFfa49yzlCSUhCVpi8
0DiQkwRIbaYYmRrXjsYXUKuSidEJTI3PkomBZRpsZIqRHdmINRuOt8xEasrIwbKQR6sfHSxzHUf1
tgyayBGPMzhqmUEfm2xZWJYiHIm+hZWIkelbKLeZI8pUjWaizJHB/UMjq8fA65DpW3gdHmLqg4mE
RxaPMxje0lsWs+8GFj4gcMtKMuzIbuo0Wq0DrHbd4pFHwwRY6bnFI48OlpnIm5rIVybA4YfYfxm7
sr+VqKF7G8u3HSrLCcZbBw6VXbHYVOlQmTFXf83KVxjpxaZKRytLLsV+DYfKbKNUzMoBaBqLVIyB
Zf5BUdXXwDLTWGK9hmMtU4izmLxSC19PKHLpVlgotEUh9AoLdcys+hpYyFs1MxpYKGDxzIGTBGYV
SjyM5WCZ9iqZqmVO0hwQNLxlGnzOBRpYeHkTbQvdjqIQ2lDLmFDVdWhgGRNqbAZ+voBVuXQrtfD1
hKquwxUWvp4wK7IrLOzt3faQed7C8p6C0pVaGDNUVV8MLBSw2DvkBAxeB3UeGmqZBqsquqywMME6
C70rLCyY6cVAx1tmdGah11DL6sez0GtgmS1rmcfI3FttqnS8ZX6CNlU6WMiEWMhmYKFr1+L9FwML
Vc2cC1wlAVreWZZeYSkTEsUI+1tb5jEy/7Zp/GVlAuxla1opYWCh3KrV28DCy5sF/fDyxvsU5jrA
1xmaur0NE5iJjC2ojlq47aBrk4ShlklC1/iLgWXuR48nKsyRwSSgHiI0sPB1hlnkNkxgktCzCJ3l
leZcoKGW+WD9NTnLOC0rCVBukwgdGp05F/h83qroYmAhE7S5x8Ayj7G/RjH2RDHCBoJZ5DZMYAZd
qzSNqoFqXKs0HSxTNbPIbZjAJEGrNB21TG71vqGDhUemtkvDBBaX6X1DRy1kQpSItsU130pElRne
7dtbVNbxoW1Ad1rHZRu9/PPlX69XuLJX2dA76l7brcw8agTGoF5/f/nlL5c//HL54+VE157K2ysq
fLXn3csA9JLiKSAjWbAwoN7NlQNQe6t18476NMkqcpbvsLtowcRP2RaTOs5Cp6MovWqoZRehxFr3
58tBUSuRoZZVoYtaie6wz5MEZW3vsLskwJxHURZhhYUD87PutMI2yNt4RsNIwnFrwPVnvdz///c/
/fMqclxiNuB30bu3fUjYShm09mUk6hnPZkcNm+5Qzzg2B9TtahjUU1tQd9ToPn4BqufrqYHsndbI
VzlaGV/DpDvUM3u8d1ojreRQmWSF8XWoZ7zFndaYaXWoZzJrB9SEr+y0ZCYdsQcflEz+REZhbIf3
zcUtzK5F5O9QmY6MROsLUDd33KDCRH68oGFQoRsSLq5DZXzVLVtlADqjsSnO0Eod57hlhtbDdTgR
OmiduYM9o2jap7nd7Gtkbg0slAKtMzew8MD0uLCDPaPDD0yI3ioHy2Jz+bgGFgY7atkysDQsid4q
BwvlNgpwDvaMMT8cWbQQOFiWvi7RQuBgoSS8ebtAjyxRi1TAol3+BUyIjIKDhZc3elkdLFOMNToT
HCzLgdUoaTlYVtysMbfpYM+4dvstq5liZCnWGu3yjlp4ZN0LGBycqLHq0lHLdELN/Fqmb/UKsKGW
dtkpelq9Gtpll2gwmBOusZPSMAF6zDWa8Q0sdJbaNbm8TNW0xLU7lZ7YdUKLJI1hArRlLZqgHCwL
89QE5WCZqmnRHepgzwToB972xE9gqqYlGgz6CS3RYFQSok7keMsUY1NWadVgUCe02AFsqKU6IWaU
HCyLo1vU+l8Bm1xeKLevCdBbFKFewITMEWX+rd4sNtReWQClx4UdLKQ2ns10sEzf9ngF2MEyfdsT
j/HKosjeEyaw69DjjQvHBBY7aNOHgYXWQY8LG1iob/W4sIGF+rZHwd/AUmqTdCjMg2mBiKMWSkJM
PxlY2CLbozxvYGGeVQtEHCxTNVog4mDZ5VVvlYGFcqveKgMLNdhQwfTpztKINZcvoDZJXcLBnxHl
eUctM5EjKT3BuGxEN76jluVqRlYmYnNwelT5FdQmTIBHlmVEWXptxAIRxwSoajJHlEnCLUtTQH0b
NmfrFf5e3mWsjW06DpVlE3QXVlpPNVHsUb98BIPKfNt428BwAK54kIew0ko7lmI+2hD7/Nai2/iU
tKe2FjnUM/K7t2qEoTSo5YxM7KjRxmZQK6M1KnwG9ZQ922mNNVsvQPV8rWd02E5rmF5D66klWztq
DKw51EMPMu2ruW2J8m+Kt7JH12JtpEGFOcHYGulQWUpwa5G0qMz8xpSOoRU6+qHODSqMTzdN7lBh
6B9GwtHKjK86YAwsHOXVCzivgPViAA+sxGZ0Qy2cEC6xGd3BMr9ZL+A4WJZfU2ONg2UFsxLZQAfL
tEyJ6NTBMne8RFHHwMKgt0RLr4GFGSv1pDtYyIRouHSwLBGmXUgO9oybsDv62oXkYJnBKZltgExI
1Dg0DiUGOJ/PBK1YcrBnPOb9yLRiycGyOpzagBws07dqA3KwTMBqPKTrYCFv4y0dB8v0bY1akYGF
DliNh8sNLBzlrVHUcbDMRG7RtIWFl7dGXsVRy1SNNjc5WCgJUdRxsKx0WjOv+RCYnejwrpliZLdM
3UWOCczythiOdLBMEloMRzpYZnlbDEc6WKYYW6wTdrBMblu0XTpYFkC12CRiYGEA1TK3mdkyNS0Z
amFlq8VKOwMLVzW3LO8BBSza3A21lAnR5u5g4ZHFk2gvgI3qi4NlvFXJ38Aek84n1Hg0xb2VdWk3
rJdtGsGhMjc00moOlYlBWF2Hyo4rqiQOlanaCJ0cKuNARE4Olfl00UZhUGnAH++wGFiYsS3RJuxg
mSEv0SbsYBlrS4QiDpbJgd5UdrDsKmi7toGFC3q1jsDAwtEBPX5sYOHogHI0BhaODpRMz8Aji8eP
HbXMpSsxKO5g4XWIDgIHy66DZqocLONtjZy4gaUBf+TEDSzM4Nf6EuOgUS1HLQvzNKrlYJkarxEz
GNhnjGo5WOYmKUdjYGEDY42YwcHC6xAxg4E91TtwyITGBJiDZQ5YTTywwsrQNVOMkLcxOmCYAB9b
bNH/4mBhMiUmwF4AG28zOViYqIoZVgfLjqxF8trBMlvWYoGVgaXJlJbwFlIbg2WGWjhE0mJRoIOF
1MaoloNlRqclGgyWNltkPRy1UG5jNNbAnmoq2tV4yxQj8xNatLIaailvk5gXdjHqUWZHLTuyXrwG
g46oRrVeQG0WSrNb1uPZAUcts2U9Jm4d7Jnexf06aFTLwTIN1iPL7GChgGUeIzyyJA9I5TZLBLLy
mxZLO97CI4vym4NlR6bF0g6WXYeRuHawvjui/OaoPTBh6znVlsd++S0bHvcrNx7cx9vXikeYcBxR
i/si/QALE++xq8TAwrsxHgLgA7VMnY1oCnPUHmBRz3B0h33h74tQYU5kxMi/g2URxcj8SHj3Mj/y
cEnOFI5i5N8xgQXYI/EjYfJixDYnQy2sRows88iYcLv6aA0y4ZY4fLA8e8syj8zC3WK3rjky2MF0
i1lRBwsvb+jdLcj+Np4AAwoFrAaVJQilZwwqOy+pGYPK1Iy0zIoK7Vk8x+lOizmmsW/JoTL9XWKQ
0cEyYks8m2lgK3NAtErTwMLUjd4TdrCQt9Fj5GBhnSt66B0srHOpWWO9DNCdUQ+9o5YZMfXQO1h4
ZLHB6AWwiaKBCrzInXn+kUWPkWFCgQIWi+gcLNPhRV7SyoRycPNPeKBVQaWBZQJW5c6ssPCWzUKq
gYXUqhXEwMKCVEz0GknosGk4HrwwsNCxrd3L7amZ3j30rwofDW+Zq1hjo4ZjArtl2/Cth2U6ocbY
qaEWRk41VrsZWCoJ0ezuYNmsXVUh1UgCK0PUTDEyH0yvHzsmMGpbvN/uYFnc0GLHsINl1qGpPmuO
jN2yWZ81sJC38W6RYwJz8pvqs4ZayASlAw0sU4wtc5tZuKvXjx1vody+Ro1r8aehFjpLTdWN9cjg
uyRN/TArLNwx09SSbGChgH0k4R4TsJ4pRnbLehKhQye/q2iy8hY2uOqZ4ufL7azPGmqZ29wzRxQe
WabBWCjdY2eN4S10lnpMXTpY5jH2xBGFHmPPEoxQEmJvjWMCs7w9CaVhrl3vCTtqmS0bMR5pYJ8x
XLSZye9JcebeqqvAoDIlrqYCg8oYK6trUJmaUdO/QWVaRqbcoDIOyJIbVKZj1Gi1okIVUzRctMLC
Wv8cLjKwTMXM4SIDy1g7h4sMLJODOVxkYNlVmMNFKyz0ZkrsOXhbYStrBpo58RUWOvclNj06aqEk
yDQaallusShHs8LCN7BnlnmFpXnba+S/VtjC3I4qL9zAsqzHzDKvsHDMbI7rGFh2eevm1zvewhfG
q7Iehlqmb6u60g0szC0mqga25m8PsnrestKmVqqY6wA3ummlioNlRqeq2d0cGZRbVfVWWNiVUNWk
tMJSDaZmdwPLVM3MMhtYdmRN45ErLGwVbcVfB3hkTeORK7U0/6Wq3goLdcKcAlphYZG7qVhoYNkt
a/G0uNMJTI03JVNWaqkkKJmywsLGl5a4djD107IQknmMTX0JKxNgXDbHdQwsq0b3xLWDZeOZt12p
hUfWty0t7jo8I0ez7lWGdYHt22+2d9nWDPVXrM98AWrwdaUVWl3dW4PKrKOu7YoK+Sp3ZkWFAitv
xqDCEFq90QaWMbaoN9rAMmNTSnSmGFhWyCqaHjGwTH0XDcMZWGbIS6y4dExgIXSJFZcGFnqKJZ5D
M7BQH8yMkuEtlAT1KBlYlg0viaqFKmFuwTHUQgGLJfbmyGCldC7XWamluUXlvwwsi8dm/svAsls2
uyxXWHgdZv7LwEJqY3OmkYQrS1lWtees1NJ2yEzfMltWNXy8Ugv92hrvsTjeMg0219UYaplOqJpp
XmHh1rF680yAW8c2x97yFqqaqkGXlQk0HayinoGFR6aZZgPLLq92/zq5ZbdMu38dLGNC07yxYQKk
NvMYmX/bNG9sqGU5cT1Y7njLrEPLXDtmebWk11ELj0ybsQxvIbVZZArlVq0OK7U0raZNhCss7KNp
WXAKmaBU+0otXGbW1Z5jYFnDR9fSUwPL9G1XTnyFhR5j1zywgWW3rGseeIWFKZWuycIVFgZQXQ2G
BpYlVWYnoIGFvE2cJTjC3d98HhCWMXqSXIOqpisnvvIWrnDvr9FgPdFgcI/XyLJ2bGxiXL3bDCVh
ZMlAllTRo9rOT2BGZ2gz1ipgjSUDh2qQKyw06HpU2zAB6tuhhu6VWliIHZosNLBMMQ4tdjCw8Miy
rB0UsHgw1BwZtGUjiXmhdRjqYzW8ZSHJ0CZCA8tCkqFOVgPLnPybOlkNLJPbW+Ixwu6fW6LBoMd4
qz6TDzXYLStnwMu7dTu8b47+t2b5Sk/Mo7IusAghDa2waBwjwQYVJqveNyEwqJDWSFUZVCixejTW
wELvS7teDCzssyzRw+pgWUK4RKODg2XeV4nNyg6WuaAlSgMOliXWSvSwOlhmyvVorINlWkavuxpY
qGm1mcbAwkKGnvhwsFDAEq1IdUIk1hy18MgisWZgoR9eIto1sNBXLBGWOliW96jhJjlYxtsabpKD
ZTqhhpvkYJm+VXHTwB4by+YO1apdqr9lj+q4xP7O3wU/Qi62xI3cm/a1RvWUe7OjRvLOoZ7xng+o
odJXWk8997GjRvnUoFZGa3SzGtRTKnKnNYYHXoDq+VrPRGY7rTG56Wg9c4d31AhOHeoZ+7ujRqed
QS2M1thOY1ChDERk6lDPhA47B6Yvul6uUyHkATa2djlqzxiIA2yitk6ZswNshJCO2jMG4gAbE0oO
9oyBOMImvGWaq0QSzFF7qGqh7c/bXfvYVnN8D6hZdSumzw0qHBEOHeZQD6w4sSEvVnc51DM6bF+L
FprRoEJfP7J2BhU6z9FqZ1Bhi2i0vxhUmGtW8G9gqUcepZdXwHoxgAdWYvzLUHvKPOwyW8I8ONgz
hvcAG+bBwbJUYIm5WAd7xlE6UBtruxws0zIlatIOFiZW4nEAAwtniZRTMLCwZKjJfgcLmRAVHQfL
qg7qw3awZ/yPg4BFBtfBMoNTMtsAmZCocWgcSqSGn8+EGo/uOdgzvt1+ZDV2lzlYlgursdTRwTJ9
W2Opo4NlAlYjNexgIW+jgu5gmb6tETwYWOiA1RinMbCwHKv2bgfLTGSNcVsDCy+v1hsYWOjea72B
g4WSEKlhB3sm6D3ohMxrZuO2NVOM7Ja1eB/BMYFZXnWNO1hmdNQ17mCZ5W0x9+JgmWJs0TXuYJnc
tpoE0WdSS7vctui5NNTCAKplbjOzZS3xb2G7oZrRDRNgu2HL8h5QwKLH3VBLmfCWXAd4ZLFOxlEL
YaNm5mAZb3tiHY51nRNJpXiE5GNdyAq7NCReBpW5oUqrGVR2XuKrQWXHFd3Hhq/QoYkqr0GF/kz0
wjlUZhbkHxi+Mm9GBQdHLDuuogjHUMtkqyjCMbDMP9D7SY4JMKMUXSoOljlJJeoYDvZMwWH3D0qm
upinWGLS1FELj0ymcZWEU1XoAxOiS8VRC69DohThuK3aSQy1cNx25mgMbxkTZjJlhYW2UbPyhgkw
1V5j0tTAQotTFYoYJjCdoC4VRy3zEGqM4L8CNtFgkAmxEs1QC/tDZ47GHBm8DpliZAF/jed3DROu
UBJiysHBMoOuyX4HC3mrVLs5MphWi25pQy3NLUaHioGly/HiBTgHy45MI/gOlh3ZzNGYI4PURgOy
o5a5H3o6yMEyj7Epy2yYwBRjiyW6jlrmMc6sh6GWeYzt5tU4TLU3ZT1WaqHH2JT1WGGh+9GiF84d
GQsiW6LBYHNGSzQYzS3GC3COCUwn9JiLdbDMOvQs5mWKUZstDbXQ6HRV9YzcQibEyhNDLbwOPQul
mQbrWSgNBSwJpWHs0GObneMt07c9yy4yE9lfk16ceVsjt1ASslQgvLyZvoVHFusNnCTAI8v0LWPC
iE3Chlq4vkt7CAzsqe7jPQWkPQQOlrl2Q81wRm5ZuDeSCB0OL44YHXFMYI7oSCJ06NqNGPNw1EK5
jTkPA9tZKD0S/5ZWnmKdjKG2sALBiHUyBpZSm7jNlFoVC80tg5KQ6Vt4HRJ9C/0EeR9b/fxbaz98
RklSa1BZV4Ly7SsqjEdULTSoTNeq0dKgMnWgPssVFV6E2S6/wtJrG5Z8G3H4LlpMCGIfvkNljFVz
sKEVokYKcEWF8Y2uwYoKlxRJx66oMHKUijWojK/bNhbLVyZZ8aSxOy0W3xW1Ba8sgH052hjhqGXG
q6iSZahlxktb9g210HhpY4SBhResKC9hmMBMQlFTnYFll2EOjRhYKLcj+l0MLBSwGFU0sHTBvCpZ
K7UwbCw3r2mge6R1+I4J8JZlehEe2UciCSy9rC37hgkwJK9K2K6SAPXtHMNYYeEM1RzDWGFhV5le
mXS8ZTmfmmkwlgfWc5COWqbBqmIbw1t2Haoyqyss7M+pSoGusLA/p74l+hYyIXHsaH9OpmogtZlr
xwbYW+baMbltqg2tkgC9mhbLwJ5/y5pqQ4Zapmr0wKKjlmVW5wSCoZZZ3jmBYGBZoaElqgaayJZE
u3AyvGlJgmECu7xtQ3RyCyPTpgyNoZbZsqaGbgMLmaCi+Qp7at3NXr/Qu43uljEN1rV6YKW2lt9f
fvnL5Q+/XP54OTEvMavbK2yDBbLYsm+YABMqXaNZK7VQbrUO31AL2ye6RrNWamFytW9ZRcdbqMFm
ddtQy25Zz6JIZnS6+iFXaqkkbIiWt/A6KCG+Untl4V5/jb7tib495q6fsnJvm2L9TGUfVu6dSQjt
26C2uqlFPeM0HFDfLSpcYbYVYx2tFPXmUc8kcncObF6To/VUlWRH3Zwmh3oqUt9RN5/JoZ6y6zvq
9liZRT2jx3bUbXOoQz3VLX5ATeT1jB+2o5YtDeSILQdH//rzpqWav2UN58F32irHNZKvqm+Vrz2c
sJtCbWYGFiaaevQnGFi4rKfHaJWDPXODD7yNvKuBhaPXPYpcBhZmLXr0gxlYaN9HrDntW778uQKm
FzMMLBSwEfkrAwsFTE9bOFgmYCNapg0sFDA9bWFgoYCNmOc1sFDA9HTb7f60xa7BoCT02K/kYNmR
Kah8AWwM2TlYGKtG9GdgTzlMB8XYNg3mYFm2TWGag2UJ0h4ZeANL8wARphlYeMv6bRutMrDwOuiW
fe2keO4tc7BPuGUvgH3YqnNgwhNumaH2GbfMwT7hljnYJ9wyA/uMW2Zgn3HLDOwx2/bH/w9LG6M5
CmVuZHN0cmVhbQplbmRvYmoKNjQgMCBvYmoKMTYwOTAKZW5kb2JqCjYyIDAgb2JqCjw8IC9UeXBl
IC9QYWdlIC9QYXJlbnQgNCAwIFIgL1Jlc291cmNlcyA2NSAwIFIgL0NvbnRlbnRzIDYzIDAgUiAv
TWVkaWFCb3gKWzAgMCA1OTUgODQyXSAvQW5ub3RzIDY2IDAgUiA+PgplbmRvYmoKNjUgMCBvYmoK
PDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA4IDAgUiA+PiAv
RXh0R1N0YXRlIDw8IC9HczEKMjggMCBSID4+IC9Gb250IDw8IC9HMSA5IDAgUiAvRzQgMTIgMCBS
IC9HMyAxMSAwIFIgL0c2IDM2IDAgUiAvRzUgMzUgMCBSID4+Cj4+CmVuZG9iago2NiAwIG9iagpb
IDY3IDAgUiA2OCAwIFIgNjkgMCBSIDcwIDAgUiA3MSAwIFIgNzIgMCBSIDczIDAgUiA3NCAwIFIg
NzUgMCBSIF0KZW5kb2JqCjc3IDAgb2JqCjw8IC9MZW5ndGggNzggMCBSIC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlID4+CnN0cmVhbQp4AbWdXW8kx5FF3/kr+nkB05310d0EDD94YeyzgQH8vKu1vDCkBbT6
/8Bm3CDZNRM3bU2dKgvCjGjyMDo/IiNuRmb+cvnL5ZfL9Hidp8ujza+3x+Xny3pbX98+//unj/+e
r/27rtd2+en9B779wss74afL/1z++m+X/71c+z/r23p5LNPl//52+Wv/0u//49d2+fuvl9//e//z
h18v19fbdX6b2s397eXXHy7L43V6PC73tdv4WLp1y9vrdb31L9xfb/3HunnL+tr6//X1V97W6fOH
fnqnvHxQwsIf+298m/U/+7f43R+/6vb6WKJlPo25vV4fL/mr8xfFF76yJX+k/+avGR+/uXzql2dL
2E/90Qzvv6hgP7+gZum2fdqaDffxi//FR/62MX9+eX5l8xnLh/66uZ8/89FJvb37J3z0ls5/+2e8
94+09N6bXtf77TJf76/TpS2LurmPlh/fv2Ge19cYH/N6e517p7a1j87r8rL5lnafe1duvuX69vro
bH3Ls13d3z7b+qUtd/3Q5wiLL8RIe46wr78SH/njhz6b+/0Lvf2/Z4S15aZR/jnCWh/THf85wrp1
my/EaP/4kc8R9vxC/uYywp4zbDOvPj5A/c3vA+qJ/fzCR7PkCPtsuN/4kT/Gxkdjdn/zPoHzM26m
1Vcf+uvmfv7MhzWDT+3n1fV1Wm/dlX129u3tdXk85Nw+0N98qf/+l/vHz3329+Yr39Pht8frPXzp
y2e73+6v/Td8GhCf9psvRa9//FwfGe/d8fGVzxH3T/r98jnaL592GwNevkFvftmzlT7cy7NFBp+/
d8CHz+m/vjTus/u/+bimBb7pgsL6GIF9Men/xG+bpte31heC+fG6dB8ytdf12udO/2NKB9Iu8U//
1l/69Lj35S9+8nf511wW53Zrr0v3Az/8fPnTl0uLb+jf0v+8Lctlbmt7+fJzX9eC8+XHyx+uvVv/
ePnyj8ufv2hx3YG9e+zEsOvA2plhb5O3doHYN4/dtG335+qLTUe3qTvx3lfbjs5loL3Ajn5bbpfs
6E46rqM7toyfAzraYQ/oaIc9oKMd9p939Nr9TvfX0wk9vVyX+wk9HdgTetpieU9bLO9pi9329MeE
/o3u+KXN7+547s4+gsj3rutO/n2Szut3OKKXdyf/pN6apV7/i1G7dzO2tu+Z+dXWu2+B6x3Z+rha
Wydm68O3wJX11ttsbW1X1AKth2Wuu65/g1ilPWXEwrHVWl/ozeCCTdvaw2PZTGiTb4T5B9a28zkj
YRmMhP9k1kZsZrqsPRg2YjOHZVO33VaLpeP27rvs+j3LTnWKbeC/6HTo2ZhrW+hsWxfeHLZtFsl/
uTaaRnjzsww2Qk9hrbVwJExdS3ONcGU+QSqSmQ5XNsumaTBu2bI7zQNXc0M+YZoHC+/3xIx1gE1d
4j2jy1Y/wBq0dh0MMBZ9TAN/e4VddveNcIWNMPC30NVMPQR3I4FiH4PpwMKPaRSHstBuehusDsza
uSe8rm2hY5y7mGWx/41cTdfGPJbNsrl5D9bYLJunAfaNNcI8cDUQ29WoM7psHcwyFjHOq29bGH7M
N7/yNhYxzjfftg2O27ufDnTcPgZYFn7Mfd/WDjDYCG+DkcCsXa5+0bn+iCbvMvBgC9MTlnNS6WWQ
SsP4dhmk0le2Oiwjx8gm77KcMm6XxY9bqIIto0CUhXbLSLWEXTZwjFe2Oiz3QbDEXM1y9ytvg43Q
q1GcY2wsYlwGjrExD7Ze/Vo2MQ+2jiJG1mXrQLpsLFhaBxk6lNvXgb/FWO9qYLC0Dtw4tTbqbpyo
wjzYOpIpmAS09q09ay3Ly9b1lEVnHYXN0CfcBo3APNg62n6CbTvQb+Gezjpy49DaUdjMoprbKPFn
/vY2WB1g294Gbhzul90GiT9Um2/TYDrAth3ot1AHu80DV8MSqNviU2nYZdqT71saKpx57slDQfQW
cpWhsiVHYoKhspkr7bZS4c6eQltDZYG4JFZDZbGiFNZKndiOlja0KhUGSU0bWhULu6tpQ6tiryyu
bVEW7SYCW8jbFCJgtZY2ggTWiqU7pnO4b4Nl87ZXonssiw/ayCNCaxUpmkZga1gb+US22LS7H2Bw
G6PdI3GqjQAznPaITZeKhQ6sjfzixtv2Isdelpz//pYa5Y992fW9KG69RIra+rakFuD5syhu2qOB
PKlznxuOumcHZkPtwoqh7tJrntTYKDHUidka+9KGuktqfdqqEu3aW5Tq23XX+H3a2mvlbQvsCcKe
1NiTdu26x+E8qRHYOCobA2+DMbBHonjaGjqgs5W1QIsNEofds0A8jW29/tZiWRu0qbtcZ+2eSp2N
tQNvuCvd3WBjJ8NZuyfC3WBjy8FgdyWQG2xsORjsrmqSDTZCBYPdtfhusCEqGSx0iS1OHBrsrp3j
jbWxF2uwuxSKDTaqSQx214b0EzuFqGSwuwouN9jYG3DYjbfNQ1TfE9I8K/Ijgm690PsbTQHuEcSO
maHCfDIqZR2VRfuaE7UF4IZs1G0ZW3c5x2dvaUYYW/csEE9q1PkbW6GupDp/g4VN0K7hyE0bwDQ9
VFaH3cyzPaXCWnuNtXsihWePqc7fWAurX1psPzksVFaiisBgqWCzDsbtnnRs07Za0k2XMTmwxXa/
awQ4EkISNdhda++mEZQ61EbYtUhusJH9O2vhLOt6gsXuCfOf1uaSXhth3pOVbbF+bdgV12ywUV5l
2hbqQCrId9g92cPG2tmPW6hfTsoeapfBtWyS7mGwTL+cJFEYLJsOqpx3XcZczTTyYMzfTqFfOmvh
5A390mAb7LLHwI1DrJISMxJYZKcSd9MIMBCfY6fbYVkMNrfBSGBt2y311rK8YZb+UbsMbuzMkoMr
FjrGOY4UuS6DA0zSrbEWtu16yhI5jzJI5hjnmx9gM1si56jkdF0Gp8MgBoNnhOfYgTHWwnRvfhuM
BHZGeJGsUsctnLyqRXeNwHKHJfaQDRZGjEvsITssmw4qcTfYXVLrM2JcYmvaYGFRzTJyjCz8WEaO
EY5bCcN13MIFfYkiRtO2UE9YRioY0xOWUQwGsaMYjMW3qkU3bQvr/FftQdWR0NgAW0dZJPMJ6yAG
m9hatk6x/VIbAQZL60AHg65mjfsunLWwEbS1VRthZtNhHSSnMxtgEStN3ZVrw+H2WUPRmLsNR3M8
NeT246m9p06gSm4/3ljJ7Q7LYtvWBh3GxmybBj0GsXHawzUCmwot/IHBUl08/IHBQuWjRU7msCyD
1P03DsucYr/F1lvL/EyL4hdnLYsRVL7msExQaZE8HY+droNZxtp2ivIXZy07oDNF8mSw8NCe1rG+
e37COnY4VevY4VStY4dTcx07ARtOsWJ31e09k9JcxyoWBqC5jhksXHW1jhks22/IdaxiYcLftI5V
7K5qpU2XaR0zWNgIoS2aAQY1mlzHqrWwQCfXsYqFJ/BzHatYmOvmOlaxcIDlOlaxE9zf1TpWsTDF
yXWsYr/rguyPmvbndJhCBHTjlkmWseCegY1SEmct7LIoJXFYto0xRR2cwzIxZRrEHnQkKIk2A4w5
xmkQfewqjNyM20H4AVfeOW6ndV3GVt5+5MVjWWI6K42uXQarf3oDWGth9U9/HsZiaZcpja6NAOOE
eRB+TMwnzKPwg/kEbW2acQsV/FlptGnbPdX4z8k7K402WJbvag/SNQJsW6XR1VoYfixKoysW1iot
g/BjYo2gPUjTtruOfj1HgvYgDRbGt9osNNiJSRS6D8tgYZC/DMKPiS06ChP6zt4JEsXhVAUJh1MV
IxxOTYniBGzECBV7iERRsTBaTInCYJmbaYoRKhauYylRGCxbx1KiqFjoD1Jqr1g6EiRRVCyMv1Ki
MFjmvVKiMFiWjqREYbAs9EiJwmDZgpMShcHCfFcxQsVS5UNSe8Vi5cM7Rhjgp0RRrYXTYZJEYbBs
Q2tSjFCxMCdLiaJiYRCaEoXBwukgicJg2eRNiaJiYYCv+KtXW54Qfx1OVfx1OFXx1+HUjL9OwIab
MVi4yy+NpmJhMVHGXwYLIxrFXxU7MaEq46+KhVdKZ/xlsLARpNFULFwes9ShYuHymPFXxcLlMeMv
g2UuPOMvg2XLY8ZfBsvSkYy/DJYNsCx1MFhoreKvioXJU24RGSxrhFge5/6e7PHL4/HUWB6Pp8by
eDxVy+MZWN9fE1seNQr6paEnjILDqRoFh1M1Cg6n5ig4ARuj4HhsBEknYGMjy2Bh2blEKoOlklps
ZDksWxUUJJ2AjSDJYGHSpCDJYWEjxEbWCdjYyDLYCRbFxmE6g4VZuYIkh2UhnYIkg911L+Jza0hB
ksHCAaY6GoOF4bKCJIOFrkYilcNCATBEKodlUbhEKoPddevkZiREHY3BTlD2GcQeVAAMkcpYCyev
RCqHZTL7NAg/4E6p6miMtRMr5lYdjcMyD6Y6GoOdN9fH7rj9SXU0BkvLc0KjMVioKM2D8AOeG1Ed
jbF2Ztmj6mgMFu6RqY7GYKHMrjoag4VFcKqjcVgWLKmOxmBnVhOqs/wOy9Yy1dEYLCw6Vh2NwcLX
clVHcwbWR4ww/FAdjbF2ZkVwWnj7wfsTkv7DqUr6D6dq1T2cmkn/CdgYXMdjlfQfj1XSX7FwKmTS
X7EwrNPOiGlbGIRm0l+thTmZKlOMtTAny6S/WgtzMu2MGGtxdh7piLH2gMoUg6VncqJ61WDh8phJ
f20EOBIy6a9YOHkz6TdYFnpk0m+wMI2OwzOmy2jbKumv1l6Zgp9Jv8GyAF+VKaYR4JaxKlMclsW2
k5J+0whwgI2iD9i2g/ADzrJM+msjHBEtdrX5hGjxcKr663CquutwakaLJ2AjWjweq2jxeKyixYqF
UyGjxYqFLjyjxYqFLjyjRYNlTjGjRYNl2WNGiwbL5OCMFiuWdpm2iAyWaTSqozGzjMa2ihartVCo
ymjRYKF4HXXMrhFg/BV1NA4LF/M4am2wMxsJuUVU23Zm6YjqmI218Gn2jBartRSrLaKKPSL06C+E
nBB6HE5V6HE4VaHH4dQMPU7Axgw7HqvQ43isQo+KPST0qFi4PZShR8XS5TGOWZsug+/vZOhRraWN
EEeojLW0EVSdUq2Fu04q4XXWspUhQ49q7SGhR8VCgTVDD4NlW8YpVFUsFFhTqKpYOMBSqKpYKLBm
6FGx0INl6GGwMP6KI1RmOlBrFXpUa+m41SZZxc5w3EqoMlioKA2iD3gHflanGGtZyJxClcGyUy5Z
nVKxDRa9DMIP6GqyOqVaSyt/VJ1SsTDAz+qUioXXEWd1isGyWRZ5k3M1M0tMszrFWMvKTbM6pWKh
qpTVKRULqwGzOsVg4eSV8lGxu55yfdYuZnVKxcLrR7M6pWLh22RZnWKw7H5b3fJiVl5aS6N9smot
XNB1y4ux9ggt4XHKNsbhVK3mh1OlJRxOTS3hBGwkpsdjtZgfj5WWULFwKuQ2RsXCdCS1hIqFC05u
Yxgsi21TSzBYFtblNobBwk0XaQkGy5Kn1BIqlo4EnXSp2EO0hIo9pOjFYNkASy3BYNmGVmoJBgut
1TaGwbLpkFpCxcIBllpCxdLsXFpCxVJrpSVULJQts+ilYuHqkEUvBstcTZ50MViWPKWWULGwy1JL
qFi4lqWWYLBs8uZJF4Nlkze1BINla5lujDUxGMzJUkuo1tKRoK2MioVrWWoJFQultdQSKhYeYk4t
wWCZT0gtoWLp85KD8IOOBGkJ1Vrob0MRXq5n7EYfT40M8nhqZJDHU5VBnoH1/TWzsK7fGDwvyyNr
EpbPF9To2OolL4YK55dGbLUVvkkfWxjGVvgIZtRpOSpbGcPBOCqLZcK/OCrbFsl5YLqLGas35Jy1
TLXW2zsOy2rK2tSfXXZYtiPQZj9tYR7Slqu3FnZZHwS2EWDlwNofjndtC8ftbdAILOZo8diusxaO
2/vA0cBGuMeKWycv9ODtMWgEWMP7Nugy2Ajxhq9pBFpN9Dbw4iy9meINX2ctm7xTvOHrsKxtp3jD
12BhrDxNgwHG/O00+1nWYJfNfoBh7GAkwEaIE1+my+CRwimeBjZYmJZPsWnusMzfTlGzZ7Bw83EK
nd1gYRQqTc1g4ab51JNRZy2sypjefJxAK17iaRTTCLBtpak5LEvI5jaYDsyNz9MgYmQr7xzyvWmE
xsLmXu1isfAc+zzwYDCDnEO+N40Aj7nMo0AUjoSbn2V0OvTKCdsILMifH4PQjq1l82PQCHDcvg1c
DasmWq6DAcbOWi9tkECxAbaMcl628i6jnBdWEw1cDSwFDK1q7RH58Wd9jqeGuuqobC6EuuqobCpI
VToDO+gvNsOkKhlrr7ARoj7HYOHlaqrPcVg2cVWf47DMzag+x2HZyqD6HIdlbkb1OQ7LokUdMz4B
G/K1w8K2Df3aYZkqrptoDRZWxcqF97D5BBd+OFUuvFLh/YVy4ZUKo/B04QbL1httDKwGywLQdOEV
C4UqvbjirIWNEOclHBY2Qtzm6bBHuHDTtnB5DOnHWAuFqnTh1VpYBpguvGLpAJMLr1j67IxceMXS
Z2diD9J0Gawf0XFNh4W6bdwUcQI2bopwWLbzpOOaDsukH5VYOizcGAiNxmFZqZpuinBY5hh1r5jD
wrYdxB5w5ZUc7Kxli45KLB2WuXGVWDosy8lUYumwLAiVHOywbPJqIHSJ4oQg9HCqgtBKPSIIrVS4
MmQQarDMe2UQWrHw0awMQg2WOcUMQiuWvjisILRi4UBIHaFioVNMHcFgmVNMHcFg2YKTQajBHqEj
GCxN+COiMVjmFHVniMHS2FZBaLUWxrYZhFYsvS5DQajBsi7TOR/TttAnZBBarYWX0mQQWrGwEE7n
fFwjwLaNjUKHZZM3g9DaCDCDVOhh3jFmbRDltuvhVIUelTqzmE76V6XSBecaTtFg4WJ+DXG1YmnJ
XhwxNlg4wzL0MNbC5VGhR8Uu7O0dTQXzZukBU+FwqqbC4VRNhcOpGYVXLJy3GYVXLM0ZNBUMFuYM
2s07HqupULFwVcgo3GBhI8Rxt/V4rKTgioWn6DIKr1jqFKMK0DQCXXAkBVdr4ZVPGYVXLB1gisIr
lobLUQVo2hauDDptb7C0wlJScG0E+khhlOsZa+EAyyi8WgunQ0bhBssy85SCKxZeVZZRuMGyGFSn
7U2XUWsVh1dr4SOFKQVXLHykMKXgioU3GaQUXLGwjial4IqljxQOwg8oq+m0vRlgMDPXaXuDpUWx
2omubUurVwfhB32kcBB+wIvVdNretS3b1tRpe4OFZxt02v4MrF/LYO6gdyWNtbBkTzf3OSxL+nVz
n8OyaFw3952B9V0GI0a9K2mshR5MN/edgJUIWD0YTEmWuOzHWAtjsGUgfcCIcRmEHzAlWUbiB5xl
A/UDpiSrhMA6EmBKoh7rSdQJW8aHU9Vfh1PVXYdTU6yqWLjgpFhVsXDi5paxwTLNMnXbioUTN0vP
KxauDClWVSycuLllXLHQheeWccXSkRBHVteKpeWQEqsqlpZDSqyqWDoSVLdYsdDXZul5xUJrc8u4
YuE1cClWGSxbHnPL2GCh8iGxymBZlpNilcGymoQUqyqWjgRFixULF50UqyoWZjkpVhks29XLukWD
ZWtZilUVC9eyFKsqFo6EFKsqFq5lKVZVLFzLdDWkWXTgWpZilbGW+YQUqyoWrmW6GtI0Ah0JEquq
tXAti7zh1s4473Q8NfKG46mRNxxPVd5gsNCFK28wWDi4lDcYLAw9lDc4LJu4yhscltXfK29wWFao
pbzBYGmXhcrssEwE1Ca3wcKVQeedDBZuDOhKeYdlm4Xa5DZY6GuVNxgsfb01NrkdFsZfUWpqsPS+
n9jkPgPrFzLob5U3GGtpyBznnQwW+gRtchssdOPKGxyWuXHlDQ7L3LjyBodlblx5g8HSLhuFH8yN
K28w1kI3rrzBYKEbV97gsMyNK28wWOjGFTJPZ0jtt8OpCpkPp2rMHk7NkLlioQvPkLliYRlJhswV
C/1BhswVS68fjbpQM7xoI0RhhsHSRohc12GZU5TU7rAsUMqQuXYZ9LUZMlcsFFMyZDZYJqtlyFyx
UFbLkLli4QCT1G5GApTVJLUbLFxwJLUbLBwJOp1lsPR54H4myU1eWAgnqd1Zy2KEDJnrAKM5WRRm
OGvh6fhR7AE3XaIww1gLJ2+GzLVtaRXrKPxgAX6GzNVaeCdghswGy/xthswGyy7nyZDZYNltcJLa
zQCDiamkdoOFdfh60dlh2eTVK0wGC++8Vl2owcKL0FQXarC0ijV2+h2W3bSnF50Nllax9v0Way3z
t6oLNdZCVUl1oQ7LHKPqQg0WxmB60dlgYaajulCHhY0gxa46RtoIsdNvrKVVrIPwA95IorpQYy3M
dFQXarAwvlVdqMOylXcZhB8wWFJdqLEWDrA1DogbLMx01jiWYrAw01F4u5yyG304VdLa4VQNrsOp
Ka1V7CHSWsXCMZvSWsXCaDGlNYNlhXC5G22wLEbI3WiDZZsuuRttsKwQLqW1iqUjIapYbxULF5yU
1ioWVv6ktGawcIBFFatpBKrdKrY93NqU1gyWTYeU1ioWDrCU1ioWhh4prVUstVbSWsXCkZDSWsXC
xTyltYqljaDYtmLh6pC70QbLJm/uRhssnA6D6AN6MFWxOlfDVoeU1mojwJGQ0lrFwtUhpbWKpa9l
x40vrm3ZAEtprVpLVSXt7FUsvFgqpTWDhY2gYriKhfFtSmsVC3WalNYqlk4HSWsVCx1jSmsGC7ts
FH4wx5jSmrGWhc0prRksc4wprVUsHAkprVUsdIwprVUsXHR05Pp4x7hIWjPWQiFwFH6w6ZDSmrEW
Tgft7FUsHWCj8INVUqS0dri1Ka1VLAybU1qrWBg2SwPr69nxJ7lvh1M1DCoVLrvSwCoVrrqpgRks
k4OzvMxgmT9IDaxiYfyVGljFwnw3NbCKhfsNqYFVLJxha3+08t4eOcOWS7t8+fHyh+sVXhS5dpXG
UVng0W81tVS2zR8PvTtbWX3dfdACrJ770d+rNLbCiRCvvBsqjJVbPMfusKy7WjzH7rCsv1o8x+6w
LEJq8RSow8JGiKdAHZYNrzb7RoCPGbdlMBLgarMORgKrz2m3vg19Qtve+zu+DgtHwr2/4+uwcDr0
S3ksllUYqjLWWAsdmCpjDRY+ay353mFZ206xDe2wLL2ZYhvaYdkAm0Kqc1jYCHG3hcNCa2NXwGGZ
T9CugMOy6TCNoi/mGKd4N91ZyzLSKd5Nd1jYZXcf1MAwfHoMVl44buPddNcITPya3nopoMPCcfs2
mGWsEeZ4jt1YC5WUeRQxsukwjyJGFtrN02CWwdfZ4nSSaVt6v+vIMbLJO0cpoLOWjdv+RozHMn87
jxwjHGAjx8j87TxyjMzVzKPUFHbZw6+8uOp4MMCgBxs4RhiILiMPxqxdml8doL9dRo6RTYdl8pO3
MfVnmXycgLGDJRI2wsDfwjsHl8U3Ajx0rv0h48bheZ+Q7+991+V4+f54asj3jspWnJDvHZWdnpF8
fwZ20F8sopF8b6ylexhKTM3oYhGN5HtjbWPLo+R7h2VnfVTC6rDMe6mE1WGhtVHC6rAsElcJ6wnY
qCFxWNi2UcLqsEz+SQ2sTgd49E0u/O2MUwj3w6ly4ZUKnweRC69UeP97unCDZeuNdmBNy0IxJV14
tRYGoNqBddbCRlAKXa2ljRBlgM5auODEBR8G22CM0LeKHRYGoLrgw1gL657ShdcuowNMLrxi6TvJ
cuEVC99JThdesXAzPrcxDJblYzqFcPxI0CkEh2Wqh04hOCzbMdWdeA7LEv7cbzBdxgppdArBWcuE
Kt2J57CwbQexB1x5dQrBWcsWHV3w4bDMjesUgsOynEynEByWrWU6heCwLHnSKYQTsMogzSyD1o7C
D9i2o/CD5WQ6heDalmU5uuDDYVmqp1MIDsuSJ51CcFjYZYPwA0Y1OoXgrGUeTA+/OSxby3QKwWHZ
ANMpBIPFcrAP8mGX6RTC8dbGCvnoew7HC6zHUyM7N9QDsnNDhSGzsnOHZVNB2bnB0tLgqPxxWBYt
Kjs32CtzihJYDRYOBAmsBgujRQmsDst8rQRWh2WRuLJzh2WrrrJzh2UuXHcEOCxL9VRkaLA06Y9D
egYLk35l5wYLL6VRdu6wrMuUnTss8wnKzg0WXv2k7NxgoRCo7NxhYdtG0YvDssmr7NxgYUSj0KNv
cp8QehxOVehRqTBIiI2Bh6HSGKEHoGdgI1Ss1sJRoI0Bh4WNEJn5CdjIzA0WngXO0KO2LXQzGXoY
LHMzGXpULLyzLUOPiqUDLB7ZNF0Gl8cMPaq1Exy3sTFgrIWXsGpjwGAnuDLEYzkGC0PmDD1q28Lp
kKGHwbJIPEOPiqUXM3eia9uJCVUZehxvrUKPip2vf7x8+cflz18uf7n8crm+3nul67X/87v86/R4
jYNo7dZel/X28sPPlz99ufSnkvQt/c8MPSq2HbAx4MYtnA5xP4DBNhjbDqIPegf8IPyAabQ2Blwj
MMeojQGDhXWL2hhwWGjtIPyY2Y6pricy1tJrpGNjwGDhlrw2BgyWFnRHXcIJ2CgtM9iFaWDaGDBY
uJbNsTHgsCy008aAwcLQThsDBgtDO20MGCwM7bQxYLAwyNf1RAYLR4I2BgwWlunoeiKDhT5B1xMZ
LB0Jg/ADRuNLXE90grUD6QPel6Cbv421UKXQzd8OywJRXU/ksGyJ1PVEDsskYV1PZLBw3Ormb4OF
i47GVz8afIK0djhVwa2hsmVXsW2lwhmWu3oGy8Zs7uoZLMtyUlozWJbl5K5excKpkLt6Bssi8ZTW
KhYu5imtVSxMR1JaM1gmUaS0VrFwecxdvYqFz32ltGawcGtT0lrFwieYU1o7HJu7ehULV4aU1ioW
3t6X0lrFQp+Q0lrFwldtclfPYJljTGmtYmkjKLY1WOYYU1ozWDbLdPP3o2Khv1XNrcHC5Ek1tw7L
0mjV3BosTaOvkY7UtoUDLKW1ioVpdEprFQsXHT2qZxoBjoSU1qq18P1OPapnrIXabUprxloWJ6jm
1lnLXI1qbh2WVbantFYbobHENKW1iqWTdxB+wG2ilNaqtTCqSWmtYuF5/pTWDJb525TWDJZtvKS0
ZrCsvD+ltYqFyWlKaxULt451s4OZvPB0YUpr1Vr40oJu/jbWwkPMKa1Va+HGS0prBstOZKS0VrFw
4yWltYqFKYnEqn4z7wli1eFUiVWGeoBYVanQH6RYZbDM2BSrDJatuilWGSyU1rQRa7BMDk6xqmJh
JJ5iVcXC5CnFqoqFezkpVhksHGDaiDVYlp2nWGWw0FptxBosnA6KFiuWDjCVoFcsTJ5SrKpYaG2K
VRV7iFhVsTAxTbGqYmkjqA6sYuHqkGKVwbLpoAPiD4Nl0yHFKoNlq0OKVQbLVocUqyqWjoRB9AFX
hxSrqrX0hTaJVRULd6NTrDJY1mUpVlUsvM4xxSqD3cyy6+vUCyPz319/+O1Vkut7leTaqyQv89vH
wx7z5xMcu4p7n9S5X3/sqHv04Q21335sqLu0xie1vxt0BnXQrnvEiqeta7/117XAZkj85krZJzUq
VQx115r2pN4H7cpsffSKfGMrHANxfayh7jq092yBt8F43aMsPal62sQYuysO22CbH7G7ThhusPEG
ibN2j0yxxQ7ado+8tsFGwOSs3VNNscHGRdUOu0cb32BXP3F3HaHYYvs5EmftnmVyg72dMxLi/mtn
LZxlUY/vsGwJa/GIksFuZ1kcYLhevmc5fx566Arb/NZfCZAgduiLWo7KIuge2lhb9wyzZwvESzfO
1j0zeEMd2LpnAj+pkf87W/eMsQ01pq8ZA3tCjyc1sn9HZbuG7RpOwRjLtvdaG8wDdnGVytectXt8
zbNppQg67J7FbIONoxkOu2fp3WLDhZkuY3OhKbY1WNhl8aCWsRYmZ+3u2xYe12rxoJaxlt56olXH
tC1zii0qZZ21cCSMXA2bDhIanbXML0podFjWCHpQy2GZkj1NA8fIPNg0+1V3YW58mgfTAWLjHQPX
trAR1sFaxmaZ9EtnLXPj023QCHDcjuIvOMsGjhHLooPpABth4G8nFixNsbFjRgIsp5ikU9TVYZuT
/GZV6RknzFc/eaG1UltNI2yrND4k0fjze/KoZ7LaZdFexvSeR21k0T1bEU9ql0UtdU+8v6E+LBVK
Yl0WdbZS6qBdmSi4euquAxXPdu16hW2BPQHpk9plUUfd5cie1J5JOuqud9s21Lun7ll5ntT+2qC1
dU/ev6H6MTDtWXyf1MhPrbF7PPkW6+csFJzjHWlr7Z7AZmPt5K2linMXW521u9adjbVdbHXYXQc/
tthB2+7JSjbYvshYa+G47dGdxe4JbDbWDrwXVZwfV28tcwmtb3rbRmD+K654tFg4y3oYZrEsOpj6
Db0Ou51lf/l/7/ZOIQplbmRzdHJlYW0KZW5kb2JqCjc4IDAgb2JqCjkyODcKZW5kb2JqCjc2IDAg
b2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNCAwIFIgL1Jlc291cmNlcyA3OSAwIFIgL0NvbnRl
bnRzIDc3IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTUgODQyXSAvQW5ub3RzIDgwIDAgUiA+PgplbmRv
YmoKNzkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0Nz
MSA4IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczEKMjggMCBSID4+IC9Gb250IDw8IC9HMSA5IDAg
UiAvRzQgMTIgMCBSIC9HMyAxMSAwIFIgL0c2IDM2IDAgUiA+PiA+PgplbmRvYmoKODAgMCBvYmoK
WyA4MSAwIFIgODIgMCBSIDgzIDAgUiBdCmVuZG9iago4NSAwIG9iago8PCAvTGVuZ3RoIDg2IDAg
UiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1nV2Ps7lxps/7V+h4gXTEr6e7ASMH
MYIF9szIC+R4dzaThWEv4J3/DyyrKIlU8+bMK15SBgO7O+5bpWKxvqv4j9NfTv84xc/3FE+fIb0f
n6e/n8pR3r9uP//t+nMK75/lOIfT3y5/8P0XbxeEv53+z+k//tvp/57O9Z/yVU6fOZ7+33+e/qP+
6p//+2/h9F+/nf75z/U/f/ntdH4/zukrhkP9t7fffjnlz/f4+Xn6+Djez9moy1/v53LUX5T6/6i0
lFzew2e+/8VXibc/+dsF4+2KYfT9Wj/vK/n/yf9mn3z9oPxeQrRPvpKS3j9yfmsf3T7Jf3NHTPuj
+tn3KNfPnr71W+eE/NZ3n10/acK9/cL4Uom7UdsYd/3gP/jS37hZhaGxtzJv/I7zt77n+DeY64df
vvXwXdW3Pr4+38ejPr4+3j/qCfSzvv3mzT7IPvryN7evffv5gaN+O76O96+c+1HbL8LHcfnk9jnj
b0zurn90O5LLL+oRtM+ejnoQ9X7U/Uu3k+4f3Q72RtzwOVe2XI7657+zXazrEV15eTtq/0a/961H
fvsBNDZcqXnkW5eS3z8P57jfkzf7xfnrynEDvv+Nffb1j26H3X9xd9pVzGZp7xe7lFTVnquUxvJS
4nvVLP1e3/2i0lKpa39yO4P+i41v/XZTKbcPulziDnv7xZUtl7N+8CtfD/vKzH7Yt4++3qTrL25X
q3/Ud5SHJPwtV3thiv6mwnM6v+d60fu9vv+NnfX1j25nffnF7XbNJ9xPvZ91jl/Ntl3Yl6vJ+7qp
lPpBb/e/McG7/M3trG8//+FRD3brSv/tqPvnXI72Bnv9+caVRuuNb1du/8E3vh7SlZf9qC8fPRiu
Tsz19K/0qjNZfO9Bm3d1ls4f9S4N9jqdj/fxqMef7aAvf9AN1xXhJ7/2hXsGe67OzJXfb+lc7WHV
MP1W3//GTvr6R7ej7r+4+87DN1V260rx9bMr7vWzv1H3t7fhF8aVi1heEX7yO1+Oun5H420/6P65
12NVv2kH1A/aUW736uesVvgq9Qr3Kx2+8vvxMZjqt/vf2Elf/ub2pW8/N17/jnj7vWr+VPhK71/n
wVTbL0Iatff9b+ycr390PedKXEO58vvRL93sxuWDTHTviRt+cWXL5aD/6DsPpmsw1Vde9pO+/46N
u9/4UL+kn1E/6CvMY9+6nuxnimaz2pesP59v98q4e/cLI6X9RZfu2893Bz18VaW56wnFL4s6brfq
q1rp+OlxyFW8r7+6qDan5vp3t0O4If3c9367HNWFavXxV07MH3XlzUWF62++Cjwu1/rK0H7a376m
81gwww9qsKr109tJXZSZx2UmVjG6EfwoVWd+nmJ4L/VGhfof8a2Ga7+egv9T/5f/qKR+VG1uAd0/
tf/aYsZU3eX3z2rUf/n76V9/nIL9D+r/pP7nUdVCDvnz7cffa9BnSD9+Pf3pfD6Hfzn9+Ovp3354
5LkB+6FhI4MtC2oTgz2qB6OYkCHsl4YdeFsNlJ/FcM7Hx6dHsuNBW1xeD/rNDggcdMxfp3bQFel5
B11hJ/l5wkEr2CcctIJ9wkEr2N8/6JLqpaxB1AsOOlcT+4KDrrCvOGgF+4SDVrBPOGgF+/sHnauy
jjWCesFBl6+PVxx0hX3FQSvYJxy0gn3CQSvY3z/o+PlR9bk4ZlfdQHF/lM/LMVek5ynuCvuKY1aw
TzhmBfuEY1awv3/MoSa1cw2fxEFTC23B0gsUd4V9xUEr2CcctIJ9wkEr2N8/6I9qoI98fsVJl3Mq
Lzhpg33BSUtYftISlp+0hB1P+upy/2TA9BbSJWBKNRo75fPnxY2uYdiOG/12CcMG1BopKNRHvOgZ
9ahBmEL9Xw+ENTPqR9Go/4lQP88aldFaS5KSAwXRWquuCjWcEWo4L1jAGBvOi/NinA31TigmnBlr
Q1jI7C+Mt3HBhA8Gm17DhKSZQAUsL5hwMCaUBRMg7BG0gD1idmbtFWoyVMrt/2ZMOBYaHFJbvUxJ
LZTblbaFt2yhbqnc1hyJYkJg1jF8LY6MabB4XlyHR/yaWW5jTdYqJpyZGo9hYSE/0XWIK337xWBX
+paZyJgWTGCXN+aFBmOqJmZ9HeLg4f6hYysEbKXG4XUo2padoYCt1DhTjHGlb5lirHUwfXmhTvhc
8BbK7deCWmbQ49filjENVuvhmrdMJ6SgLy+0ZSksjA7TCSkuvBomCSkuBIzdslRTH9KWsVuW8kss
byr6OsQh3Du/x1p7bf/+TJr3qn7LJa9QTrFKcSiXvEK65RXS8CE/rdQ7arJ66Ywad27ygFovskDd
UukdtXYfvwJV8/Wh+vZ8WmbUFAf+54Z70zlw1GshUMOOBe6oH/VWCNQzk4HPxWntKPNO61dVuoLW
tOPadNRgLrmAPe8EECPsQgp2rPoAG7QYnHe04wBrJkIxYcdODrDmkitYyATznQVsYPIVvIFkVohn
SK03kAhYdsfCh2bCeceqD0dWW+Ulbwer3jqEHjFlQzLbVEP1Ib2O9dQUuULducOdVkuRC1To5VmK
XKBu3eBO66fdtJmvW1eio5qzL1C3bsSAqvlKs8O1nVASy7znYCGE4sFwIX7a+eo8CME07nxglAmW
shGwYcc+DNS6BzpTm3ZU4wDr9mGGhXmr4PZBwO74SgO1liJXvN0xkgNsnVeRsDve/QBrSRBFLdOJ
YaEU6ZGttCLkreVWBBMilAQbLRGw9PJailzABnjL3HEW1wFqMEuRC2qhcYgrfbvj3PXrEBf6NsBU
Y1z4M+yWxaTlFgpY9JB/loS4E5oOvPU+8Rn2zAQsWjuFEDBY2olFq3Eqt+7mCyYw9yO+Rt/Glb5l
fkJcuKFQ39bWSSkJ9DqsFONORmG4DpbLFnK7FZl12LTyb9nlTQvFCHmbFo5oYpbXk86Kt8xPSHXc
UB4Z02ApL9T4Tug/SEJtF1fUwiJfWihGeHlTTX0oaqmAHYuIl7nNydMqQo0zxZg+FkyAkvAaxZhW
ipHZsmS9GuryMmcp17ZoCcs8xlxnyyUs02C5Ttop2MAkIS8i9MCaKrJV49SRQVirxilYJmC2iUDC
QgFbROhQg+VDW4fMjE5eaTAKu9BgzPLmRSgNE5d5pcF2suPd8uavhaph1qHUKQIlt4FRW6wtTN0y
psHKwmPMTIMVr0EJy8sErMSF3LLrUKwNV/GWKcY6Ny5hYZqiLqORsFCDFS91z0cWWABVrLtX8RYe
mbXhKlgoYB8LnQBv2Ye2ZZS3Xpufjwzmb0tFlLxlPlhZhdJM1RyrHOOvGy0a3TocC8UIC4bHKsfI
UpfHQjFCy3vU6XIlCc/viIrVf/Iy8tARtePo9eK3pUcF6hM6ogTqEzqiBOpWsN45YHZCoG5ph45q
qVGFuqMhB9SqIAXqlvx21M9qewTqVi57QK2mR6HuOHgd1bxRhboTRQ2omq+J0ep1dEXsTnGrE+t1
dAW7oxxHWM2ErSh9gDWdq6iFTDBnVMHu2LOBWuu6VLCQWuuZVbBMHQSL0hUspNbq6Ap2xwUZeGud
lwp2J5s/wK7UF2RCHWpW1IbBI3+8K6xvmvJrUSdn23aD3uC8c4k7qpvzGXVLlQ+odtdm1LQT+HVU
a1lRqDviMKDasc20brX3dlR3EgTqjrYZUO36zqhb8U5HtSqBQD2z06p71BTqVkN+p9XmiwStULKs
oVOgbrl0nVYr9ArUrVaVjmpRpEA97zg0A6q+sVAGgiXtBLFbHngnNpz1nYVSYBo23fbH3DRsZHfW
Yj2BuhXwdhZYcUCgpp1cQkcNd+agtx5vNb8MsO4kXfVWh4U8qBsHB+nqsGdmEELdFdWF9nmwdwpx
gIVHZqm12xUbYHcydsORWWpNwG5FOAOspdYEbGB3LFhXoILdKXQP1HrwOMvt1txLh422qOT51HpX
oIDdakAeqLUar4CFOjzalI6A3Uq3j9QuJGGn+jTA2jy+oHbM2P10h/sIq6mlvE2jpzzohJ3ocaB2
ZR12wrwB9s6vH6hlijHm0aUZYFnA5B2XQhJgxBRXRoep8ehpRaHB4JGtbNkQ6+5ch5Utg5fXOtzF
kdFbduffDwIGb9nnGIx02MjCsbiwZVSD1f2pL+BtWphIaB2SDbIKSYCOaLqLR/qRbc2rdcWYViaS
Xd4UX2IdfIWC4C2UW287VbDMtfMVCgKWCphtwhGwMIBKtrJGwFK5tekBAXtmRid5lvnpRietbBnL
fKRD8xZah2SdFIq3zDqkuwRYVzVpYEI8/Y9TPP3VHqGL10fo3v787/Yel6/L+Pc//9xLB+nDdXt6
L/boSgux6g/19Yl/r68aXNHqjHP9oGQf9Icmf34/4fIZ8ck7V5O1zFXuf4d96FAFtdYyJ2AfSsAq
2KY1vlP70JKNGTbbNISg9qEhCwXbJPs7tQ/1XwlYm4ZQ1A6SvSFg+RK5faf2ocymoNamzwS1UMCy
VylnuaWSYEMWgtqH7IdgwiXEmnj7iIMiYIuW2/RIGKBgFwL2SCeegLVOPMXbR+JMAfuhj+yhPL+C
bf76dGSPRBcC9pLX+w5Lr4PXVMV1eCQ1IKi1IQtxZA8ljmfYstK3jyQ3Fay2ZaPJ31CM5RK0fD+y
h8pTglqb3VC8ZQJWLkHLd2rPkLfWUK2oZQJWLgm4iVqmE8oluphgmQYrlwTcd9ixc2FHwC7lme+w
9JZdSusTLDwymzRRkgDl1naSKVhI7SUMmJjwSOQmLu+l6jPBQmo/NRPi0Ira0h4/szCpkf02PMJ2
iU0uvTE9KHrI+lyX1PX8S7l4+98XMaVHmKxgdcAJUw/Fdk1USftOLWxkOWz9vYJlTDgWKbOHPNKZ
t8ciZfZQgKZgF7x9JDYRsFGnI2GR9bCto+rIdrpT+3XwZngF+4hyEEyw8UkFC3mb9JFRSbDGC0Et
PDJvvLj1c3QNBqtKweI+AQtvWbB0pIB9KKaeJSFYOlLBMknwplcFO1ifP3RvBLWWjhSwVBIsHalg
d7pT++UN5jAI2AB7ZcxhELCUCRZOClhKreUwBWx+xC0XkmClNQELDXqw0pqATYzaaFGqgB2dsY3r
EM2gC1iowbxNRMEy9yPaGnEBuzUY029ZtHBSwEJJiGbQFSwz6PGu4XEwOo/k2ebrEM2gK2pZ5cMf
mRCwD6WdBbW2mEvAwhqYPVcqYWGHhO3fFdRuTcEPcmvBr4ClTLC5EAXLPMZoqVEFy0yk7/t6Aax1
nwhY2qxsFS4BC2NeXyMmYKkGs651AftQslFc3q+xDbprMOjfRgulBbW0n8NCaQX7SIppZoK/tCFg
IROSvSQnYKFO8O4TAbu1mKtrMF96JmCh3CYr8wlY6Iimu6GALrfpkWy2kATrsxfUwpmbtLBllAkL
W0aPzBZuKCYMbvO1M+Kn/NxkBb50Lt4Gkazpr/2w3wYhTq59xvXt4tvsCew0T9aneeNFuMEGFlEn
m5cSsCO17Wr+TD5XcKMx+cKNfj2gbUvWWXkju8OOAveYZFh58ioZ2TYJvUAy2mdMkvFQcUaw2Eqg
N150yUgsH+B75gTs+AQLkYwLkyfJgM5Utq0kN7K7ZODm2IoaLxs4Bh4PmuinNNC//jgN1Q7rwheo
kaG66ZhpHQ9ug1a3HDPq1h7hbuxtCafgAHR4PJ8naGVhq7UBClpHnbPBV1fAM62w19bV7ow6DhU+
pB9bVjsGt5wtneU/PNNyXj5jvmQsGPT3EdS5Mf3YMuczi2EcFKwmrqhlmZzgaYGZ2q21PP36+vsI
glpYmgk2PSJgH+o3mC1lsLW0AhZWgcPisj3U6SeodR9nPrIIr4MH2jPsWFwmdv2iHKY3j6DH55OW
t7Prdh1qX3+iWMCOHVkPKcp4Nj/9oiiLx5xPV5SXz5gVJYs5W4J+lgx4maMtdLuxuPtOEaYOPeU9
UwtvXbTd6IpaFmf5A8gCFu6laLlpwQRm2+JrjJAtAJK8hcUPr7MKJjzSSzfr37jw92AKJtoqpBdI
guemBROgJFi/l6IW8tbLt4JaeMu+NLWRCZi/RSGYABVjaqZiUuNQg7UksuAtsw7+coZgAvQgWxJZ
UMsEzEcYBbUwtPYRRgELY+tk3cACFgbXydYrC1h6HWyoQ8BSufUkspAEWFOxBzkUtcz98FlDBQvl
dmF0YO+Fzxoqalmmyd/5ULAsWG3ZXSEJUIN5/lXAsgaUtDA6MBGQbeGW4i27DvlsNZWZCdCWtbTr
DAt1QvbK5QwL1bhPEr6ACYvYIbMB92z9r4Lah+bHZv82e+vnzNuH5nAU7IJa5ojmhXWgcuvVupkJ
W5tve14se4+mgGXWIS8SWNAHy4tME2wC9ldJlNxCJniPpuAtsw7F9pQIaqGAlYW+hasI/VWSF1Br
s3kCFnaU+mMnCnaIy0jO8ZJne3bOsdiDzTeye84R5ot99k/AwlSmz/4J2K03CLsqK3eFv84EmL4r
tllEUBtZBqDYBlwBS3l7l2LqTIC5oHJnJjpsZvMMxVv5rxqyw8IUfLFt2y/grbc/CmofWT0w+yE+
8ieopYrXW/kFtSyc9Nk8QS2U2+MuxdQlAfZ7+dMvglp4HY7KViVgGFarmsT8kOPO2++8hbesVcEr
tm+H77CBRanB1wwLWBabhGze/gwLW0tbFVzAsnyF7wNW1DJ9G7w5XlDL+k1acX2GhdcheAFCwLLr
0Irrz4f1AoSAZdYh2EC4kgR4ZB6bCGoHuX2onBzsSbCU2uKu6PrRf3hq3037jOk9irEHdKOxKXqP
/JUXve4LO1ZjMA9vhh2pJbHEhcmT/oVqPdqA+I3srtZHA/+QZER7AvcmGe5NP10yLp8xSQZ0H6L3
Pf7+Ee4InC0/ubF4EDhmOaM94KNgh3wDErh2dk8XOK97XJn8DIHzrsqrKmpq2fTSM1WRLzlWvGZR
YRszu/LieZLh6TgB+yzJWNk+VgKIXge5kt0l4xkt0jVZ8PxXjWxq5RsqLgDUKz2jwjKuZ0pmVFjF
9RbpGRWell9mgcqy9F69nFFhO7e3SM+okVUZvWtzRh1bpDeMUAvfrrDD5WL5geBN/TMsjbO8BiRg
2WxzW/8hYAc3eIe3Pg82w8JR/3B3F/qRwcx/8JzhTC0s5bf1HwKWeTnh7pJ1JoxtwTtH5us/Zmqh
Nx3cMs6woze9Ra1FWzMsHMYIPqElYGHuxWebBSyLYaM3HsywkLctHJxh9zutfUovf7Wd1o0X9sNT
/dH2GZP7MQabG3IWva3hyovuj8Jb0XaWzLBQkUVbgXm7FZ1a2NvRokBBLZtvaJ3WAhY6zRVRMSFA
2JV3xzKS/gaNOrIhMtmRW++WmHkLvZB4WE/SDAs7qKJPEc2wsK0hetQnYCFv7yzlcMuY49iCPUEt
c8XinUnr1GaWRPbHYoQkwCVk/liMgKWNsL4oS/CWHVmyvcuCWtjlkzwDKaiFR+Z5yBkW1qv8VRfB
BGjL0l0c1eWW7oPxMtjMBNhLl3yN4gwLFWPy1OAMCw26v+oijgw6S/78ioCFDSht88XMBGjQ21YR
AQtvmW9dmmHpkfkw6AwLS4zJmyRmWDjt1lZSCFiWtMorNc6OLNtrm0JuE8utZNuLLGChTsg+pTnz
FrbL1AW7L6HWty4JalnskL1JYoaF/m1eWQcot94SLahljmi+y7J1EwkVY/YmCUEtC6DyIuUMFWNr
4BbUDh2rGwFU9inNGTaxcC9/6gAKus15YXSgD5ZX1oFlMIu9CCkUIwz3irfQzUcGBawEnVQJTBKK
b8MV1LKQpCycfMrbRWYJ2rLWYC2YwFRNWVkHpm/LXQ2m61voLBWf4RdMYIF/8Rl+Acucpda3PcPS
TmjfmjfDQh+sfOjLC1eztL7tmdqHXvkTndA+3jPDUlXjvW4zbB5MJOmL8VdQbvq8V6RgkvxYlDfg
UMfhcz5XbnRqYdXkuCtAdNjI2h+PuwLEAMtU2XGXYhpgmfU57sxEh6W89Ta0+cigzjn8pQ4BO9yL
DdfxuDMTnQmwF++4SzF12AQFrIzlkg4LL2/rrqgm6HtzPIv7gr3VmWZY6N60nvsZFire4GsdZli4
dzn4WocZFt6y4FHqDAvlti20m2Hh3uXWtPF8WB/0mmFHW7mhE4IPes2w9Mh80GuGHZ8reahXubVr
HG17ZHRL6T88s1R/+Yx5mw4LqEJ9hq2rhu6d0y52nza+srjDjrly4jxdmDwpSrhdN3rUeiV7UOus
k8WThLUB6VuT5yhvG7fDzfuMmpmtcOU7o8IeNLfCMyptHbXkq0CFtt3yLAKV8dVfAplRYaOvK8gZ
FV4DL9XPqNAAe1v2jApXUQTXNDMsHOkPnm2bYanp8XjnBbDm4M2wUA5cb9VVdt/0Fmx39trGjPrQ
m+lzFsCTV09H9dmYGRVywCsQMyqULS9AzKiQr54KmlEhra63ZtTIaofeNTujPqXlverEb0EZLNC3
lvcZlvZP18g8pxmW6kOf4pph4U1ovekzLOxXCZ4XnWFpeN4uwyQJ8DK0deAztbBMED7MKMywcLIm
eI1PwLK27LZlfIalvPXk8Ay73ZbdJqs/28Rya63wH54a6/n09pXoHj0FNhHUVpfPsNCvi2fbZj/D
wuxSe6ZzhoXV2ejdhzMs7D5s888zLGzBbA9fzrCw8a5tAZ9hYZ0++ia/GRbanuhNjTMslQRvW5lh
YeU7eqw7w8KG0ei96QKWhaXxzlJ2VQOfomhbwGdqYV0n3tmegVo4P+39JTO1sCUoegVxhqUC5v0l
M2xgxa3WRC5gmYAlj3hnWKhv25uPMyx8Xrbt1Z5h4S7S5BW+GRZ6eG2vtoBlpbi2V1vAsh6I1u09
w8LrkHzEaIaFZU4rlymvBibG2zuHM7XQOqQ7X78rRqoTfIh8phbWdVKN0RVvqSQs3GYYQiTfHzQz
AY4OtwXYAnaIo0iJ5BKbTMEqjIFb2/eV7F4igf0lbRP2DAvPLvtKqRk2s0RTa/sWsKz5LPt79DMs
zDS1tu8ZlvLWOzZmWEqtF9QFLKvq5Dv/ucstZULLus63jLUEtf7s5zPBZztnWNpIfWcmOm9h6jl7
xWimFsYm2WfpZ1jYtlLO1jQ5w8JZo7Zg+/mwvmZOwDLXsXjj3QwLu2GKN97NsLAbprQC13R5KexC
jVMm+P43wQTWnFCyThNTJnh/9vOp9dnOGRZ2PZTDps5mWOgslbvsSleM0Oi0/uyZWlhKLwvrAEP1
4guwZ2phTF3ugoiBt8y1K3dJmwGWZVcOb1MQTGB+wnG2WXoBy2aNWlu2gB1ik42OpWNhdKBiPHwo
aKYWarAjap1AYe9yQV3AKBO8x3dmwljtO7/H0/Xf3345/fQJlpMFov9UJ3NtTipXg+Gl8HQKpx+/
nv50Pm8F7h3VSBeoYSea6qgWnjwf1bJNAnWrk63Tas86KNSdmKejWleuQt0pI3ZU655VqDs5+AFV
83XrVnRUm/9XtDLJsgS8Qt3Jj3Zag01iCtitmskAa3P6AnbLqo+w+npRWEvYCGrTThVioLaug1Ww
8NoGm4UR1G6lBgdqrTKpYCETrO9Mwe5Y9YHalfLaccQGWGu2UdTuNLyPsFrRULk131lQu7XEdaDW
UiAKljHBdyAq2J1QslPr7fMCFvLWH25XsDvzzgO15t8pWGZ0fe+fgt3ZhjFQa00QCnYngBhgbSpK
wTIfwZ9CV7DMSYiWbVWw8MjsyRAFuxNFDbyt3riEZd5HtJY2Qe1W9D9Qu/BqtrpsOmyyCFVQO04C
bQQi3lagYJmJTEH7YGGwZY8X5dIlfkon6w3Ktfn5WyvxVvw0oJqREKg7RqKj2tZKhbqTIe6oNgej
UHfObUBd0Lrj2XRUj3Rmvm61BXVU2zojOLAV7Q6oJriC1h1d01GD394Zdmt5xwAbTI8L2B2rM8Da
ki8Fu2MeBtikT2xrb8UIa1ZnZsJW1WyA9Zhkht3KOY+wiyODvF1pxB23ZqDWuncEb7eM2Qi7YALT
if4SmqB2awpioPbDHFwhCZC3Vu1VsEyFh4VepHJr+XxFLWNCi6AEb5kGi9YtqahlatwXsivYwa35
aSesC1j0CEowgemEaO8SK2rZLYs2eKhg4ZFlLWBbnagDb1eKkd2yaPVTxQTmKUXPAc2SAPWtb05X
1EK5XSnGnXhvODLrTlfUQt5a/VTBwltmmx8ULLxlX9roUEmwph1BLYT1pncBC/3bZHskFCwTMN+c
rmCZLfOmdwXLFKO9cyeZsJMD6rcsebVwVjXQT0jWXSOYAMOy5Kn8mdqtudmBCZ7Kn2G3NvkOsPZU
lGDCVqvGCLsIz5ktS/YAhqKW6dtU2SphmdFJnrabj4xqsNe4zWnlNsPLu1DjW9nALmDZdi4pSWCK
0XeRK1gmYNn6VQTs1jTQwIRF9mPr1ccB1vpVFLXM/cgrfctuWfZ6xnzLoHXI3vYhYCETVm7zTh1u
ODIvnQpq2eXNdcGMlARI7cq/hbfM+gOF3G51j3feepu3gmVyW+yRBgXLBMz7sRUsU4xlEfhvtdAP
vI2LI2OSUFaOKIt0irV5K94yt9nXcCtYyARr8xawW/OMw5EtHNGtecYB1hqnFbU7XbgDrLm3tSfs
e/mN3QbPNc+oeac9odPqHJhRt7ZqdFRX4QKVXQVvfplRt5q2Oq3uMM+oMHRyx1agsmKpF89nVJhH
CGdTMQKWqZhgfdgKlvkHwYvngloW5gU3NgKWKcRgwz8vYIKt5VSwzD/wbWEKFjLBm6Rn3sKgNNje
PEEtvLrBtm4L2K3+sq5ngg3/KFimFH0JmYCFTlJw534+MlqN9mSKgIU6YWEaqCTYxhbBW5io8m3I
CpY5CNGGfxQsu7y+eEvBMn3bujifLgm+eEtRy3LiMVp6QlDLvC9fvKVgYSHWa5CCWnbL/FFoRS1k
gievBbXwyGzCX1ELb5knrwW1LISO3rEmYOHlXelbyATvOZ2phU1F/syyOjIotwtnHLrNyd7AUdQy
t7n1nM683Roi6e6Hr7JS1DL3I/kkjaCWOaLJczQCFvJ2pRiZLUu2Flrxll3e5MkUwQR2HXxDlqIW
HtkiQQFz4smb8Z/PBHvxUjGBBei+IUvBMn2bbOe0goUC5nM/M2+3evwHVePlNwHL/ITsk4szLMxV
ZVvVqnjLblleeYxMwHwnlKB2a4K1H1ld66+ZwASsld/mI6M1SG+GE7CQWlsmonjLXLvs5TdBLdO3
2ceJZliob7Pt+BNMgDFvXniMW3voB7n1voSZCVsPyYywCyYwNV5ek2gtq0Qruw6tqjfzFnb/FG8g
ELCQtz4+IWCZa1cWihE2bBV7AEndMqYT/LlaBcvc5mJb7RQs5O2q+AQlYVF9GneUbLShF++7FQIG
b5n3JcywsJ+mVER5ZCzcK18LZ4kJ2GHL/ZWAsTzY4Q2yM29h4O+bgBS1TBL83VcFyxzRYxVKM0f0
WIXSTMAOW+6vmABVTU3V2Bv030ry0A+1di2FCuWg3gWFyrxQSwQqVGZwTHkJVOiDWk+VQmUJYdOI
CpVZm2ALORUsE1hf0yNgod8RLNgVsNAND3EhB8wsBGupUtRC3pqOUbBQEixdp2CZOvAXhQUs7H3y
N7EULEvSeN1YwG5tqOkBmb/RK2ChogkWlSpYZsT8FV0FC6/DSoMxL8nrxoJa2EEQ7W1LAQvTdV43
VrDMPEbrllewTCfE+BKdEK1b/gXULhQjlQRbKvQCaq39R8HurEDqqsaHTBUslARrqFGwTCdE63xR
sCxoiCvHjlneaG9nKGqZiYw2DapgGbVe4FWwzER6gVfBMjXuBV4Fy+K8ZH2RCpYdWbK+SAELO7Z8
bFPA0uK5FRwULGSCvaIqYGFYmmw6ScFCaq3Aq2CZ5U3W+aJgWWSaLF0nYKHHmFaKEVJrY/KKWjaJ
kK0lUMBmOEu1cu2YicyWrhPUwsbbbA3jCpaZyGyvRShYZnSy1TEULLu82RrGFSyT27xy7Viqpg7l
aGohE1aKEV4H23aieAuZYJ0vr4DV1ELL63VjQe3Ws7/dG88rfQtv2cIR3XqJY6B25YhCubWGGsFb
eGT+6I+AhSayrNQ4O7KyUuPM6BR7bEAxgV3esojQ4bBaSQtbBplgAzovYMJC31IBW9Rdth6A7pe3
rPQtSwYW23CqeAuvw6KgA3dclNdkRIs1MComsOyHV7kFLNyKdqxqOkyNH9b+I6iFrVX+jI6CZa6d
bYazF9G+lUxhJO2ukkBlKRW/YjMqLJbZ/jbBAYhqey0FKqzAuT8zcwD2alm3h6KVRU6tZCqIZdfL
x5gVtUzRBnvZRMEykQ02OKFgWRYweMFB8JZlAYNtoVDUwiPzgoOglrkzwcPHGRaOJwWbKFNMgNdh
pRMhExZK8RnrfhUTWBYwrNQiZMJKL0JqPSCbBQw6tq1kKmBZLBJtcEIdGeOtj9oqWKZvY/3+ilpo
dlvJVPCWeUlxpcGYYxsXGgx6X3GlwaAk2EzsCyTBZrQULDM60QYnBCzMpkR7x0HAQn3rM7EKlmmw
aKtkFCzjbfLIab5lcP+Tb7oV1MIeqGSjCAqWVV1abXNmArQOyRaWC2phN7OvpFWwTIP5SloFy/zb
VBYhCVPjPmWqqGW3LNnbmAqWpZTSIjKFqiYtfDCYTUkrHwyqGs+1z7cM6oRsb9GII4vMq/EpUwEL
xzyyd2fMTIBPPWVvvBWw7MiyzQwIJsCWwPrwl4aFR+bZa8EE5izlVbgHeWtTpoq3LDjNNqOlYFk+
wZe8KljIW68WiiODkrDSYJDa10SRxbszBBMYta2sJ2CZn1C88VbAMj+hlfUELPMTirdRCFjmJxRv
oxCwzE/wKVN1y+CR2Zy8gIV+gk+ZCljoNhfbu6dgWVKleNuaODKWFi51n7aiFrZgl1VwCnWCLRBR
vGX61qdMFSwzkYd3w4kjYyaylfUELFQ1FjrUcv/3+hsj1hYpK1R2GTz/M9MKMyp+w2ZUGOX4BROo
TGS9vj2jwmvrg5AClfWreVVvRoVl6FbVE7BMxQRbWa8klukCX06sYNn18uXECpa5y8GblJ7PW/dm
BCyboGnltxl2XMBwfo+n67+//XL66X0M/clnY8lxHelOp3D68evpT+fzVuTbUW3dh0CNO/5dR7VX
SATqVlZ0QK03Q6BCWs25E6hbTdidVrM7z0e1vSQCdcvudFqtPqBQd2xkR7XGKoGadvTYgLq4BTvW
rKPawkxB69ajJh012MJMBbsT5YywWrbG19Q39EsINW5Q1O4EpgO1Fu8q2B1vcYC1vg8FyxRXsIyd
gt2JIAdqbf2RgoW8tU3CAnarMXSg1txbAbtVjB1gzb8VsFu7ywZYy+IrWKa+fGm5gIVM8OFzBcvU
YrQsvoAddcL5ZP884nwMvcImEbX0/y04g4N71tesUHd40Wm1tmaFuqMZOqq1HyvUHTXWUS1/K1Bh
CsjCKIXKaLUwSqGy4nGwVVgCFo7sBXu7UMDC4nEzkvNF2PIWuxgEK8wramF05kZSULvjLQ3UWhil
qGX3NtQISsHCkqFHZ4LaCIM+9/Bn3gaWDw2HvmUB3jL38QW1ENaGjgVvof4KK7UIqbWhY0Uty9g0
kz7zFjLB3yF5AbXW3q1gdzzcrhOitXcr2B0Pd4RdqHFmyqK1dytqmY8QbS++goUCZoV5BQuptcK8
gmVq3PfJKFh2eaPtkxGwcN42WnpcwNLL69kPoROYdYi2/llRywy6N0cq2J1ERb+8yepPCpapmmTt
3QIWlmOTrQoUsFAS/MEQAbuVCx14a2sTFOxO1DvAeuZ2llvofiRb/CKopby1mT0BG6CA2eIXBcuK
Gsk6lgQsDEnSQjFuJS8HSVj5YMyWpZUPxo7MF78o3rIAKtsEq4Jl+jYvfLCxYPTTGdx+ZN5zqahl
Bj2vXLvwL6cffz3924/TX36+njVQuwpO2S3LK9eOyW1euXaQtzb3oo6M+bd5kVk7Mx+sUiqphbma
vIh5oWLMi5QdzNVkay1SRwZVjb3LrGChgK08Ruba2cZySS1kwtfCT2D61t8hUbxlOsHfIRGwsAmm
LBxR+HpwWalxJmDFVmErJkBYG/4RsDBrVxZqHGbtysoRZfq2LCJ06I2Xlb6FR+b1vTl2gEbHO0SF
JEDr4CdWx0O/VbTgAglPCgtUpmiso/eYUeGEsKeEZ1TIAc+nCFTGATeOApXZBTdiApXR6o2B4rhg
H6c3BipYZnJDMP39fCZ4RUvAspxl8LSHgGWqK3hFS8Ay/R1szEHwFuYsg7d9CGohE7wTTsBCASvm
0wlYFue1QpmAhZfXgwYBC3m7UossXedbRBRvWfgYbP7rFbBWcBC8ZQLWCmUClh2ZbxFR1DIB8y0i
AhYGDf6eg4CFWcBog7EKFjIhW4ZVHBnLAkZPMwtYKGArxQgFbOUssssbV94iS9dFW06ijgwyYeGF
brU09+SiLydR1EIBs/kvBQuZsHBEaY3IBmMFtXBjQFp4jDAqTfaAtKCW1ohsY4CCZaFDWilGVuBN
K8XIHNFWf3u6Ykwrxci8mrTyGJnRSZ72EEyAsAuPERZz0spjZKomeWPCzASYAPOdJ+KWQa8m+WCG
oJbFDsmWQQlqoarJtgxKwbJOw7zQtzABllcROqTW62/zkcEsYKu/CVh2ebO3VglYpsGybW1SksCM
Tk2Ia1imE7JtzlTUMkc029YmAQvrGNleABOw9PL6GImQBBY7ZO/FF7BMg2Vvxhew7DoUb8YXsEzA
bFm3PDImYK1QJqhlzlKraM2wsMpdvN9hhoVqvKz0LWu89Q0t6pax61C830EwAQrYQo3D0YHijWAz
tbQI6YWyGRb6YGWhGGFcVha1Fwq7iHmhGi8r147pBN95oq4D1LeWXauJlRcUIQUqo9XTSjPqM4qQ
M+ozipAClXHAL4JAZU6d3wOBymhtRUgByxJgrQgpYJlZaEVIAQuZ4CGOgH1GEVLAMiPWipAClqmu
VoScYZ9ShJxhof4OnlISsOySBbfkApal64Jti1QKHB7Zh4WPM7WJNe0F71ycYaEHGjwpPsPC3E8b
wJ9hIbVtWk/AsrRHDBaaC1imwaInxQUsU+PRXiNW1DI1Hr2NQlDLLm/0oRQBy/Rt9KUcApZFpXGh
wWDaI3q1UFALmeArhQQslATPtQtYlvaInmsXsPCWeVJcwELerhxGllz0R+XV5YVya9t5nw+bfBGD
4C0TsOQjNAKWHVkbAhSwTMCSN0nPsNBEJk8pzbDQRCZPKQlYZiJbEVLAQt56rl3AMhPpLySo6wDl
thKqbhmuFi7cD3gdPqwyIHjLekn8UXkFy6xDmy0U1DIBa7OFApbxNnuufYbdWofVO1/8UXnFW8gE
X+M2UwujyOxbLWdYGEX6o/KKCcxEZt9QM1MLXTt/VF5RCwXMHjlWsEyDtZLpzAT4EK8/E6GohXLr
tU1BLeStD10LWGYi/fX3FzDBh66fTm0bqxOwLPvRxuoELJOEsgqlmTfuDy+oI2MCVnzQYWYCTLfb
qmalE2C7ZVmpGpawKj7oMDMBVgdKLb0pJkCjU7xtbaYWFyG1D4aLkBqWFiEXMe9TqoWCt0zV+AsJ
z7+8x8K1gz1QxyrmZYrx8MHgmbfwOhyLmBeu3T9WqUsWOxy+CF0wgfHWp0zrJpXvBV4Wm3oxQ6Ay
79ZrGQKVFcu8lCFQGV8rYH2pa+YrM7reqyVQ2Wl5q9aMCk1u25s6w8KBnxDMLAhYdl7Bu/AFLDuw
4MpAwLKbEFwZzLAwzgtex5hhoaINXscQsCzOC8VmtAQsU7TBvSQBCwXMCw4CFgqYt2rNsHAyJ/je
VAHLYpE2tylgmZcUfCvLDAvlNvrzCDMs3N4Wg5ZbmGtvBd6ZWphrbwVeAcsSCa0SK2DZLYs+0C5g
mYWMK1XDNFj0LVgztZHphOhbWWZYeh28uX+GhX5C25s6w8JtFNGbTQUs8xbj58L9gEfmA+2CWihg
C9cOpkKTh4+CWnZ5W8lUwDLetpLpDJtY00eqDwwq9wNeh5RsRmumFlqH5J0vMyx86Tmt9C2UhJW+
hZLgeTXBBOaNJ3+OZoaF3ngbB51hoRpPC48Rpj2SD1MJapk3nnzqScBCAVvpWyhgXzZRJqhlzlL2
8SQBy5jQ1rEKWEjtKuZlTn5exLzQv82r4JRFOvk1GiwvNBisuuSVBmPvmuaVqmFVl+wrOYTcwiPz
gXYBy3RC9t69GRZWXfJCg9Gqi4+IC2pZH3pZxbxMJ5RFMpAWc7wyMDMBWt4SrbYpYCET/ElAAcus
Q8kvSWEXX4H0fGq9yU7AssC/+FttAhYOr3p3hoBljmgbsBSwLOYtq5gXCtjKWWLUHr5USDCBqfHD
24RnWBjuHf6o6Qy79Ypjb7I7fLBMwEImeDecgGVpimMR88I0he3klfoWyq3NxNZe9O8lU6gSjFaB
yjSCN5cJVKYVPdQTqEwKvOQgUNlpeclUoDIOeF5NoDIOtJlYActubfBHQgQsk63gE2UzLEx7tALv
DAudr+DddQIWHplrRAHL0h5t1FbAssvQRm0FLBQw766bYWkR0n06AcvivLBQijBoCD76NVNL5daj
0hkWFiGDt8EJWCi3Pmo7w8IkTfClGQKWZapaJVbAslsWg8V5ApbZnLhSNUyDRXe+ZmrHgZ/zezxd
/33kfe7+CLrR/nHtXkuncPrx6+lP5/N5Z06no1pKUKDGnQiio1oXjEDder5vQK0OnkCFtNosr0Dd
ekKo02qjvM9HtUlegbr1Rnun1XKMAjXuVPcG1HqFBepWnrWjWiAtULeCvY5qcbRC3QlIBtSFvO44
jR01WHSuiN3RjQOsdR4rWCYFwTqPFSxTMN4VqGB38uIDE6zGq2B3DMQIq+/CVrP4AGsvHb2AWlvg
pmChJFirjoLd8ZwHJqx04nDLzif75xGz2/NA1t79WV+5/ZargDMURrRCZb6jpVpfgFrFQaBCr9zy
twqVOY7WsiRQYeuH1Z8EKnTJ7dk+hco8cjcPCpYxNoTFee1YnX67gs0cK2p3FO4Aa+UnBbujwgZY
c/QV7I4KG2GrZhSwcIl/sJyCgmWFyGB6XMBGKAlWQBewUM34G0IKlmlaT1UIWFjLCAtNAxvtfH2X
oBYqMM8pKFh2HaIV0AUs5G08L1QNk9toBXRBLZRbbxoXsGHHb+6qxlMVAjYyfRutTiRgt5ITA7UL
DRZ34rIRVlNLeWtN44IJYfBEN5789ld5FCxT49GyogqWtVLET20d6HWwrKigNu7Ee4Mk2OMTAhZ2
csaaC1SwcJNKOi8MOrsO/tiPYgLzGJMV0AUsPDJfiCVgoYB507iAhUYnrRQj07fJOosEtVBuky1j
ULCsXJSs5VLBssubLMeqYJkGS7YFW8EyfZus5VLBQklYqHHo2iUrbglq4VxVWsW8zGP0N4QUtczJ
z5ZpFbCwqcbXdylYdh38DSEFy6xDtqq/goW8tRZ3BcskIdub8goWUmsFLQELrUNe6VuWpvCniQS1
0ERm20khYCkTbCmFgKXUfmj3A4bS/jSRoJYywepaChbK7UrfQlVjDxoIas8sOC2LwB9Kgu8wE9RC
SShWMBOwUBKKFcwULJOEYrOWAhZOL5ZVRpTFDmXlNjPrUKxgppjAIvRiTxMJWNjGVxaJVnodFmkK
GJd5n79gwhnydqHGt0qnPfAv1iorqKUPgNmspYCF3nixSSUFy1y7Yks/FCwLSXx8QMBCATtshFPB
Qp1gWryOEHyr70JiPTSdUbfaVLrUen1XoMLzMk9coLKg33o5FSrzPGxZtUJlOXzPWc4c2GpX66fl
TtKMCiXL76xAZbcg2KIexVgKa2kEQS2TglaMnmHhwpNWjBawLPMTbIW/YAJd42bviCtYlv4KNl2o
YJlHF6wTXcEyLRO8kWY+MnjJWtVYwMLrYJ2WigkUdqFrmevVitEzE+Bq3uChroCFTHAfaYalkmBz
SuLIYJQXbf+PgIW8bTXumQkU1p4nF9RSJniFaKYWlsn85StBLZQE37emYNmGh2jrugUsjPJ8jZuC
3RkX6D5N9IzlfGQwJe4vXylqmdGJXsoR1LL8avSYVMBCaj0mFbBMMcY6bKwEjF5ee3BAHRkLRqLN
KT0fNq38W+Z++MtXilrm3ybb9aFgmWuXbKpKwTL/NtlkkoJlktAq8uI6sFvWKvIClumE5K1KApZd
3mRLkBRvWeanlc5naqFOaKXzGRbGZa10LmAhb1fJBHjLFtkEmANMi3QC9BPSSt8ynZBtYF7JLbtl
2WsuQhKYTshecxGwrJ6VbVuRYgKT25xeYnl9O5yilkWRvh1OwUImrBxReGSrxC0z6K10PgsYrBDl
RUIYwy7kFt4yeydCSQLzwSqkhoXUesfpfGTQluWVvmXOUln5t0xuW+l8ZgL0E/z5LyUJkAkr/5ZJ
gj//pahlGsyf/1KwzP3w578ULGTCyr+FR+al81nAIux28FalGRb6YMVblZ4Pu1KMrKrlk6v1jblv
lU1YkHfOClQmB56oEahMDLzlVqCyq+D2RqAyM+YNtzMqvAi22OBzRj0zs+A1SIHKnHtfsqWIZcfl
S7YULFPfyd5yELC0Q9pWKwlYGub5uLU4MnZtk2suAcvurT8erZjAQhF/PFrB0ljXcjQzE2D7gK8s
F7Aw1e4ryxUsuw4thJ6ZACdSsj0qpqhlAtbaxAW1TNVkbxMXsJC3tmBdMYFtCsj2TJeCZbesPruq
YZl18JXlilqmwbLPzzz/yHyQW8CyvG32oFTAwiPzoFTAMgHzleXqyCCstzILahkTWiuzgIVeuLcy
C1imE1ors4BlAla83jDD0oB/pWqYTiirsIGp8bKKGyC1Xt+deQtdu+L13RkWRg7F6w0zLAwdivfT
zLBwQ0/xieunwx6eVpth4ZEdPsgtYJmqObxNR8Ayxeib0JUaZ5bX0xPVs/menoA8MF9coDKN4Hmf
p6N68CRQWQnD1YFAZfbGloArvjIZcB0jaGXevS8BV8QyIQi+QEZQy9yZ4F1wM+zzt8d+XTOXT90e
K1DhRlaLohTqzvH1RYFWMFSoO7eto9r2WIH6hO2xz0e1XmmButVu2TlgmSWBuuUnDKg1iFSoO1qs
o1pUplB3tNiAuqCVSZalbhWtO2nmTqu/KS9gt5YUDbDWmCFg4T0IYcHaHY9moNbWAypq2YkFWz6g
YHdcmoFaeyFUwe6EeiOs5u1WAnuAtQ4KQe1WT8IAa1klBcuMQrCFoQoW3jJzlwTs1vzfwAQLnhQs
04r+SruAHXUCXaH7VevH3zx9+HyfW7MZFSacXcwE6o489LZ5t5EClZXhbMRS8BV2qLiNnGmF1Qxb
RKFoZSkVy1sq1J370E/L4wcBC5NgHj8IWHhe/tqPgt0xZgMTrPKiYCFvbe+Pgt2xkQO19o6FgmWl
vVDDMgkLQz5LhypqWeuPTy0q2B0bOfB2pWeYTmymd1Y0WzZyoNYaKRQToNwuFBg0YsHyloJa+Aat
zwEKWLi13p/lUbBMbuNC1cDnpKL1SQtqYfI22mOxChYywVY6Klh2eaOlWRUsuw7RxrkVLKTWGpoV
LLMOPrCnYHciqK5qogcPQoPtRKcDrA1IK2qZQY+eUBDUsiNLtiTx+dQme29AwTK5TTUFqmCha5es
JK2oZe5tqrUcCQuZYK/cCGojlATbrqVgmQ+WPMU6yy20ZcneGxDUwpXlqb7QpmAptdamoqiFkrAI
9mDtONkuBkUti3d9zauC3Unfdn2bFj4YbbSz564VtYwJ2WaDFSwzkdlmJxQsE7BsxS0Fy44s20od
BcsKhzlp6wDHBvJCMW6VSLrc5qoTJRNYXJZtJEPxFkqCbTNUsMzoZGvDVrDwOqwydsxj9G5DQS3s
fvEROAELRz2821DBMq8mexZ7Nuj0OqzUOJOEslDjMB9aFo4oDE6LvaeljozdsrLQt1BufQTuBdTa
Sh0Fy7J2vuZVwULe2j5WBQvl1gZJFCyzvMV23wjYsVtl45GbYr1QApZeB2u5VLBsC1JZRejM/Siv
idB9H6tiAlPjx8oRhdfB5KvW9r4VC+mybrtjMyoM+/2KCVQmBrYkUNAKN3V7ADnTCl1bT7YLVCZa
1haoOMA8UC8WzrTSVxZtLbEgduv17O7cB4/HBLWMB76LVFALsx7BM0oztVB9BzfkApal2v1hTMUE
prmCPXOkYOGRebFwZsLWQ+qDgHmnwwwLV0UGD5wELMuJt2LhDEuZ4IZ8hoVaMbghF7AsMo/1GWol
YNALj57Bn6nd6gvtAhbdP5hhoU6INuSgbhm7vNETVYJaZsl8F6miluURWg1yphb6M9FrkAIWUus1
yBkW3rJoqygUb2GdzIY9FCxT460GOTMhsHgsegZfwEJVs3DBYEk+LTQY1AnJtimLI6MFraD90AgL
Wl4sFEcGYb3dYYaFrp3vyxS8pQUtWzMvYLe6j7vRSStVwy5v8naHmbdQ3yZvd5hhYUdg8hyNgGWK
MXkyRcBC3trAmpAEGJelhQ8G5TavVA3L1vmbkIIJUDFmzzKLI2MBVF5oMGjQsz0m9gImeFVPMIGZ
yGzvbyhqmSOaF4oRRjr+JqSiFjKhsvUVTPAuCnFkzBvPnmUWsPDIFhoMqvFsG9bVkTGP0TdQKljG
BF8VqWCZ0fFVkQqWGZ0SrDoiJIH5YMU7WQUsk9uycu1YK0lZKUZmy3w1ieAtrZh6X4LgLZQE70uY
YTO8Dov0WmT6tizSazDS8ecQxZHBSKd40/zMW+iD+bIPQS2MdHwrh4CF1B4LHwxKwmE7ywW10GM8
fDR2PjJY3z1sFbqglsIuFCOE9SCy+grfa5CsrueDsU9H9TbWGTUzHW4bkL5mVChc9uCCQmWq1t5b
UKiMA54AExxgqdDgCTABC8sjXoQUsMz5auP3Apb5Hf7O4vNPrNU2Z2qh3xHcS5phRx1zfo+n67+/
/XL66QaYPtpd39Ap52tP3DP3syhUvp9Fou7EJZ0DdT+LRN0R4Y5ahwcUKtxLUVX5C1Cr1ZWoO81K
nQM1GShRd9zmAfXzFag1kJa07mjHTmuNoxXqVodGRzVVrmCfuDWh9p5+fHdCsDdaiZ5RYdW/Bjsv
QK2xjkKFSfc6tKdQYbW7NkIpVDjMXJ0Qibpzd3uRpDZCKVQ6ylyXGipYOMpsPoiChfcg1EyNhGWZ
8VADkpfAaqGF/niogymK2jNkQs3USFjm54faKC1h2W0IdYJEwrJMTahtBBIWMqE6ogoWlgeCW96n
24VQ91UramGhKCw0GNS29ijzC6iNdTeahGUBaqwJIAm744Z342DLGCQsk9tYd6NJ2B33fqC27oqU
sEwnxLr3RcKy8kD0aETcMlYesEYoSS0L0+NKMUK5Xbl1kNqFXwdNZPxcyC2zDrEuiJNHBm9ZHa1T
sNA6WH+VgoVqPC0UI3Tw02sUY3qNYkyvUYxpoRhpf9VKMTJ9mzz583TFaG1bUm6ZqkkrR5S5zamO
EylqYXt3qvNEChaO29qjzBKWWYdUX1dTsDCJm1aOKJTbRYAOm3pz7ciXTGBGJ9fWeQnL5DZHfWTQ
8trTT5JaJmD29JOEZcW9XLeCKVhoInPtyJewbJQ5ewJb6FvmfuT6HoukFh7ZStWwSMeWMUhqmU7I
tSNfwkIm1F4KCbuTG+8BVK5vOUpYFpeVRTIQXoey0GAw8C+v0WDWDaZ4m1gN2bYmKFjYbmgPB0tY
JmClFjUlLBSwOmwpYZkGK7WdQsKyCL3UflYJy1SNPVSlYOH6rrLSYMxtLrVRQ1ELN3Zbk5mEZQa9
rBQjOzJ7UUpSy2zZUbfUSFjGBOtdk7DwlhkPalX2W38V1eJ2x2ZUmE3woGxGPTMHrI7SKFqhefSk
kqCViWwFlLQyf6aVzwWxzNyE2gklqWXmplUhBbXsIoTabSmpZScWarelhIVH5jHOzAR4w4LHODMs
vGLBYxwBC4/MY5wZNrHSQPAszQw7dpn9dFtZd+9D3d0uJQEKmIdOM7WwAzu4hyBgmRULnqURsEwS
4tnyHgKW8TaezeYKWKYYYx1mlrAsp2Qr4SUs07fR+yEFE+CR1T01klrIhPrGr4SFkuDtGYIJUBK8
PWOG3XqhqauaWAdpXsEET7bP1MKoIdbRa0ktUzW25UHCQrld+YtQwLzrY+YtNOixIkomwFvmXR8z
tbB3MXlENsNCJqS6/kYxAfYZpjq4qGBhsj15BmxmAi0Srfxblk5JdVD8FUyonf4Sll3etFLjzBtP
CzW+1dre1Xiq68YkE5jRSd4iLASM+Qlp5d/CI/MM2POp9VSVgGVq3PbiyyNjIUleKEaYpsn1GWVJ
LcsuZm8mEbxltyx7M8kMC+vReRWhM0nI3n48U3tmt8xWXcgjYzrBVl1IWFYfyStHFF4Hb4cTvGWZ
QNtJIZnANFh9rF3DwutQv7+klqWvbSeFhGXXoawidCa3lVJNLfNvW3FTCBi7vKVuNpS8ZQLWqpCC
WsiElQ8GJWEVoUNJyFpuYShtm+blkUEmrBQju7zF24+FJLBQuvgAhYCFcrvSt5C3iwgdRpFlVdKB
t2yVEaWw2qBDJthiDnUdxlD6/H6c7I3qR6ave9Djb+h+1r4Kr0iGU10//+vpT+czHjKrCw8ELCzz
BXuBUsEyByfYO/MCFiqzUJWZgoVxarDtr4JauCbf39BVsKxH0so7itrAEiG+FltQCxtAQh16UNRi
WH0d4PIi37YtmACLUb5tW8DCI/OneRUs8/KirWQUsIkZYRvbUrBwQjTac92CWhhVx+qOKVhaK7Dt
r4JaqMZjrSRLWOaORXuuW1AbWX7FF00LWHrLbAO/gIVGJ9obYwIWGp1Ua7MSlvlNyRZNK2qZq5ts
p72CZTmAZEu3FCwzkWnl1bBsUKoTS4paqGqSrQ0UTBhv2V/+P+f1/i0KZW5kc3RyZWFtCmVuZG9i
ago4NiAwIG9iagoxNzA1MQplbmRvYmoKODQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0
IDAgUiAvUmVzb3VyY2VzIDg3IDAgUiAvQ29udGVudHMgODUgMCBSIC9NZWRpYUJveApbMCAwIDU5
NSA4NDJdIC9Bbm5vdHMgODggMCBSID4+CmVuZG9iago4NyAwIG9iago8PCAvUHJvY1NldCBbIC9Q
REYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDggMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dz
MgoyNiAwIFIgL0dzMyAyNyAwIFIgL0dzMSAyOCAwIFIgPj4gL0ZvbnQgPDwgL0czIDExIDAgUiAv
RzEgOSAwIFIgL0c0IDEyIDAgUgo+PiA+PgplbmRvYmoKODggMCBvYmoKWyA4OSAwIFIgOTAgMCBS
IDkxIDAgUiA5MiAwIFIgOTMgMCBSIDk0IDAgUiA5NSAwIFIgOTYgMCBSIDk3IDAgUiA5OCAwIFIg
OTkgMCBSCjEwMCAwIFIgMTAxIDAgUiAxMDIgMCBSIDEwMyAwIFIgMTA0IDAgUiAxMDUgMCBSIDEw
NiAwIFIgMTA3IDAgUiBdCmVuZG9iagoxMDkgMCBvYmoKPDwgL0xlbmd0aCAxMTAgMCBSIC9GaWx0
ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AbWdTY8lx3Gu9/MrztqAWiczq6q7AUELXQhaCxjA
a1/a9IUgXoDm/wec8UZ3nzMTb9qc81RbEEiNyaejIyMj4yuzfr38/fLrpb88jX55aePpeLn8ctmP
/en143//8/1/j/Z0fXm5tss/3/6F7//gyxvhn5f/d/nXf7n8/8t1/md/3S8vW7/8139c/nX+0R//
9lu7/Odvlz/+n/nXn367XJ+O63jt7XB/9+W3ny7by1N/ebk8Px9P1y2k216frvsx/2Cf/48py77t
T+1l+/YPXvf+8a/8843x5Z0R8v08f97r0P/Zv4uf/P6Dtqe99fjJ76KMp+dt+5I/On+S/uQbYfJf
mj/7W8r7zy6/9ZebJuxv/c3Pnj+pcD/+IPQyhfuQNhX3/oP/l1/6O21OY0j1TuXd/471t/5W499h
3n/4229997u63/p4OZ5ej9tSx/9u0yBva/3xJ1/iB8WPfvt3Pn7tj//9A0v95XjZn7a+3Zb6eNme
jmlst6X+9k/C7t7/pY8lefuDuQT5s8tS35n6banfBP6wstsPyoX9EO7u57yr5W2pf//vHBvrfYni
3wrtfiz1/I3+59/6Xt9agFTDuzQ/8ltv80f1621bf9lextO23S31N38QP/n9X/lY6tsffLPW08iq
rd+29fbSn47nu229vbSn1+v7j86f9PYnH7/k+7/0sQa3P/iB33r+kh+/dW7r289+28U37scfvOnl
ba3fEB9GVn/V269/t9hv2ryt9cdP/thJH38iC/lW4+8287Eo+Vu/TIvO/84f9Tx/pe3Sx/40no/L
tvWnMU+Vts99et2+zGPg57d/5O34GPM0mUsx/522tacxPa3+mekYdH6E8L0/vc4/f96nK3u59Pa0
z3Vq8y89ee0S/5n/5K9TkOf50+Lg+UP+bZ5t23M/no7t8tMvl798vbT4/89/Yv71mMa2t+O4fP3l
yx//FpivP1/+dL1e258vX/9x+etXHZA/Tn0W9cvXX+aJd0ftiLqnrIU6EPXoXtaNUV899U6vZomP
Y7r+6Yzu1zjtoX1hazyNbK5xrsaX09Z4Ustq8DV2VL7GjsrX2FH/5zXejun9poe428ZvS3yJRX58
G+9bbOOPDfflnG08qZ+wxI7Kl9hR+RI76v0Sy5n+7mX70sab9x3Ts08ncX3OVZsu/d35/t/f73q+
vLn0G/SYSYeBth/YlwY6hTXQK5L0uXnov5Fff4ak50s6XbKF/kQkbVe/Utd/Z9Tdy/oDG6Guf5vx
h9NAv95kvT71GX/kf3/Hdnj/Ifvbdtgv/Zg/4/ltO4zbdrjbbP9bhFOhI0KRCu3HTfAfh25huQb6
HwgaIYOBIkn32LgVen0hku5epwx6LHS6E0lnhmN//WcCfYl9W3XaHnCGN+N/XSzUA9v2Bm2zXGVF
Rb9/u3pLbcioWnuxsl6ZrCun8sAhc6fXEadMNYHr3WplkvUDjvB2hEdcEGUBRXN3ccEDjvAOOhfN
QVlcMD2Bg/5ALPfusm+SPs/95aB3yv29LvsOupD0Afdyg77M7eUkfcAT3EH9Qg0UbMyCopUUxhqf
8fvLvTitIgW0tjAAZFVtZnJWr2gDtL6Q9QFXeLOrNmZkeL5et8hjjLNCG6ttCw08EAzdaWBfaIDp
9VhoAHmBFtmR0yuz1+d5yDoqW61ZXLJUtmNfF+cAW63XhQaQJ+zXhQ0gvfZZG7B6Rbugt8UuQPba
u9dAQ0FLX3lC5F/7WFgWstc+FpbF9DqretYGmGXtXgPtLp//8Rir7wsNMFmjQu981gPZ9u0s6Mdi
b7HVevZ7a3v98YTzTtYXv7eujPq6OGHY3npdRERstV59UMwKkONT/OtY+Ve0C0ZbaAD5rLHwr8wP
jFWk+UDSfdsFY86/WD+AduyY8w2WiuKssYgJHymR3GlgERPC1XpeWNYD5Zw7WV8WemWrtfIubG8t
YkIWu2zXxbmF4tdtdu2tvSL/un2Kz9pWPgvF2jGiZDWAKlnbHAG0VGSv27ZYLWSvW0xtmIioobxg
i/kKR0VRxrbwhCx22RaekPXOtjmx4zRwZZYVLUmj1yuzgTkV6qiN7a2VJ0TeZY+GgdFA+5lExXNu
yVKZXqecnor8wD5ndZ0Grih628dCA+jk3lcVPXRu7fsi20A+a9+9ZV1RDrOvMk62Wou+RmOyLip6
HXmXfVXRg1Rvryx+3VcxIVqtYxW9IXs9VtEb0uvR/AkD9RoB0azqfd+FRImR9quBohhDpZwKZcmW
KjlnQ1XIqdBHety3VEt1HANFZ7YahgaKwgvNIzibQi6wzXFoa6nIAWjkycjK3HVTeGH0ihxAtiEN
Fe3VNuLINlQUCrURR7ahInNtSokqdTANKGipVFZ2bCsnyDQw5/utXpllzesEjtoYdY7OOGpHBcL2
4qksLW6vntqRZWVrr1oWS4m6AoFK7eh47Sq4VCpLtLpSIkNFXrsrJTJUlLz0hXdh5Ya+LTwh2ls9
Rj6df2U2EOOZjsp2wcK7MP/aVcYxNsD0GmOfRgMsyI7LvY4K91YMrBtZWblhxMC6oTINjDk75KhX
dBaMvrBXFLuMvtixaBeMhc9i+ctY+Cy4WppNNXsLlZzGKiJiq7XIC0+/tNDn8Lay5DMvLRgov7Tg
oA8UYW+T0DrC6q/PJNUJVqHsfkFcWjC/PoPqVKyS9geijZtOj5ghqdDrA5WnG/Q5sgMDRauvzrGB
PrBtb5LqRDTQB07vG1Q1wgpldzbiRpxVKlr+pl5slfWRmvZNAVl4MNQHCjr31IVZIQtoI0JYIyva
AW0+w2KpDxxddxrQfF6V9f6Q+b2TdHdUTSpX6iOB8R1VJYJKbcxe45KVWa17KrwMM2YG+n0ZGs2V
RrzhoKjRG+GGg6LiZjSNHBRFnFF+cdAHXOytDB2XYRz0AVdwB10sFCoSREXHSfqAI7hJqiq0oz6w
ue6ocfHWUR9whXfUqEI7KjLVNtMCS0WLpSq0kRXW4aMKbags727ROndUtFtbDGs7KrPXCIgdFfnA
FsGroyIv0J4XekU1ghYjiufLGqGmoyLn2mIwx1HRju1xP9hRkb3GpI+lIg30lSdkGohg22kA+awo
klnqA8H2zWurYu5kRXtLFXNHZRqI6pOjonOrR/XJUZkG4skUR2WyRm3bUdkuiGDbUZllrQJCFLv0
l8XeYhp48Sc3iwf6KiZE3kUVc7NarCutayuG+khyePMuurbiqGi1dG3FUGEVOq6tGCqL3kbMOzgq
irNGXAs0VPYg04gnaAwV2kCUcw0VrtYq0kTzDiOGNI2s0AbmW4iOCjUQ1VcnKzpjRwxpOirbsauo
mHnChdeGHcmV10anoS7uOL2iDrou7jgq0us2n5OzNsA0EG/xnC9r9GQNlZ2GW8yRGCrzhFv0ZB0V
7S1dB3JUlMdu0S8zVOaztuhtOSo6DbdjccIw6ip+ZXsrJj6MBpjP2qK/Zagsft1iXtdQ2Wm4x8SH
oz7QNbxFmvuqPoCyOF0HcrIiT7gvfFZHVbI9HqBwsjINLCJN5gnn86deVhS77HHZ0GkA+dc9HqAw
1IbqWfvKEzJZF50dNq26L3zWfTPu97Yj73ZsPMVj9Aq9y6JSys4tXdxxsiJ71cUdR0U1IpWzZifi
u94mu8OpvMhAUbalAryBooNAtlqhzKritu0wULRQMU9poMxS9QCwobKp4naNqltVAJRVeUalsrXS
o3xG1vt3NH/cW+k2jKOiSKDF7Kejon3V4iVRR0W5pkZdHBVF2U3VIWMDTK+KBAyVaWDhBa9stTTi
YWRFcVuLq4ZutVDU0lQdqrI+Mph0iwSyZ1qp0A8ovqhUdh+oK3upVHbbMrublcoygh7PkzobQJbV
u7csVnHp8VTK+bLGUymOinZs37wG2PV43dxxsqKMQDd3HBX5Vz3K56gog+2qk9ddwHLNrjq5oTK9
xhMJTgOo6tbj2rWhsjirx0N3jopO7uwYVr3CGyaanajURwaVbyfMUO3ZUFH+NuIdeKdXVCEcq+gN
2Wt2DI0GULI1VMcxVHTCjFX0hnyW7gOZ1WJnbHyIzdkA81nxmbdPoK7SWLYLFnksi96Gas/GspAN
bJpNM1R0bm3xFJWxLGYD2yp6Q35gU+3ZaIDpdeEJ2d7a4slPp1c0QbRpntZogOk1Hpc3ssLnHuOt
CENl2cammwpGAygqnt+g87KiiGhTF67KyiKiTVNklcqqZNsi42SVp03zCEZWZK/7yhOi2CU+Imrt
FVUd9rbYBUwDq0gTnYa7pnTNaiGftWuKzFCR19ZTf867ML2ucm4UE+7xULORlX3BZo8rcYbKvMse
z5Ma6iPXgm85zK7e3uk2sKoTMhuIS7xGA1Cv8RaPobLZif3V28AjV6NvqzW/UO5lRXo94nKw0wDy
r3rqz1GRzzr6oqKH4oFjFRMy7xKizqzzu54pKzrItxgoOl/kWiqUhZnqQFQoizLlWAwUBZnq7hoo
sql5edmtPnNWepbQ2RQ6sts1CgNGAShs09fRHBU5gGzEGlnRBmhqPxgqcqzZiK1UNlDf1NSoVLax
mgIsQ0WHgL6O5myAUaeY1l7Zamkky2gAuQF9Hc1oAPoBhUJV1o7eGsiWaaWyoltTAmuozA/omqmh
ovZD10jK6VRdCDVUNDjQdTXeUNFZmI3YSoVtSI2kVCqzrB6vr5y+t7ouLBlZ0QmTjVhDRdNeXReW
DBV5wq4xUkNllqVGrKEiP5CNWENle0sjKYbKbGDlCZkNLDzhQNHbUKppNIAiTT2haHYsG3YaGvkz
sjINxFc7jKywFR1P1Boq84RDV4uMBthqLfwrXC0N/1dZWUSUTeNKZWWcWCi7Wih+HQv/yvKCoVZJ
1QDUq67xVypragw1YAyV7dhVIo9OmKFrUEZWdBZkK9pQ0cm9aZDQUNFAxqZrUIaKymPbwr8yy8pW
dJWVNo1j5K9SYTN+4QkhVeMzRlZkr/rmmtMAs9dVzo3OLX3JzcnKBjLiS26OynbBIpNn8cAWn29x
sjK9Ljwh3FtqRRt7RV57X2XyyF71fTijV1Yp31fxK9OAhnKMXlEWt2sox1BRlWyfHUhnryx22TU+
Y2RFu2DXXThDRTGhvg9nLIv5gWwaV1kbswENP1cq+9DIrkHCSmUfcNkXfZgrqpQeqzgLeZdDgy5G
A8gPZCPWUFHV4VjlsUiv2lrz4YXvW6YofNWjaQaKzm1N6BooMgDlWgaKVkpJkYGiX1+RQIWy2oim
cyuUhcP52q2honBY31wbhoqWSk+fOypaq6bi0Omy6t0ZQ0U7INuQhorKuU1zXpXKzLXtUSCsVNiI
VRnHUJm9LlwLvGOpGcoZv3/nr8eVfC65xcfYR6VCWTVDWakswMo3nyt1nLALKhValnaBoaJwuOlN
J0NFyXZTidRQkV7zjcfTqSvLYsVMJVpGVuQH8h6YoTK9qpBVqew1m3w50lCZrHqj3FDRyT0UZBoq
Ct2HpnMrlfmsofStUlmynW88VipsFmk611BRRDQ0nWuozLJ0I9ZQUbK9KSk0VKSBTSMplcoiok0j
KZXKbGDTcJ6hMg2ouWmoqIyT7yYaKpN1dXKjs2BT/GpkRfFAvsZoqEwDMyB2MSGbp897YEZW5Ac2
fV+mUpl/3fQubaXSe2CRwxgq0kC+xlipHdlAFt8NFeWG+yLbaIyqnLvKysqOs0RuVwvKqi8gGFmZ
Dax8FoqKd91dNbIiT5jFd0NlGtC1ikplj+bteuDOUFGUkcV3Q0WV110vj1Qqy+TzblWlsqh4X0Rv
G4rg8zVGIyvaBYcahoaKTu5D75kYKsrkj1Uey/Sq90yMrMhrH/HhRXcaIr3qm+wRcH9XJWP22sO/
OiqTNao5jopsQAPFjorigR4xoaMiT6iBYkdlssZAsaOiE6bHFxAcFXmXHpGmo6LMqEd3x1GRBvTd
GkdF8YDGlB0V+awRA2+OyjQQObejooswI75bY6hwRDVeEzdU1uHTK1SGyvItDRQbKqtljIhfHZXZ
QNwKNlQ2mKWBYkOFeo1OlKGyq2sjxugMlZ2xI8boHBWdsRoodlTmXT7Fv2qg2MmKquUaKHZUdG5t
0Y00VDact8WLLp9AXdgrijK2hddmPmuLC8dGA8xrq1LqqOjk3j4lKtZ3a5yszF6j/mqozL/qxSxD
hWP1q1ib2WtcA3GyotNQ9VdHRbUM1V8dlWlgprBWA+iE2a9+x7J4QC9mna4B1V/Pp648IfIuqr86
WZG9zorDZ9hAVHWdrCiT1/Czo6JdsEf33FGZXmOSylHZ3lp4Qri34uVnJyuKCfdVfYDpNa4xO1nR
aahBbUdFO/aIFwkdFWngiMsljoosS7ViR0U7VlVdR0U7VnNvEW5+V9NkvY0WTy84KqrotZgqd1QU
D7R479RQWcbZomfkqGy14uqao6K91ZRzVxtgLxLqERonK/KELb7g5agoj+2Ks4wGkCfUIzROVrRa
PXpGhsq+5tjjkpmhsg5fUyY/mzHfexd0yUxzxVulQllj+tNQoR9QPFBlhVR1IQwV2WuLd4+dBpC9
tri45ajo5G7Kt6oG2KSqvt9jZGVX13q8AO+ozGfFvIujIv/a44EnQ2X2qgeeDJVVSPTAk6GyKlmP
a/eOik7uPu/tWSraBfrSjpMVxVldsUvdW6xO2BW7VCqbVO2KXSoV2kBcYXV6ZTYQ38JwVNiPXexY
JKu+3+NkRWfBUA3erBbKt4Y6p4bKNBCTf04DyGuPuG3nqMgPjHj001FRZjRUg696hR0+9TgrlZ0w
+n6P0wDyhNk5NbIyy1LntFKZJxxxP9hpgMkaF4QNlZ3cejTJUGFvQzWiqld2bun7PU5W5Af0/R5H
RX5AjyY5KrKBbRETshmS7EaevlorT4gyzuwbni5r3I10q4XO2E11bSMrOmO3uGvmZEWxS3b4jKxs
F6zyWJQdbwtPyB4m3DTtcbYGdG/DrBar6u7NnzDwERpVnqoGGopd9kX0xmpEuyYoqqwsdtGXdsxq
wTsm8SUzR0VdCN3bcFR0wujehqOi6G1X39CsFpN1Eb1BG4hvOjoNIJ+1r7Jj5LWzZzRfrP6uqsui
t6bMyFCRvTZ1zw0V2UB2ogwV2WubwH0zVCbrEVXdSmXTdE1RRqXCly00R2SoTK+qlhsq06u654aK
Ypfsbxkqigmzv2WorFaseMBQkQZ6i0jTUJENdFXLDRXZQNd0UqWyzKhrur5S2QensgZfqSyTzxp8
pV5R9KaPLBgbgHrV/ICRldmAZp4Mle0CxS6VyqaTetw5dXpF7zz1uCdvqKxO2JVvVQ2wOKurBm+o
KDvu6kYaKvKvQ9NJhoosa6gbaaionjXie9TGBpjPysq+kRXFr3knylCRDQzlhoaKIvgRLwU4vaJ4
YCg3rLKyGZK8E1WpV3SXNyv7hsr0ekQvzlCZZa2iYpTD6CMLTlbmBxZem53cQ3dOjV7RGRtXue1q
oR27aeqrysrO2Ly9VKmwC/Ep8WsMfFm9Iu+yrXwWstdN0/VVryx+3eJp8dP31qbboVVW+MZPfGTB
yYo8od55clRmAwtPyE4YvfNkZGV5wabOqVkt5LOyX1Cp7HNem6bpKpV5l12d00plet3jxTuzWlDW
ePHOUVGHb4+36RwV2cD8Grenor01byx4KjoNd829VRtg+dYer3QavTKvva88IaoR6SMLRlY2S7bH
C/OGCjWgfkFdLZZz77onX6nQBuLtz/M1EG9/Girrxx7xuURHRdnxoTn4s/V6aJquUpllZXdnNrm+
7+6gzKjFy8KboSKf1ZTHVirUgKK3SmWWlfeMDBVZVjtib1Uq1MBz7C1DRXls012ISoU9I92NNFR0
xmYfxlBRPJB9GENFmVG/Ru/YUNGOzXtGhop2bI+36Zys6OTuurtjZEWZUY8X75ysyLJ6vHhnqCwz
6nPMwVHZyZ13IYxeUV0770IYKrMB3eM0VLa3dBfCUJkN6C6EoaJKad6FMFSUGWXHxFBRhy/fezNU
5F/zvTdDRZalz1KbHcv2VnZMqqwDee0Rn/MysrJ4IHsbVVZWH8jeRqXCfsEiJmRVh+xtGFmRdxm6
C2Go6Nwayo4NFfmscSxOQ6aB+DKGsVc2SzYW8esVxa/5ipzRK/NZ8bay0wDTq7LjKiubAN7UkTZU
5F/1AWmjATYBvK1iQqTX7JhUDTDvkh0TQ0U7dlt5QvSi6KaKnpEVxYTbymeh7Hhb+SzkX/OGhdEA
Wy3NPlYqyws23YWo1M52gbq8lcoiouxtVCqLXbK3UamsF7dfF3ks0uuu3oaRFcXau+7HGirasXnD
wlBRfSA7JoaKTu7smBgqW63NV8nY/MCulwKMrGy1NO9iqCjj3BfRG8sL9GUMEw+wbwTtmncxGmA2
sPCvbIom31AzsqJIMyv7sxnzfWUfUuP9AUNFp2HTXIahotilaW8ZKtpbTXvLUFHs0rS3DJWtlmrw
hspkVQ3eUNHearphYajohGnKjAwVnTBdfUNDRavV1Tc0VKTXrr6hoaLKU+9Rga5UFr3lXYhKvbKa
pjIjQ2Wrpb6hobLVUo2oUlmU0XW/oFLhas0jy9kAm0rIunaV9f4u7/WpX97/+9tPl1/n/3iegxfX
+Z8/5N/2l6c5oT3DiuPp2L789MvlL18vcyPon5h/jV7P/t5LH5d2+frz5U/X6yN3cG/QMZuzBtof
cLY3aEz/GOgj3+q+g85D3ECZpPENIgN95F3Jm6Rzjc6HxksMTtIHouObpNHkMdD2gOu6g/qFeqSH
foPOvWUlfcAd3qDtOku77vd/IIS7py4U8MDxfUeNRzWNrI8UCe6o8bSBoba7cDP8z/XyAy5rvLms
KfB0tvu8JfVdOM/KptFFNVB2jycCZAdFKULExw76gNHedBrhsYOiIzzuHzsoqupEcOygqBQfsbGD
Ip22iI0NlcUaelvWUZmsMZ9iqI84gptVtZgudlRkVi3eZTJUqFcFLdWtsCnYFvMpRlbWN2nRi3BU
pteoEhgqfDEhOhyG+sjJfWdZ0eFwVOQGmkIXYwNMr9GVdbI+EA7faSBmlh0V9Xj0ermjohxZbyEb
Knv5r8ftDUd9ICS66bXH7Q1HZXfFo8NhqDBDjNtxhsr6UZoqNFS4WsOvFpt66XE7zsjKvLa+eGuo
UAOLwJV5wh7vMBhZ2cndY77aUVGU0VeeEHmXvoozkdfWt2mdBu6SmN9bbrnzLvEdB0dFKcGIG72G
yvpReofBUJnPGitPiPxrbK1jfp/2u5zwkTLWbbEiJ3RQdL7ExnJQtLFiXzko2gHxiJqDIkmj5GKg
A9l/bCoDhQlBbCpDZSX4Fk0IQ2VHS4uhL0dFptqiOGyoMHmJiwCOioxVF60MFdpAXA41VNbmVjvW
UdHRonasobLBaj14Z6jQBmLoy1DZeFaLUQdDZeGwPg9jqKwRpYtWhsoKjvo8jKOi1rGubzkq8i49
ntFzVOQHRpScPoG6OAtRsq3rBU5WdBjqowiOyvQaD4oaKju3xiJug4FrtI6drCjEHHElylAfaevd
YswR5XxHRVHWiHq+oY4HenA3WeNtk2OGmgqyj49e8X1b58czIp0EZ0NjOs1J+kAL7vbrxxMkDvpA
s/QGbVHE+gTqYqnQ+rd47M7Iyko4ahIYakM7oMUTJI6KfKs+8OmoTNZtsVosHoyJAScrigVaPKvs
qLDwvlgtRlU8eLZvaXEJwGkAtTUzcquy3g/7/LhzlceeHdPzPfbZUHnsCmW1JnnsCmUF1/TYhooO
lxbPkx6GyppE8tiVClt6irErlUVC6bENlWkgxsacXk/w2FXWxmIBeexKhZmmPHalskuhLZ5UNnqF
liWPXWXtKM9Kj12pLHBNj12prOasjycbvbLV0qMm51NjzstR0WrpU6yOyppEMd7hqCgr7nEVylHb
ny9f/3H569fL33/3TO4tJ+gxQOqoyBP2GPZ0VKbXRYjBztiurNDsLXTG9kWQwfKXvooyUK41lBca
DaAoU4+gOxtAOzZM4HlekT89yjwdGgZgoDzKNFB2DijKdFTkrxRlGmpDnkV1AUdFXlB1AUOFnYeo
CxgqMwHVBQyVecEWdQFHRV5Qn1tyVGYDEWU6KsvgI8p0VFYZiSjTUZEXVJRpqDB2jSfgDZXFrooy
DZVlcIoyHRWtVo8o01FRBqco01Ab8q89okxDZVe4FWU6KtNrRJmOinasokxDZXmhIoz5vP75EcbZ
UEUYFTpQ2BYR5nOFwtMlIkxHZad21LEMFc5hRB3LUNm+ygij6hVGQ4owDBXt1owwKhVqQBFGpcKK
U9Sx3GqheQF1HgyVeRbVsQz1hEkUR0VnVkYYdbWgH1CEUakbWq2MMCq1sWpD3Fc0emU2kBFGlZXN
DWWEYagozs4Io1I7sqyMMCp1QxMTOrXnVaXzT+2zoTq1z4bq1D4bmnWBSmUBRtYFKhXWMHRqGyqK
sfPUPp2qU7tSmWfJU9tQmQZ0ap9O1aldqZ1NTKguUKkwblFdwFBZjKW6QKV2NjER8wLPlQotS6d2
pcIMPh46dbIivWZdwMjKTkLVBSqVxa55alcq7L+pLlCpzAby1K5UFruq+2RsAEYY0X0yVFhvWYQY
zLuo+2RkhZcKF0EGvKi3iDKYH1D3yWigo/kGdZ8cFcWuelDeUFnsqjlyQ2UPSY9FlNFRzW3EjIuR
leWFYxFlsL01FlEGtNdFlNHRuTUWUUZHxbyxijKYrIso45HnsW6TCPoArbEslsXrOXVDZf51U22g
noZsjnhbRBkDVUm3eMLEaIB1IbdVlIGyjS1mXIys7Nza1H2oq8VqLvqoq5F1oFqWHj53VNQv1Edd
DZVFmnr43FDhc+qLKINR9US5kZXVMnZ1IIxlodhlX9UykB/Q51eNBtgu0GPi51MXUQbLYfZFlMHy
gnh8zvksSF1FGahCMuvZVlYWZ+nZb2cDKMrYF1EGq5Dsi1oGs6xjUctgkeaxiDJYtqE0dlrX+ZXy
s6FKYs+G6nQ5G5qV8kplp0tWyiuV7dacoDNUtFuzUl6pbLfqnsZzpbLdmpXySmW7NSfoKhXWtHW6
VCq0gQncjV5ZPTP720ZWFBHrpQUjK7QBnS5VVjbrpnsaRla2WtnfrrKy1cpKeaWynCD725XKVisr
5ZUKq8/KYQ0V1QizUl6pLB7MSnmlQstSpdxQUY2wL0IMlsVnpdzIiiaUdU/D7FhWfdY9DUdFlpWV
8qoBFg9mpbxS2Y7NSnmlshetslJuqCgzzkq5obLaq3JYQ0WnYVbKDRXVh7JSXqnQBibQRRksKs5K
eZWV3azKSrmhor7xWEQZsFuiHLbKymLtrJRXKrOBrJRXKou1s1JeqSzWzkp5pbIzNivllcqit6yU
VyqL3rJSXqnQBhZRBju3FGS8fMbE39lQ1THOhqqOcTY06xiVyjx21jEqlVlV1jEqlUUYWccwVHRq
Zx3DUNGEctYxDBVF71nHqFS4WqpjGCrqF+acfqWycyDrGJXK8pesYxgqyl9yTr9Sz6hjVCo7CbOO
UansJMw6RqWykzDrGJXKdkHWMSr1jDqGoaJsM+sYlcoit6xjVCq7s5U3ASuVvZ2bdYxKhbdV4r2J
50qFlrUIMticS9YxqqxsPjPrGJXK4sGsY1TqQCdM1jEMleWF8aqVswF0cmcdo8raGFV1jEplMWHW
MSoVZvGrKIPVh2ZC5FaLRZpZxzAaQJFm1jEMFUWaWccwVGZZqmNUKvOEWccwVOQHso5RqSzSzDpG
pbJIM+sYhooizaxjVCrz2sri5yfxzp9GOBuqA/ZsqLL4s6GZxVcq89iZxVcqizAyi69U5gMyi6/U
K7tdpYl6Q0VeMLP4SoUa0KyboSIvmO/5GCqKhjKLr1TmWzOLr1SWw2YWb6hsekZ9gkplFf2cRqhU
ZlmZxVcqzAs161aprI6RWXylMhvILL5SYR1D0wiVCusYmqivVGgDmqivVFjHUJ/AUFkdYxViIE+Y
0whVVmhZiyCDnbGZxRtZWU6gN30MFUWZmcVXKpvHyCzeUJFl5TRCpbKIOLP4SmWWlff2KnWgcyuz
eENl+bayeENllqUs3lCRH8gs3lDRDZDM4iuVfXc+s/hKZVFG3tszVGRZmcVXKqtlZRZfqexbNZnF
GyrTgO7tGSryWZnFGyq6V5LTCJXKKmQ5jVCp7F503tszVLRj895epbJvrOW9vUplX+rIe3uVOtAM
2baoZQyUc+e9vSorvQ0Yd2IrlVVI8t5epbKadt7bM1RUdch7e5XK8oJdvYJKZXWXvLdnqEwDiygD
amARZbDp77y3VzXAXo/Me3uVyuoueW+vUln8mvf2DBWdsXlvr1JZRJT39iqVWdah1wEqldVdjkWU
wXKYSLlf5jc3T6/qnw6NhPt0aJyEp0NV1TdUdmapqm+ozFZV1TdUFg+qqu+oKNvUbJ6joul/VfUd
FXV3NZvnqChyU1XfUKENxEloqOx0UVXfUFmVVFV9R2WWFVV9R0Vxi6r6jopkVVXfUdEu0GyeoTLL
UlXfUFmEoaq+oUJZo6pvqLCiG1V9Q4XdkqjqGyrUa1T1DRV2SxYhBvMDquobWaENLIIM2C1ZRBkn
zOY5DbAqabyTY6jMslTVd1TkX1XVd1TWLYnZAUdlNe3Itw0VdktidsBRUeVRdwwNlWUaYxFlsB2r
qr6RlcWvquo7Kjq5VdV3VHRyq6rvqCh+VVXfUVH8qqq+oTIbUFXfUFn8qtk8Qx3ID6iqb6jsTXVV
9R2VrdYiymA3AFTVN7JCG1hEGSznVlXfyMrqxKrqGyrUwCLKYJ5QVX0jK7NXvcbnqMgTqqrvqMgT
qqrvqGhvqapvqMwGVNU3VOYJVdU3VBbB6zU+R0Vn7L6IMlgWp6r++bLGm7+OynbBqpaBJj9V1Tey
MntVVd9Q2Wqpqm+oLH7VATNvA51fKT8bqiS2QtlRqNOlQtlJmJVyQ0W9oqyUGyryLFkpr1QWDWWl
vFJZvp2V8kplXcislFcq21d7n07w5ch9tV3a5evPlz9drzDAiLzYQFEkcESB0EBRIPB89VBUw4iL
q05SVBrSaWV+fVRr0GFVoQMNOb0e9teHO/W6WSqLr9OrVAU0lGWmVzFUZP+tv3gNIAtow68We+26
bYt9hWbH2rbQANqtbY8eQV0t+E3zI+qYhspkXfkr5Fra82JvoUi4vSyOFhZdvC4sC03PtTkuYlcL
7dh+XdgAWq1+XRwvSK+9LTSAbKB3rwEWs/S+8FnIE/ax2AXoLOjqPBg/gOy1bwsNIO+iN0ecz2L2
GvODhsriga5Kg9ErCl16vPtvZGX5QF/FbkyvSjSrBqBelWlWKqsJ9NfFyc06kAv/yjQwWtSFqgbY
d4BGW2gA7djswVZZWfQ2YtbRaIBNJ4+Vf0Xn1tgWUQbaW+NT/OtQR8esFoqKh+ZGKpXlMEMFt9Op
q9SY2cDCEzKfNT4l0hyrSJPZ66vfscwTbqtIE8m6Lfwrm8/eVv4VWda2ijT/7c+Xr/+4/PXr5e+X
Xy/Xp+fj5XKd//lD/m1/eRr9sj334+nYvvz0y+UvXy/z3r7+ifnXbSxWC0Wa27aIs1AOs82Pdtmz
AJXddGPNnTBMA4eXFe6CubZWAyiC31aRJsphtlWkibpP26JMyObydA/O2QDzLvFWlqGyTln24etp
yG4t7quaJtoF+8q/Invd2yLjRH5gb94Tsnff9+5t4Ipyw334CgnzLvvmM86GvPa+il/R3tpXZwHy
Wfvu/StrQuQkQt2xcLVWXhvFA/sU0/os5gdefT0LWtbCv7JqeXQhX+c7Keru33UhkWFFNGCgzK6i
C2mgLDV+/oxff75AaCVFTvBl7lX366MqRqREDoqOlqg4OSjKB9p17lRHRUptbe5UR0XeukVG5Kgo
DmhR0XdUptcxa26OyjQQJ7ajMg1Eb9NR0Ymt3qajIhfY9oW9Mr0uPCucb4neptFAQ9Wx9jwjTEOF
k1Mvn3EMtNfFOYAsq1+9XlmNuEfuYvTKqo69LTSA+gQ9vhNuZGVZRp+jWJaKvEsfi9VC/rWPxVmA
Ikx9+eB8vUaV3FBZ3NoXnpC9aBVF8tfpDU+fSj0dGiVyB0UGEL1CB2UeO95L/ATqYqlQ5qb5MSMr
PF3kWYxZsVggblYaWRuLXWO+wVGZrHGz0lGRF9T7DY6KPLZeZXZUdGbp/YbzqVEfdlSm16gPOyqa
HdL7DYbK3nSTx37+hHsEr2dD5bErlI0hyGNXKIuEdI/A/P6so6d7BI6KehnpsasGWH9AE79OVnS8
6h6BozINyGNXDbAKnl7cMbLC7C1mxwyVvYmRHttoAOVZ6bErFVqWPHaldlQc09fwjF7Zuyjpsaus
7DKJXtwxsrL7j3px53xqvD3nqGi19OKOo6Kqa48XdxwV1YYyJzzdBpQTGiryhPoantMA0+sixGBn
rF7ccbKiE6YvggyWv+gdfSNrQ3rV1/AcFdmr3tE3VLZaenHHUdFqybDmVNr51YazoTKrCj0hdq1Q
drpk7GqoyKoydq1UWCFXHdNQ2c1aVRsqFcaDqjZUKjMB3YF9rVS2WzN2NVS0W7PaYKjozMrY1VBP
qDYYKqwLRDRkqCgayti1UmFEHHMNRlYWEWfsWmVlmXHGroaKVkuvRRoNMD+QsWuVlb3znbFrpcJ7
OvFapNMA06tiVyMr2rEZu1YqyzZnhHFc+/kRxvnQGWE4aEflfP36c2jg7ADruJ4N1a9/NnQWB8+X
NAIsR2XPb0aA5agwGJwBlqWyYHAGWJ9AnQGWozIHEAGWpTINzHbOJ1BncdBR2XNbEWA5Kjtaojho
qehoiee4HZV9liECLEeFljUDLEeFodDVrxbzLhFgOVlZiBkBlqWiVmkEWI7KPv4UAZajdha0zADL
UVn6FtfWLRUlWhFgWSpKCvsixOjID0Rx0MnaUQM2ioOWymRdRBnjSq7URXHQyUpLjn5vwYuliyij
IT8QV8GdBgYqDsVHNh2VlXHiI5uOypLC+Mimo15Z2XkRZbDxyXiO28k6UAsynuO2VFRwiee4HZU1
4OI5bkdlH6yL57jPp8Zz3I7Koox4jttRB7JXHTDzotb5OezZUB0vZ0N1upwNzRy2Utn6Zw5bqTDT
0OliqOjUjgGX+VxsMSuYaeh0qVSYaeh0qVSWaUSTwGqAjU/qdDGyotg1c9hKhWMzOl0qlZ0DmcNW
KrQBnS6VCnesThdDRedrNAmsZaF4MHPYKivTa+awlcqe4cwc1lBR7Jo5rKGyrEg5rKGiyC1zWENl
lqUctlKhDSxCDLa3Moetsp4QDc1Y+/xo6GyooqGzoYqGzoZmNFSpbP0zGqpUZqsx7ntcK5X5q4yG
DBX5gBj3tbKifCAr+kZWVMnLaKhS4WopGjJU1n2YQKdX2CdQNFRlZdWGjIYMFVUds6JfqXDHKhoy
VHZmKRqq1IFsIKMhQ0VxdkZDldrQ3spo6HSqKvqVesL5Ol+aOP98PRuq8/VsqM7Xs6F5vlYq3K3q
mFcqq2Xn+Vqp8BxQtaFS2Ssreb4aKtqteb5WKtSAqg2GirxgjCQeV0NFXjCrDZV6xvlaqbA6plq2
obLqmKoNlQqrYzpfK5VZVlYbKpVVx/J8rVTms/J8NVQWYahjbqis3qLztVKZvcZ1GrdjB7LXrDZU
WVmvMDvmhopi1+yYGyryhFltMFT0dEF2zCu1sYrTIspg3iU75lVWNokQ12mcvbKIOK7TOCp7vCM7
5lUDbG9lx9xQkXfJjrmhou5DdswrlVVH4gPWbrXYRFJ2zKus7IJxdswrlT3smh3zSmVPF2THvFIH
Og2zY26o6FGM7JhXKuvuZ8e8UlmUER+wdvZ6QmY8XzY8PzM+G6rM+GyozqyzoZkZVypb/6w8VyqL
szMzrlTmW7PybKgsg1PluVJhBqc+fKWyT7hn5blS4eS/zixDRb41M+NKZY8Q5yy5oaJuaVaeKxXu
LWXGhsr0qsy4UvllveNaqUwDmRlXKvMumRlXKvMuWXk2VORdsg9fqVADyowrFdYxNEteqWwyNTPj
SmW9osyMDZXVBjRLbqgsi18EGXBvLaIMHrm19gk9jdOhodTToaHT06GK3AyVrb8iN0NlnkWRm6Ey
36rIzVGRb1VPw1BPiNwMlWXFitwclc03RORmqMxjK3IzVFbNVeRmqHAXRE/DUVmMFZGbobIYK54I
c9QNyaqexumyKnJzVFTJU+RmqOzMUuRmqGy1FLk5KqoNqadhqFADEbkZKtRATFAaKtuxitwMlXkX
9TQMlT06pJ6GobK5gXgizOmVndzqaRhZKdV7QmYD6mk4WVH0rp6GoW7ojFVPw1Dvd+z16dAHDn/7
6YEvIsZxu0clWtXSdplfAvr58qfrlV241ouchspet9MXJRwVPT3SZizvNHBFrUO9leRkRclci2/r
GCor7verpzIb6PHdOiMrKxfGIe6o7Lqxvv3gZEWr1eNro46KWod9DihZKipC9n1+VcTJyjRwzJfv
HZWFMfHVLkOlx623V3YxuL96Kj0YFz4LeUJ9f93olfmBFl+Y2ubnZb47YeBZEG/oGioLDdosbToq
a3W3fUFFO7Ydc8caDTD/2uYVI0tlp+Ec2bdU5Anbi6eyvaVvQTm9Mk8Y31ZxVDb2FN8Jd1S0Wj2+
Y2uo7KEQfQvKUFmcpXjAUJkNKB4wVFaI7GOeBYZ6hn/din9l3wPTe69bpTINtPhS+vnUeOfRUFlM
2I4ZZRgqPGHiW3uOyspw8R3LYwbcp56xfb5H6ahMA73PbMPIys5YfWfNUdEZ28NeDZWdsT0+umuo
zF71Lqmhsjirx2d3z6dGPOCoKH7t8cVJR2WnYUQZhkrzAk9lF23G1VsWs4ER9QGjAXbG6qV+Q70/
Df/+33uBypMKZW5kc3RyZWFtCmVuZG9iagoxMTAgMCBvYmoKMTI1NzkKZW5kb2JqCjEwOCAwIG9i
ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDQgMCBSIC9SZXNvdXJjZXMgMTExIDAgUiAvQ29udGVu
dHMgMTA5IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTUgODQyXSAvQW5ub3RzIDExMiAwIFIgPj4KZW5k
b2JqCjExMSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAv
Q3MxIDggMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMQoyOCAwIFIgPj4gL0ZvbnQgPDwgL0cxIDkg
MCBSIC9HNCAxMiAwIFIgL0czIDExIDAgUiAvRzYgMzYgMCBSID4+ID4+CmVuZG9iagoxMTIgMCBv
YmoKWyAxMTMgMCBSIDExNCAwIFIgMTE1IDAgUiAxMTYgMCBSIDExNyAwIFIgMTE4IDAgUiAxMTkg
MCBSIF0KZW5kb2JqCjEyMSAwIG9iago8PCAvTGVuZ3RoIDEyMiAwIFIgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4Kc3RyZWFtCngBtZ1NjyXHcUX38yve2oDaVVlVr7sBQQsbgtcCBvDapkQbAmVA5v8H
nHFjet5jx02LrJMlQqA0IE9H50fEjcjIrL/f/nT7+629vWzt9rZuL/e3299ux/14ef/+/3/6+P/b
3v/0bVlvP337Fz7/wZdvhJ9u/33793+6/c9t6X8d78ftbW+3//3L7d/7H/3zv/283v7r59s//2v/
+w8/35aXt+///fmH2+vbS9tv99f2snVT2lt7uff/v+7ry7a2L53x47d/pL23l7a83bbj/rId7bb1
3+F12ePH/NiB92V7b+vd/q/+Y/b+Y97evrT7/WV5v/dfeX9/WY77rfXfvJP6b3jsx8v6tn/6k/f+
kz7+pZ++UT7+4Ev82vGz3zf9x/6v+NkfP2p/6T+x/2jZ0inby2sf9fzR/Qd1657/JI3Rv9N/8i8Y
Hz/4//mlv3z/pT/MdT/5M/b7//8YlU/j9vGD/8Fv/Hks+wr7Prr6FfvQxZ/k6D7/0r8c78e/9WFP
Dnj5vb88FsDj9163PjV9br9PdvxBXyKPuf7FH8SP/vavdPO+TdIH41f+4t/Gb23vL305fh/xL2tf
rLGuH7/2L/8k5vrjX/o+2Y8/+MVv/fS7/oPfOtfZ4yd9su6nLx9/8DEu537pb7P05dtoPib78ZM/
Jtv8ybdJ+jwp3zdX39L9rz6rR2sv72vfjvv9pXNubX05+v5f+9/kbH68rfqr/6N/71vxtbuT+Dd/
l/8zPd5xLO8vbWtffvjb7V++3tb4B/o/0v9+37sXetvfb1//1l1WkL7+ePv9sizrH25f/3r741f5
zRPYV49tDHsMrN0Y9t68tTvEvnvs09j2pay5eJrode37t7vop3nOgPDr5/lm5/l1accXMs8O+3qz
2N8yzwbb59lif8s8G2yfZ4v9LfPssO8e+zzPH7P8D/do8rtX+bZHt9u9L6O1HblF79+36Pp6YnU+
qK99h86nvh1XUN/7IMy3de0Sz2Hbf6KBXZfBfD0th3+4Cj489WO+1tVP2PIfzNq+sNwgLHeG3fyU
tR8YdvdTtrC9sPYA6AZh/y1uzEzZ4ads/S3+xmDvfspWuMBe/ZQtB5uyt8GUwQX25qeMbt53P2Xt
t0SeOmVtGUwZW7etRwm3bhvzCQo4+3JFwJlOVcCZTlXAmU7NgHMBNrbCfKwCznysAs58rALOfKwC
zgVYP2XUeyngVGuXH5kLV8Cp2CkBp2KptQo4FUuDuQJOxdJBUMCp2OUvaMoy4FTsyrRtBpyKheu2
tdAIBgujbvO7DGZObQuNYKyFY7uHRqjY7Y2thCM0QsWeqvA80pF291O2wCkbaY+FDYKy3ToIcPO2
kfqAK2EgP+Au25Tv1kHYWDqiGTsuKU9Mp2q+plM1XdOpqRYvwIZTnI+VWpyPlVqcj5VanI+VWrwA
66cM+oNVarFaS/WX1GLFQl+7qjxRsdRaqcWKnaIWK5YOgtRixU5RiwYLg7nKEwbLAk6qxYpdWaGq
SS1WLKyEplqsWLh5m9SiwcIpk1qsWCqZpRYrdofWXqM9mtRitZZO2Uh9wEEYyA9obarFOghQLW46
HalYuMC2gfyggzCQHztzNb1vxmowau1AftAp0+nI/CkbyA86CAP50djpyDaQH9TakfxgIXJTsapO
GVwJcrevlxwMTKfK2U6nytdOp2aqdwE28ob5WPna+Vj52vlY+dr5WPnaC7B+yqCbyVSvWkuTJ/na
iqVZjnxtxVJr5WsrdkqqV7F0EJTqVeyUVK9iN6Zo8mCgYuG6zVTPYKFkVqpXsVCEZqpXsXRsleoZ
LNMICuY9SqojcG5b2XSqgvl0qoL5dGoG8wuwERnmYxXM52MVzOdjFcznYxXML8D6KYNOMYN5tZaG
RwXziqVxTMG8Yqm1CuYVOyWYVywdBAXzip0SzA12RltZxcKxzWBesbAdMuu2FQt3WQZzg4XSQ8G8
Yqn0UN22Yid0ArblioR/PrX/8vf51NAI86nSCFdge8C5ABsa4QJsaIQLsKERLsCGRrgCe82URXH1
AmtDI1yADY1wATY0gsHCyLBGcdVgYUfVGhrBYKG16gR0WBjH4mzXYGkci05Ag6WDEAm/wS5/Zm1l
0QnosCwz19muw8Ke0NAIBkvPzeNs12DpuXnUJwyWroQ42zXYCScjbb2imDKfKqE03VYJpenUFEoX
YGNxzcdKKM3HSijNx0oozcdKKF2AvWbKJJTmWyuhNB8roTQfK6FUsdDXplCqWFhHSKFUsdDaFEoG
O0MoVewUoVSxdBAklCqWagQJJYNlTRkplCoWXlltEkoGC8tqEkoGCy94SChV7MouL6sJzoRIusAG
6mOG/touKVRNp2oEplOlv6ZTU39dgI1gPh8r/TUfK/01Hyv9NR8r/XUB9popk/6ab63013ys9Nd8
rPRXxUJfm/qrYmF4TP1VsdDa1F8GO0N/VewU/VWxdBCkvyqWFlOkvyp2ZY9wpP6q2AXWv6S/DBbW
v6S/KpYKJemvioUrQdR+WDi/PSdmbS5VimY6VYpmOjUVzQXYCI/zsVI087FSNPOxUjTzsVI0F2D9
lG3MzWjj3i9JRaZTtXGnU7Vxp1Nz41bsjOl6ne0RdcownarpqlQ4Av0d0fu23TMm9JdFyROgjwci
jr65HJVVJe799MZR2YMLfUgtlfVEv/oRWNlTFm+DEWBP/PTHq+0IsIrXuvQTRzNdsNjTX0i12IWt
gnV981i2DNY22F8sr4n3MN3YQu299gfSLRYOQvcvFgunLJ4vNgtsgc9Mjlwiq9SuI58Id9nIKbLk
bh15RThlb94nwAx3fe9dCG4lwHU7coxw874PXA1bt20Z7DLY5rIOxpat27b6AAnLU635BbbCQYjc
xiywlWULbeDBVhbP2zGYMrYdWr9SbAeBaZr+BQiLhbGs9TtTzlq6wF590IF3BNrrwCfAXfbmfQKt
ekUTpNsOTN/3z51YLHzgees97M7axqzVYxZmEOC63frXOpy1cN1uzQ8CfGBwGwhROrab32XwgcEt
KuFuylh02PqXfywWLrDDTxndDsfA1byjdtjtPli3cGxfL4ll20jfwkEY6Vt2JrK9D1YCE6Jb1Orc
dmBCdI+nJg12Zdbu8XiQwULHuEcvu8OydbsP6gnwJZp94G9XlpzuA30Liyp71O7d2DIhuvfTAIeF
xbU9Th6dtXAljPwtxI5kM0tJ9v4JKTsIcPOO3DjLdPZBmXVhbnwf1VnhlI30LSuqHAN9C4XosXix
tLGxPfrnzNwC2/hnK7Zer5l7th0nOfOpcZLjqMyHK5ibEWDTpYM3ZyzFRjA31rJVoO8kGSz0B1lu
N9ayjbsq6hos01/9Q6J+bKG18RKgGVvYS6UHLRyW+do1egAdloVHPUR8ATZ6AB2WlX/UA+iwLOqq
B9BgGysERu/E3k/35rvw+dRw4YYK1X24cEOFCb9cuMOyeKNP3TksPHmKpieDhQVWuXCDXeAghAt3
WDgI4cIddoILN9gVBvNo4zZYWASUCzfYhZXV5MINli6wcOEGCz8eJxdusDTqxnsDBgufMVAbt8Oy
KdMDgxdg470Bh2W5rt4kclhWBNSbRA7Liilq43ZYeDsviikOyxyjvjzksHBsB9oDRl5do3PWsqCj
Lw85LHPjbSQ/WE6mt+SdtUyE6vjNYdnm1ULoRdYLROh0qkRopc4QoZUKI0OKUINl3itFaMXCuy2q
I0St/fMyYE4xRWjFwjK76gjGWrgQVEcwWOgU9b1lh2VOUXUEh2UBJ0WombIJdQRnLU34Q9EYa5lT
TBFasVTbSoRWLNS2KUIrFqZ6KUINlk2ZHsZ0U8ZSvRSh1doZbzk4a9kuSxFarYWuRm85OGvZ5k0R
Wq2FGaSkR/1sB9wNcYSxT6dKelTqxjSdBGilwlWQ0sNgYTCPfgQ3sqwKmtLDWMt2WEqPiqVCSfWv
it3ZIGgr1EfvZ2yF6VRthelUbYXp1NwKFQv3barwiqU5g0rBBgtzhu657/t8rLZCxcKokCrcYOEg
xGmeGQSoD1KFV2sbPNKM0zxjLb03Ei96OCyTdKtKwWYQ4JFmdF0ba+kCkwqv1lK5vPgpg5EhVXi1
ll7wUCm4YhtUivGih5kyqGiyFFythdshVbjBssw8VXjFNrbLUoUbLNOgbaA9qLXS4dXajQmlLAVX
LP2swkB+wE9WZCnYWMty3SwFV+zGBL4+K2o2Lyyr6cqEwcLIq8+KGizsAtx0El3HFnZdbwP5sbGD
wk0n0dXajdW/tpH8gNYO5AdslN8G8gNjfSyDucM2kh/sMGsfyA+Ykui2gNtlTI3vA/kBd9k+kB9Q
Me5xjcoMAvRgauu/AKuT6OoTYEqyx4NixlqowfaB/ICKcR/Ij8ZSkn1U/GCRdx/JDyZEj7iYZKYM
piSasT4Qn88KmbzVhE2nar6mUzVd06lZrKpYGHCyWFWxcONm3dZg2TLIum3Fwo2bR8YVCyNDFqsq
FtYS8si4YqELz2JVxdKVILVYsbQdUmqxYmk7pNRixdKVoGJVxUJfq9bziDqfnS0LOHlkXLELa33K
YpXBQmulFg0WVj6kFg2WZTlZrDJYlpNlsapi4brNYlXFwqCTxaqKhReTslhlsOywMPsWDZbFsixW
VSyMZdm3WLFwJWSxqmJhLMtiVcXCWJbFqoqFsSyLVRULY1kWqyoWxrIsVlUsXQkqVlUsjGWRN8Td
3c+hjG2yyBvmU/svfwE18ob5tipvMFjowpU3GCxcXMobDBZKD+UNDsuCufIGh2X998obHJYdvylv
MFg6ZVFldlhWBFSrqcHCyKD7TgYLDwZ0yO2wrEajVlODhb5WeYPBbmzKlDc4LNRf8SaNwdLnBiNv
uALrAxn0t8objLVUMsfjMQYLfYLyBoOFblx5g8MyN668wWGZG1fe4LDMjStvMFg6ZSP5wXyC8gZj
LXTjyhsMFrpx5Q0Oy9y48gaDhW5cktl87W6CZJ5OlWSeTtWanU5NyVyx0IWnZK5Y2EaSkrlioT9I
yVyx8DvhKZkNljnFlMwVSwchct3DYJlTVKndYZlQSslcrYW+NiVzxcJiSkpmg2XuKyVzxcKyWkrm
ioULLCVzxcKymkrtZoHBgKPbWQYLV4JuZxnsxlZCSuY6trARTqV2Zy3TCCmZjbXM1aRkNljWUJSS
uWLpW+2q11Us3LwpmQ0WLrCR/GCxLCVztRa+CZiS2WDZIKRkNljYxRrXUtwuY1cnVGo3WJiYqtRu
sLAPX32hDss2r/pCDZa+Jx4n/QYLH0Lb4qTfYGkXa5z0OyzrAdvipN9gabtp9IUaLExJ1BdqsLCq
pL5Qh2WOUX2hBgs1mPpCDRZmOuoLdVg4CKrYVX9LByH6Qo21tIs1+kIdlmU66gs1WJjpqC/UYKG+
VV+ow7LIq75Qg4ViSX2hBgsX2BEXxA0WZjpH3Io1WJjpqLRWP2Q84cr1MZ2q0tp0qrTtdGqW1ioW
xrEsrVUsXLNZWqtYqBaztGawzClmaa1ioVPM0lrFwm/l5Gl0xcIrKVlaM1jWX5eltYqFH1nI0prB
spbILK1VLHSKWVqrWLrLpG0rFu6yLK0ZLNtlWVqrWDgIWVqrWBges7RWsVDWZWmtYuHxW5bWDJYJ
pSytGSys2EnbViyMZVlaq1iYk+VpdMXSdTtQH3TzDuQHVOJZWquDAENkltYqFobILK1VLAyReRpt
sCxEZmmtYmGIzNKawbIQmaW1ioUhUnlDz9Av6GKdTtXOnU7Vxp1OzbyhYqGvzbyhYqFTzLyhYqFT
zLzBYJmiybyhYqFTzLyhYmGVOfMGg2XNWpk3VCwUSpk3VCyMY5k3VCz0Xpk3VOzKznIyb6hYunmV
N1QsFUrxVsJRsdAnZN5QsdAnZN5gsMwnZN5QsdAnZN5QsdAnZN5gsMwnZN5QsdAn5JF8xUKfkHlD
xUKfIEVzv+ReznSqFM10qhTNdGoqmoqlTlFl9oqF3isVTcVC75WKxmCZ90pFU7HQe6WiqVjovVLR
GCzzXqloKhZ6r1Q0FQu9VyqaioXeKxVNxcLGjFQ0FUs3rxRNxU5RNBULfUIqmoqFPiEVjcEyn5CK
pmKhT0hFU7HQJ6SiMVjmE1LRVCz0CaloKhb6hFQ0FQt9ghRN/+L9BTWa6VQpmulUKZrp1FQ0FUud
ohRNxULvlYqmYqH3SkVjsMx7paKpWOi9UtFULPReqWgMlnmvVDQVC71XKpqKhd4rFU3FQu+ViqZi
qbXqW6xY+kUEKZqKhXee8my3YqFPSEUzH6ubxhULHWMqmoqlajHeszwqlo5tr0w4LPS3qWiqtXA7
pKKpWOhvU9FULPS3ebZrsMzf5rWJioX+Vi8UmQUGpyzPdqu10N9KLb5fUv+aTpVanE6VWpxOTbVY
sdAp5olexULvlWqxYqH3SrVosDPUYsVC75VqsWLha7ypFit2Z686pFqsWPgxgFSLBsv6EVItVix8
8zrVosHCBSa1WLETfO29H7/Nz8znU8PXzqeGr51Pla+9Attb+i/ARkv/Bdi4UXgBNj50dQE2vjRx
BdZPGY268QaYsXZhb7DK1xosDeZxo9BgqbVxo9BgaRwLX2uwdBAiMzfYGZm5wcIWEmXmBgsDjs4a
DBY2biozN1jYuKmzBodljZs6azBY2LipzNxhmVBSZu6wrEdJmbnBQseozNxgaY1moD6gB1NmbqyF
rkaZucFCa9V1bbDQ36rr2mDpIAzkB/S36ro21kLHGFWPe7ui6jGfqr0w3VYp8enUVOIXYC+ZL1U9
5k+Yqh4XYKXE54+tlPgFWD9lMOCo6mHGFvraVOJmEFgwV9XjAmulxKu1MDKo68dYCyODnhYzWBgZ
dEbmsFAtxmu8DgvPGuKMzGDpWUN8xcNg4VlDKnGzwOD3S+OMzFgLH49JJV6tha4mlXjFUm070B7Q
g6USr9bCzaszMjNl1NqB/IAeLJX49EFIJV6x0IOlEjdY5sF0/9FNGfNgqcSrtdCD6f6js5ZV8HX/
0WBn5A3bJRX86VTlDdOp2rjTqZk3XICN8Dgfqwr+fKxS6PlY5Q3zscobLsD6KYPBPPOGai2MY5k3
VCyMupk3VCy1VnlDxcKom3lDxdJBUAW/YmHUzbzBYFnUzQq+wbKomxX8ioVRNyv4FTslb6hYGHWz
gm+w8O3geBPQRAfoajJvqNZOyRsMlp1BZt5QsXDzZt5QsdCDZQW/YqEHy7yhYuEgZN5QsdCDZd5g
sMyDZd5gsMyDZd5QsdCDZd5QsdCDZd5QsdCDKec/LjlvmE5V3jCdqrxhOjXzhguwIULnY5U3zMcq
b5iPVd4wH6u84QKsnzIYzDNvqNbCOJZ5Q8XCgJN5Q8VSa5U3VCyMupk3VCwdBOUNFQujbuYNBsui
buYNBsuibuYNFQujbuYNFQujbp43VCyMupk3VGxjp3p53lCx0NVk3lCxU/IGg52RN1Qs3LyZN1Qs
9GCZN1Qs9GCZN1QsHITMGyoWerDMGwyWebDMGwyWebDMGyoWerDMGyoWerDMGyoWejDlDf27Ixfc
GJhOVd4wnaq8YTo184YLsCFC52OVN8zHKm+Yj1XeMB+rvOECrJ8yGMwzb6jWwjiWeUPFwoCTeUPF
UmuVN1QsjLqZN1QsHQTlDRULo27mDRVLP0auPqWKhQEn84aKpdaqT8lgoQiNu/zG31LJrD6lai3c
Dpk3VCxct5k3VCy1dqA94ObN84ZqLR2Egfqgm3cgP+B2yLyhDgLcvJqxt0uqzNOpmq/pVE3XdGqq
xQuwIT3mY6UW52OlFudjpRbnY6UWL8D6KZuiFqu10IWnWqxY6GtTLVYstVZqsWJhwEm1WLF0EKQW
K5YGnHid2/gE+AZFVpmrtXBsUy1WLHyDIqvMFTsjPL5fUkyZTlV4nE5VeJxOzfB4ATZ87XyswuN8
rMLjfKzC43yswuMF2GumTM8vzLe2C/ArFpieX5hvrcJjxVLpoecXKhbe5c9LXxULXXgWUyoWfss4
w6PBsiOMDI8Gyz6RnOGxYuHJSB7CViw8GclD2IqF6zaLKRVLSz/x0TsTdOB2yOcXqrVwO0TC/7pe
kfDPp4aimU8NRTOfKkVzBfaS+dI19gusDUVzATYUzQXYUDRXYK+ZslA0F1gbiuYCbCiaC7ChaAwW
RgYl/AYLc10pGoeFd6Ij4TdYGszjeMhhYetTXGM3WPiMoxSNw8IP48bxkMPCD+PG8ZDBruxBTyka
g4XbQcdDBouFkneMcJfpeMhYO0Mo9Xg2v4/mdTpVQmk6VUJpOjWF0gXYWFzzsVH6uQDbDb0CK6E0
fxAklC7AXjNlEkrzrZVQmo+VUJqPlVCqWBgZUihVLAzmKZQqFrpwlX7M5qXlCQmlai38MIhKP85a
WlHyu4yeOkkomUGAikZCqWLhuk2hVLFY0YS2NVh4y1hFmoqF20HU/ZLSz3SqFM10qhTNdGoqmguw
sXHnY6Vo5mP7cr3CWima+dZK0VyA9VMGvZc6g81KgN5LvR4Oyzos1ethsLR7QoqmThluIfFTBpPS
VDTVWjgIqWgqlgZzKRqDhcUUlX4qFo5tln4qlraQSNFU7Iyoe1xSR5hOVdSdTlXUnU7NqFux1NfG
tzVfK5b6WkXdioX+QO8GO2v/4w+3r3+9/fHr7U+3v9+Wl9f7223pf/0u/2d7e9na7TiW95e2tS8/
/O32L19v3QfoH+l/17c1HZa9sKevJRks/gjTYMqY98qoW6cMeq+MuhULvVdGXYNl1Xt9LclMGU34
o4XEYeECiw5Lg53hwl8vSZymU+XCKxV6RbnwSqVOcYn02WDhxpULN1i4FeTCKxZ+FCRdeMXCIlW6
8IqFRap04RX7vMOWl9ZDTv735x9+ffw5vsWf49but/vbx1fOezi6ff3x9vtlOdVR86CGvjPU9czR
3oO6e1shtTtyZ+typhb4sPXeT3jNCJxaag/qa/PUH05okAc10j1n658Z1Y/rekYvPWwN9+hsZSsr
gpmhbmdi5MPWdXmz2Aax62AVsDFYV7+9Fojtj1LbsWX7a+2q2mHhtl17UmqxcMr2LsLMAqPWxvmb
w54pij+t25HzOiMWnrCvAz9z5hzjGesdDV23r37KGtwOb94nLGe+IPY0CAMPdip5eGDb4t3tqQ/q
PWGvcTVt4GpOaecna7dLfELb/AI79VXnJ2v3gU9gC6wdg+jApEeLo37nwZj2UEe3wzI33l4Hm/fM
lYGnKXsbTBlzNe3d+9tTecnD2m3xkfdUfe0Ju3prFxYdtnWwwJj82NrAMT6FyCjxLbffkpY9yoJH
jHGfP7XE7Swte6KGxzHUM0P8oN5j9Roqe7isJ76WembeHra+Dmw9I5geVCVQdQTW9xMJ1IPav3Du
RuBUuvtEDRdmbD3jax7UdYnwULGnZM0Tdt099kzUecK2wfY6Ex6esBIKZhDYTlB9yYztBgdBqY6x
lu2FdR9MGRzbkUc8I2uepqyXvty6PRXMnrGDQYArYeRq4Up4jRhpVgIc27eIkQbLXPg68IunUp2n
KXsfTBkbhCa1ZAaBTVnr9wrt2DI33qLw7qbsSdacOORs0bHksMwntOhYcli2y9o2iGVwygaOEX9f
cRDL2C5rx0ArsujQVFqq2wH62zZyjHDdjhzjmXzv4WpafzzFrls4tm8DDwZ32ftggcFd1u9bu0Gg
K+Hdr1uI3VQIq+sW6ttNSa/BsgW2qb5msCyWbW2wwJhj3FTKN9aeqQE9dtmmQ0iDZbtMT1SboAPT
Mj1R7bDsAuumEwIzCHCB3Qc+AU7ZyI2zWLa9DtYtXAmqBpqxZUFne/Pyg3qwa2TzNpLNcCUM3Pip
auDDJ+zLQN8yx7iryGhWAltg+zqIZWw77IPqB7zUvm9RwK2DcKrc/DRlcX/AYdku2w+PhVnkrm6S
Ogin+j6eBmEkm1l02HUia6xlm3d/HXgwaO1I38JdphNZMwhnGlUeU3ZEx51Zt/CtyN5I7LFM5B+j
xJ85xmOQ+MPHGI7mi9hw8x4jIcoynaN/sNCuBCabj31Q/WDb4dD5cd0OUH4cI3/L3PgxKlMwfXvc
B4oR+oRrjp+OwfkTTE6P6Bx3HgyuW7Wq1AV2ql/n4W/vy2DK2AK7q9nOWMv87V2tKgbL/O195BiZ
tXH28t5P+D6fRkNjexXMUHd2atqv3zjqqR6gx+oKRWNsXVhkiBYzQ92Yvo/80VBh83zkeY7KegfC
Fxgq9FxrPNvlsMxzrXF302GZXF7XwZJly0C3HZy1TB+s8bEYh4WDsPn1BeXyug9cFxyEuIpgBgGK
pLV/os5iWeK0HoMFxg4Ldb3ODAJ0iuvAg8OcYY1c9wJro7bosHA7DEIDdOJrdBpeYG0cETksEwht
8dsBpnktlKKzlvnbFmc5DstWQouzHIdlGY6eQHJYpr70YIDDMlejI3mHhWMbtUWHhYMQtz0cFk7Z
MVi3cJfFWY6zluUMLRo4HZZF3jbyt3AQ3vwgwB67Fim0GwS4bgdiHMpmdXY7a5ls3qJXyWGZv9UH
kx2W5WRbZOYOy+oIW2TmDgvHNnqVHBaObdQWHZZt3i1qiw7LtsM2qk/AKYveUGctHISoLTosHIR4
c85hWYK+RcnSYZm/3eLxBIeFYzvwt/AMcovTaGMtbPDf436wwcJa1T5SjGyB7fHElLOWLbB9UE84
dU/8UbDbo/vHWcsW2D5QjPBJmT16Q4219Ej+8G4cboc9TqOdtczf7vE+r8HCdG8feTC4HQaKERas
9mjTMYNw6sbt03a4ptB6XFNoPUaFVrZ5dchtxhY+6XdEP43DshB5xG0ih2XS7hg4Rti/eMRrws5a
5hOOgQdbmGw+4kNSzlo4toPSJczLjsHpU2Nl4SPa0N0gwF0WbToGC2PZES+/GCysNh/vgwSKLTCd
RjtrWR3sPqoxMldzj0ZDZy1bCfe4JO2wLPLqkNthmRC9j1JpVk+4xzMPzlroaiLmdEX+6Uge6tDo
XnRUuA7CIRhbWYFRhUBDZQFHzqtSoQaNFkMzAlB4yCMaW5kz0Guvzli2YPUYlsFC3aFXqwwWyvA1
rro4LAsLerXKYeHYysfMXwkq1xkscwdrtAKaQVjZ8ciqc4xqLSzS5LlxxdKXdOPyiBkE6GhWZaXV
WqiSVpXrDBZuh5EHYyopz42rtbCDQI9huSmDp4XSdNVaeGWgSdMZLIsOrUVdzWCZT2hxecRhobUD
x0hXgrqKzCBAa9X+Y7Cs61h3ri8YWzXUGGuZT2jqfDFYljS0kbBjkVdvbLmxhdshLkc7LLM2D3jN
2DIPlge8BsvceB7wGizL87a4k+LGlk3ZpnOMai3s2NItZmctXAk6cKjWQvmx7V7VwLR0GylGOGU6
4K2DAI9HNnW+GCzLTDeV6yqWTtnIMUJr1RJorGVfPNrVElixz4+in3igZo/nHdwuYwF9H0k75hh3
NYzXQVhYiNxVrjNY5mp2nWMYLNu8uxrGDZat230k7Vhyul+TSusWs1m3MOjscavOYGG9alfni5ky
OLbqfKlYOgg6N67Yxr5tsY/8Ldxl/S6Zm7IGd9lIiFKsX2Bwyo543sGtW2btMXLjbMqOkRtnQeeI
T3q4QWC77Bhk6PCy2rF5xUiPTHVBp25e6MF0i9mNLVxgg3OXxjId3WJ21rITrSNe6XFYuB0GBzrw
yZfjmorocU1FNE+567qFjwTe4zEKN2Vs3d7V/lOthUL0roZxg2XSTl3C/ZD305HpqW9wPDqrJJUM
lZVUtMUqFR6WxXOG79Op8cyrocITOOmZait04Or2MFSWOeWRqcGy7ZXXmA2WOdo1njRwE8aW7KqL
E8ZaluyuOnAwWBYb13iUxQ0CnDIdOBhrmaZblT5WLLyetOpGWcVC/72OfCIchIFThL2A68ArwvO3
deQW4SCM/CJrpll1w8GsBLYd8sjUYFku0nRxwmDZ2OZVW4Nl/raprlaxMJjnkWnFwrirzxI5xwiP
9QYeDKqvNvJgcCWol8SMLVwJqlQZLNxlujhRsbCa0uJZqQtWgu5oVWuhv2264WCwbGw3ZU4VC1/6
2JQ5VSzcvJsuThgs87ebKlUGyxoTNpWUDBZO2UjaMZ+w6U6ssZY5xjzbNFgmmze9+WKwLIfe7lFc
NFgmP/RCs8OySlVeXjXWwilT7adiYZFmUzdcxdID3oFjhO2WeXm1WttYiMyzzYqFt0f2URYJD3N0
CFmthVO2qyhusCxD31UUN1g4ZbqjZbDM3+66o2WwLDrs8cVJ52pYCWhX04exlpUpdrUJGywcW70R
aLBwJYw8GLNWTym7KWMrIS+vmkGA1o40GAs6R6+H23XLdIKeUnZjy3TC0YfVWst0wqG2NTNlTCfo
zWM3CHDKdKxXrYU64dD1+4qFQSeP9QyW5Q7H6yXV5ry8Wq2Fnd3HNVW7Y1S1Y/72eI/D8zoIcCXc
45t1DstC5F3dGcZa6GrC2N4g+vlYjxkb381xVLYZVFaqtsJCjaRHpcK6uJSHobIlq9SpUuG21f1K
Q2UX5HVYWKn0dEQVJYNlsmOND0O4FctEUr55bKxl2yvfPDZYJpdX9T4ZLBxbpXkGy+pfeapXsfBd
h7xfWbEwKqxSMwbLUui8tmmwcCWMnCJcCdd4xbxfaQYBWqt8zGChT1BFyWCZtU01cYNlKrwpHzNY
ljg1tTsYLFMzTe9EGixLnPIBXYNliVMeFhosnDIdFlYsTJzayIOx7aBP5brIy7RiU7d8HQT4OmBT
PlaxUIE1dVFULOzjbcrHDJap0KZX1gwWrgS9y1uxsNSeh4UGy8rB2xpvXFQsfNlgU6GqYqH8yGub
BssulG3xDXEzCHDd6iuxDssW2KZX1swgwJWgCr7Bsl226X6lwTKdsOmVNYNlIXLTK2sGC6dM1zYN
liVQ+YCuwTL5kWeQBgsH4RrFuA8UI2yL3NUgawaBTdke31h0PoFth1332Y21TIPtI8fIdlk+oGus
ZQtsHzlGOGV6kcNYy5LTXc0ZBgtXgpozDBaO7SiVZvp2v0Yx7tcoxnyXt44tbOLcVcGvWNgHdvSP
9VlXw3zCMVCMsIkzjzbNILDtcOhFDoNl2+EYOUYWeQ+9LF6thY2G+S5vxUI1fugTNwbL/O2hdl6D
Zf72GJy7QJGvC2Xd5346eYIPzqntpVJh2q/OY0Nl86Urm4bKpks3Ng2VbTCl/IbKopjuxxsqq6sp
KlTqzjxX3ierWHj8mEdEFUvPydR0bLBsaFeVJwyWra78LKbBsoi76rV2g4UrQcGmYldoraJCxcKT
6FWH8QbLUpH8fmXFQkm36jZGxUJJt+o2hsHC7aDnSAwWrgQ9/2SwLN6sqiMYLNsOTUfyBsvGNj80
abBsbJvKEwYLB0GfDTJYNmX5oUmDZRohPzRpsCxnaNf42zbwtw2eQaod0gwC60toA38LHWNT53W1
lp48qRxcsfDJ46bnTQ0WTpkaCAwWuppRdICbV33ixlroagZaHOa6Tcdv1Vq6wEZBhynGPNWr1sJH
f/JUz2CfeuGWl3b7+O/PP9x+9YOJx23pf/1uPW69z+p1+Wjl3G69+/LH2++X/id/uH396+2PX29/
OkPtztdRG6N23+uo65mt8RiBLnUdFdraD+IcdTnjdB62dn9+AbUXKhz1VDb5sLWrZ0s9k6Y/qL2k
4KjbGT/2RPW74FQ59EHtXszZupwJ6g/q2pu6LfZM4HnG+rW1nnGOT9juY6y1bCOs/VF8i4XW9tuF
Fssc19odrMWeyR+exraflVksHNuRRzwj9J+s7bVba+2Z3oQnbD/UcthT31l8wvbTJ4tl7mvt6bTD
Qk8TH8qwWOYWWz99cthnnxBCYrn9FvHx9ORaDEZ/DOhz3f3Miniixq4w1DNj8aD2Jj5LPeMZHtRe
d7fUM27sQe2lIEeFR0X9boalMlv73QxLZd1g6+KHAD4vvvabT9ZaVqxYFSTrkj2lFh/LYO3fM7XW
nhHMz9jBILBtu/a7GdZatm/XfgXfYeE7BHHlw2HbGXH3NLZS+HUlwKPItaeRztoV7jJpfGMtxPZO
O2ct9F/ryC1CaxXS6yDAM+kM6QbLtkOUsu3YntE1j3Xb+qU1i2WOsfVOO4elBczeaeew8E3S1j+Q
YLFwEAYe7JRmfJoyZQ9mgUFrVfkw2DO5zpO1KlIYLItlbeAY6eYd6Dr6NJqqH2YQoE/oxWG7bplj
jCquw8LvLsRDbg4Lo0NUcS2WbYd4yM1i2XaIuxkWeyb1f+yyrV9as1im8TfVP8y6ZcnT1k/NrLVn
KmFPgzCQdrD5YeuX1py18C7c1h8RcVi6HfpsOeypovDT2PZeYYs9U1t6xvp1Cw+Mtn4Y56ylY9vf
TrBYljtsvdnMYpkH21UEMpuXWburgmuwLOjE+3BXDEJ/itJimWze94FiZKl0fKTKWst0QnykymGh
T4iPVDks1Lf7SNrBQVC92axbOGX9I1V2EODmHbgamEDt/T0CZy1cCfE+nMPCvCwuUTgstbZfonBY
2C57jBwjWwnHyDGy7RBfk3KDADtAjpG/ZUL06E//OmvpAutfS7VYFiKPUc4Lp6y3bzlroU84RsXA
p36VX92g8pB2x0iDsch7DHJe6hMGOe+pM//HIMSLa27KYJniPjp3YEWVe39R5QprR8kpWwn3fg3M
WssC+n0g7eCbUP2q0uvSy0Cfj0yZS5CjqVR+VcnZujCFL6FUbd1Y0q/KWqXCXv/eHnnBCCjPq7bi
s82I5BULfUw8Z2exrFK19iZ3i2WuKy4VWSxzBqtclxlbtm3X7RJvsKrRslqLzzb92OKzTb/J6Nmm
CmB1EChWJwMVC0tKa+9Gt+uW+dpVKslYy3KRVSrJYOF2GDhG6MGyC8pYy0r4TemjwTLHGNd07Epg
mVNc07FYVsKPazoWyxZY09mmGVtorc42DZat27imYweBbd64puOw8Pwt3p1zWOjBWn+1yWFhQtbU
9DF/ytQMZ7BwgakbzmDZ5t3U9GGwTCxtA2kHpXhcfHErgZ6/qRvODAIcWzV9GCwcWxXAKhZuh/j2
lR1baK0KYNVaeHUvPqllrYVTpgMHYy0L6NtAMULHuPX7i3YQWEqyDRQjjA7xnJ21Fo6tDhzMlMF1
O1CMcJflkWm1Fj9n5zdvY/IjnrOzUwaxAyEKr0XuI3/L6j/xSp4dBLbA4gNgFsv6HeIDYBYLp6y/
kmexcBDU+VK3wwIHQZ0vBstyh33kb+HYqvPFWMvOiPaREIWDMBKizNpjoBhhSfgYeTA2CIfahM2U
sQOHY+TB2AI7dH/CWMsi77H7dA+GyGPkauACu8YnHNf4hGPkE5i+jW9fOTdOz+TfLtEJ8Uktay08
N34fFKzYLrsvfmxhs9J9HURe9h74vT+95sYW+tu7Xo2orgYm/jrb7G90fDrbhGdw/e3y18VQWXGt
v1XjqPAMTm7G2Mri2GvsBENlhWYdDRgq04pyBobKdm1/3NGOAFsDq3yBMZZN17qGQzRYluGsKqsZ
LNMHecm0YmFb+yqRVLGwmJKXTCsWqplVIslg2RZbJZIuwHrnBc/J8pJptRbWbVedmBosK7WvPXzZ
XQY3r1o+5lurQpXBMr/Y9JaMwTIn3tSuZrBM1za1qxksHAQ13BosHIQWxxgGy6oeTT0fBsvWbVO7
msHCsdUVLYNlQacNpCJ0422kFVlS2tQZawYBTpk6Yw0WTpkq+AYLN68q+BULk9LWiXaXsUHIS6bV
WnqgpYNYg2WuJg9iDRYeEanHzmDh2Ko92GCZWNp0wcFg2brddBBrsMyD5UGswcKVoIPYioWOcTvi
vKFi6XbQQazBwrHVQazBsgRq080vg4XW6iC2YmECtY3yc7h5R/oW7rKRvmUZeh7E1rGFZZpdxxgV
CxOoPIg1WOYY95EQZa5mV0egsZYtsDyINVimwfLE1GCZBtv7d26sY4TWjjwY3A46b5g/CDpvMFh2
TpZHmxVL2x30XlPFwsrSrhNTg2Ua7LimxngMaoz0DuAglYbyI++umrFlC+wYpNLU2lEqzfxtfADM
uhrmwQ71NJuxZeW1vLtqsCw6HOppNljmGPPuasXCZrhDD9lVLHQ1h3qaK5au22sc43GNY8yD2DoI
MCW5660Ag2Ui/z44fIEi/66e5motfPfmrsaXioX6Nop2a//mzafzXRhzomZnqNDWON91VBZxohDo
qCwxjZsTjspSsnAyjsriQvgYQ32+Ff2n/wNb2FYACmVuZHN0cmVhbQplbmRvYmoKMTIyIDAgb2Jq
CjEyMDk4CmVuZG9iagoxMjAgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0IDAgUiAvUmVz
b3VyY2VzIDEyMyAwIFIgL0NvbnRlbnRzIDEyMSAwIFIgL01lZGlhQm94ClswIDAgNTk1IDg0Ml0g
L0Fubm90cyAxMjQgMCBSID4+CmVuZG9iagoxMjMgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9U
ZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA4IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczEKMjgg
MCBSID4+IC9Gb250IDw8IC9HMSA5IDAgUiAvRzQgMTIgMCBSIC9HMyAxMSAwIFIgL0c2IDM2IDAg
UiA+PiA+PgplbmRvYmoKMTI0IDAgb2JqClsgMTI1IDAgUiAxMjYgMCBSIF0KZW5kb2JqCjEyOCAw
IG9iago8PCAvTGVuZ3RoIDEyOSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB
tZ1diyXJcYbv+1eca8O2Kj/qfIDwhYQR+E5oQNf2Wishdg3r+f/gjIg+XTUdb2qn6znHwmjV7Dwd
E5kZGflGZNavpz+ffj3V62urp2tpr+fr6ZfTel5fb+//++f3/315LWtdyunn+x/48IOXN8LPp3+c
/vpvp/89LeM/6209XXs9/d/fTn8dP/rdn76W09+/nn73x/HfP349La/npd1qOat/evn646lfX+v1
errcLq/rWod1/fa6rOfxg/Pr5dqHMWtfX8v4p29/chv/8v0P/fxGedl+8I/TT+M33pr/n/wn+93b
r1qGheN3341ZX2u/vsTvjt/kP/lgjf2h8bu/pZh37Henv/fL9jP59/7mdyvu7hcNzwzr3s0N391/
82/8rT/685eX7Sf7v2X+e3/r8+1P3UfqHy/yL75zxu4vXm6vtzGq24CPH9g8eR/wl8s3P/Ff/vaH
tr/6+w9+c8B9sr0NVbm+9m5L4e7BcrGlsRvv/Q988r39kftwD+OCcXd6Gu7f+lu/Dbf/IhvLb03b
/eDulndbw3H3X5xGe8yz+8+Gu99H6c2ZY/nf19P+7xjeTV7wX/W2DsINd2smk1z+rc9teb3exgJ7
eftb2g9KvTvcwN/+xKy5/6H3sd5+MH737i+5/XW3f9oW97neXttubZ9HMFxH9Hsf65dvf+LGxJ95
H4M3xt3j/2KodxHtbu77JNt+z90LH3/Nu1diqF/uiPsvvg/r9vfc/mk31PbHzLvbUL/96l1A24yx
6fCtv+8T5M65//r095YRrQ8Hl75b2L1eXttlt7BP3/7EfvnbH9pi2p1y/92/8Vd/82iv5xF3t4X9
0uv6+r6JxC/a/cDG+v5H3gd7+8E3U3z3d1Vx/G7v+2i//+YPpt1/zzDt7pa3hX1HfOdf+T5Kb5yX
bbTff/V9aMUPYozeY+1uSCKIX8dCjv8fE+syYlU/1WX8aATodum+M49Bfm3Dg2Pn/42wv1sVxf7w
spsd5dJGuNrPjm9/YoN2/0P3UPCy/eA3w/5pCwUGLp4BvXm8XOqr7aN3P/n/3jag8XvjD9zHbPeD
b+bGFvR2s8R+b8T4u7Xvc+P+e96mhvw1wyfbargTPjk17p7cdvj7b1Z/4289fZ9ed8b9V59fLOuz
aFPr662MJOwyso8xDWp5XcfAlvFfng3+dCr+n/Gv/jocdBmOtz/5Q/xjpKQjCl0sC3j58ZfTH76c
iv0L418Z/30eEeRSLuX05ZeRUxrpy0+n3y/LUv799OWfp//44ontAexFYyvDrhNrG8Oeh3uVEzrE
3jR259sR43ws9gM91r9lvPuBfvHF//0DfdIDXS/1hQy0wo6BVtjPDLTA2kAr7GcGWmBtoBX2MwOt
sGOgFfZfD/S5jLRi5A/7gY4oX15sqL9nRQtjbEW3cdSLgR6kAytaYcdAD2yaPw8YaIV9wEAr7AMG
WmH/9UD3ZaQBIzN7wkCfxybwhIEe2GcMtMI+YKAV9gEDrbD/eqDLOrKukWQ9YaBv16cM9MA+Y6AV
9gEDrbAPGGiF/Wag60is4v+/Jybfs6z1LctaT3XobOU+gO09yWrnA/nFRm2WY2VqZdReJLV8Zviy
B7qlQg+3dW2SulyRX1ftV0g9a7/W3UT77vx9mwMjc1d+Xdhojb1KUlfk1zH8kvo/jDqxla2CobZL
W/+GbC3j4Kaw5cKwdjwUqwvO2DIOIRILrR0ah8SyESttEgx+ZL4dNRdpLYsxpWvfVrbEyiR2FRZl
yllbW/6b+faid4UCV5nVudRy+EyqkLewMpR1iWVDVhc9wfYxIfSaz+Qe7S33aEM/GmfT0uKUMHSj
t+NguR0Yuo1qu5mifuY0eHfxjmqnfmErpJpEkanLkXHbbLWdV1ALo14XSV2O7JGbrdexmwlblyPr
bKPeJrYeyT121BHGla1HwvhGLaPerrCH0to91pSfh8+tMogKWxa0aEvVTligb+vECUc29J1v7Xzz
BN/aAUdg9/H2uxPxnbWrxi4szpZ14tv/YjPhoneF5SeGnYWvI3nCzre2oYshg/Gr3PQqgxtDuel5
246kH5sTqp0dhBNgTKh2dlBYtufWMtly2HKodTJkbILVNlm8cMjaZN6yHKHakUQNGcROIlhloabO
UkU4Ey46+ygsgtWLXrwUOwq3ashgqPGOPjETYBivdtJRWLbK2iSCQSe00YjyDGtN/VBOYMlSM/VD
YY/oCdvu0GYR7IhWs8dO0g+W2rWuV9kCJ9g62XSgtefJpsPibTtrJ8ANvV0mTmB7WTP1Vs1b6ITr
ZJVBa2epHTubtllgZFtkX/QqKywm9DKZYCy161XvvHDxjra8Z0ywPjry5bxlE6w3PWRQqOnWvKFW
GVNqupXfFJYthz7RFqGe0M96gkGtpo/OOOkEFsH65CgNj3vdtHExZHB36NfnxISZFsiS/H6bDBnL
E9blKZvOOlHt6k61u/cR2H9/Rs/fKr7WS1Cvb3r+Q3sJBPUBvQSKemT4Ng94MMsegLZaL4GwFdZQ
rR73eKofqbMHDjXtbn71QCaoR+LjjmpL+OFUP08L6pHjzmbruK+ibK1HcoWNWhbbz7Kxe8WZVvha
6U+o8Akq1FytkPx4qtXiBBXulbYDC+qhjp3tSG0HHkFdjsyxjWrnHUU9snZ31BG9BBXWOIttvwIL
hUZvVxFYWOkudZynFZYJjcXOJc/A6kkLNbbSJ/MLOsEkZ+EEeJT0opnCstVQTAdS2CPpzLbI7OKJ
xDKhsUzC16GEZmftLH4d2Xl32Ns4+CrfMunOm2sUlg1ZHTennmFtGbmSspbN21p1qKFVgqadAPfH
amX/JzjByv4Ky5SVan18CgsnmN1/ElioCFa7/ySwMN5Wq8UJLMy/6mWyHFgzlGXiytpDPdNbBKuz
wMjCeJ0ERiiGNes6FEMG84Q2Se2gLNrKZPEyJbuVSbLEFm+rT4lgXuJTQ8aKD83vC+bjI4wJzbTh
J1h71tk43MvaZRIT4Ey4TuYt23TaLNSwPKGZiKuGjEWwZiKuwMLdoc9CDVsO/TkxYbweIZ0A4223
sr/y7ZF+/20v622yyliS32enSLYc7Ikh5QTq21kEYzHBq1tqyHZVggP9p17dElh43OvWTaCwbOft
sxyMRTCvbglraS1uloOxIVsnOVhhvl2XyZCxWpxXt4RvYZ6wWk+6wrKZsE5UO5jkr9akoKxlW+Q6
7oxLLHRCn2zo7AA1nqzR1sJ5axU45VsWb1crliks9O0kEYVZzTpLRNkWuc6O0hA7CePUCTc9ZFBZ
WieJ6L4+f2DnPU/COEw/zrP8lqV2Z2tSUMuBLd7zLIzDxWuHyHG9yJ842S4vLiwPtf4iRWWLwQOC
sJUp2B4PBJX51c+lgso84MdSQWWR1k+lgsrmgMeCTD10UXo7OBWPBRkLY0FUTAWWbeTFZTWBZbGg
+BFaYNmcLX6EFlg2vYofoTMW7mHFGkQfH2Tsxc+nYLW11AnW/iScADfycp44Ac4EaxAV1sIzQ9R3
8wSDHR/FUzqBhU6wPn/lBLh4Z1GcHZzKJIxD1aP6EVr4lu051s4rfctShOq5l7CWDVkdxGdY6/Vd
YS2bt9XruwLLOlSqNZuK5QAjWLWX9wUW5gl1ltmyPKHOUluWJ9Tn5LZ1ltzCCWaPaIghoyV579wT
85al4nUWGFlMiPqusJZ1L7ZZYITWzgIj23RsEqiZQIvcTWc1MAdrdltczFtqrV3hVFh2paitk7M5
23nbOknt4EzwdmaxHFioad5PI7DQCbOMkYWa5iKgsJZlNc1FQIGFMeE2WbzMCd3utqvlwGbCeDlY
Y9lM6Ha3XVgL1Q+/GSqwMKvpdmVeYVlW08fckliW1fRZfsvmbfeii1gOcIJN8ltaMZ3kt3Av65OD
P6yYdruJryYYq5hG7VwMGZwJs3jLcrA+O6HDCea1c+EElid0e2RJDRnb0KN2LqxlTljtgr+ylkWw
dXTtSSyLYOOLIxrL5u3q/eKP9+0kbYYX1daZfgudMEub2eJdvV88+xYeTlfvF89YWH9bZ/ktXLyz
/Bb6dnLwp40vk4P/vhr9mNvibaS8XkB96G1xQYU3sF3By7bWI0Fyu33rCY6gHjmdbFTvVcnUQ7rz
jmqb2sOp3gCTqfXIGWKz1TXBTF2YXy+2ownqERV3s9WvwgnqkVi+Ue1VSmXrkVxho3q+lG2lT20v
k6nFJkGxZx6VD45kd5sPij0xpLAsFBQ/SGbfHorkO2vt5XllLVsKxYU7Ye2RV6F21vqNtYzd7zvf
3QW1w9rba8oJbI1FqTdbu3874Yi19taFsHaPpU8y9JHvfuxbYr1b9haworJ03w6/inpkCW+dMJbi
KSrLxex1TkU9EnI3W61gpKhHpu6OOhktluTauVfZeiQobLb6h0kU9sj2sMPa48IKeyQy7rC2PSgs
m7LFHhdWWDZi3mAksPAGpzcYCSwUW/2lB4VlC7dYXUdh4by1BiOFZSGxWHKrsCwijG+8aiy7slas
7/IJ1lomqrAs2HrLjsKyxVvtAw8Ky+ZttQKMwjIn+KvrCgudYOm4wrII5q+uK+yRdHwL49Uu0ygs
W2XVLtMoLHSCdV4qLNvLqt0yVFjoBOsEUlhorbVIKixcDpaOKyycYLN0kWU11QRBZS10wlUnjDBP
qLOMkYWaZo/aCSfAwmEznUJgDx3Rt1DTZoGRDZk/ICGshWVOf0BCYGFq5w9IKCzLwZp95UJgYVG2
mRwssHQmmB4ssHTIZokoaytpVoAR1tKZYH1LAkudYOqtwML3oP3peYWFi3eWNsPAOAnj1AmzMM62
yG4XlpRvYeuDPZCmsMy33fpEFRY6wd5dU1horbWfCizcIv2hfIGFgbHP0ma2yrrdQVfWsjNvtwKc
wMII1q1WprBsi+znyaYDsbP8Fs5b+4qbcAKMYN3qZQIL89tu3+QQWLhFrpP8Fj40tc70BHbcW62h
UzmBBUZ/nENgK5PXvBNIYGEEWyeJKMVawUxZy/QEb9lRWBZvV+t0F9jCdDB/RUNhobWTMlFhMsU6
iWD78t53Vw23U+RqLZLCCTTUTIRWuJf5uxTKWjZvz7PUDg6Z5aGjx/lDxRR2pFsbsqDC/jXrQlZU
dtbzHCF7YGGJkl3nVbaydetHJ2Er28V8HQgqm7D+JoNyAUu+ivX0KiwTF4t9tEth2fLyV+wVlo1Y
sdYXhYXWuvYjZgKbtWUQn2Gtn0WytTB+Fz+LZCy8uFdc+8lYaq1rPxkL90Z/5UBNMJbOFJfwhbUs
Xy6eIAgs2xnKbTJvmUhTl8niZYHRH8dXQ8Z861+UVljoBG/6ePiQRW1TYFm8jdqmwLLlUO1hVuHb
Qz2BW75c7bKDwMKYUO2rIQILvx/jH6oWWJgs1kleB8/Q/ji+shZOsElmBzXLapcdHm9t86YPsRxY
vPVXDoS1laUfzU9OwlqKnRxHWLyN2qawlmk/UdsUWDZvm71YLYYMhppmt8AUlh3K/HF8gYU5WPOm
j+xbeAusedPH47GXyeGcqdfNLnsI30L1utmHUwUWqtdtltrBmDA65pW1UL3u3p2RZwJUWLt3Zwgs
i2D+HIEYMrjz+rsBAkudYO8GPAE73CqxTFSJ+psYMjZvu7dRCCycCd5GIbBsL+uuXgss28u63WNV
MwH6diYFQt9OAiNdZV7WE75l8tpq77Q83rdR1svWUvna709kLDySrH5/QmBZ2uxv7ivfsmQpynrZ
WpgsrV7Wy1gor62Twyl87TPKesJaFhP8gr8aMpaDrX5/QljLZIrV24QFFjphloiyLXK1b1Qr38II
Zh+pVlgWxlfvL3u4b8+zEzrbIs+T4ktjQ3b2NorsBBhqznbvWA0ZE1rP9nK1wsKZYPNrnCQ/VmLZ
x278aJqp8FTmJ1NBZeUnjweCysKM9yQIKouJnn0JKgsyfioVVLaTF29+ElgWDPzD32LGQu3HHyFQ
WLY3xi1T4QQWuuKWacbCDLS4rpaxMAONW6YCyzLQYl+CU0MG561XYrO1cFsoXhnIWJiBFq/ECiyc
t95sKrAs0kQlVmDhcvCCg8CyGF48S8pYeNelerNpxsJVFpdXBZZtOVGJfTzWnp1Ti5cNWa0mMwtr
WUyoXhnIWBgTomSasfi9ectAMxZukdWbTQWWxYTqLSoCy/Jlf29eOQFiZ4kdbEzwdnnhBLZFRiU2
Y2FtM26ZZiycYFHgzVi4ypofHzMWnkaa9+4JLDuONPuWpZq3LDDae6QSyyZYs/c4lbUsJvgz9grL
Vpm/N6+wLP3w9+YVFs6ESWBsLLVrFxMSxLxlQkKbnaPhBPPnmoS10Aku12UsLZ67XJexNDB6eURg
2ZB1l+sElg2Zf6tdTDAYxru9fyywMIz3WSLK0uaoG2ffwrNDbzptpr71e5vZWng4NblSDhlbvP4J
eDUT2KbT/f6IcALbHfwZe2Ut29D9E/AKe+Tx1K2Ls8/COFPt+iTe0gnm1+/zkOFy9ERZYk5Y7SO/
asgg9jmB0R+GV9ayebvOTuhsL1u9PJJnwsKaPvxheOUEOGTeKy2shb71crTAQt9OAiNcZVE3Ftay
MO4fVVdDBn07UUSh5L7O8lvohElgpN9J8Et7YsiYvHb2TsOMhVnN2TsNMxZuOmdvqBFYljH603CX
fCeWJeNna8XP1Mps9actM7WwJeYta5m6sHeUfSUIKrPVKw6ZCu+cF7+kJbBMSSj+kk7GQs9GzVRg
mWv94XYxZ2E7c/Gjk7CWbeXFj04CC53gD1AKLJwJkygD25nLiIYqzEA5pXjHh3ACHDI/4wgsO+gV
P+MILBwy15QEljkhqpACy6yNKqTAsuUQT+gKLBOEq2/lGQvnbdwHzVha4fVHuwSWzds6CTXwPmgp
Q2dex4b2obWssdayUkYhQ2CptXYzWGChcuuNOgLb2HLwTUdg4QTzjhqFZefHYk8mKCw7m/uTCQrL
fOtXIZ+AnU0wpoU2k1OUtSwmeF1PYaFv7dEugYXvVfnrsQoLrbXPGCgs2yL94qbCsiO/f0daYGEE
a9ZgJrDwbO7PvAosFCj84qbCsmTJL24qLJxgdnFTYdmZ3z9PrbDMCd3uJwksTJb84qbAwpnQrY9C
YaET7A0khWWCij+cqrDQWmuRVVi2O3ilTGFZnuDvsSosdIJ13iosC+PdBGGFZTGhmyAssDDedpPB
BBbeVPP3WBWWOcHfY1VYtspW05kVls3bdRIYYQRbrcFMWcsyRr8PqrAsJqz2fReBhU8mrHbmFVg4
b1d7A0lh4by1up7CwiGbJKKw9cWvmSproRPs/r3CwlVmny5UWHaKXIeeIrFs01mvz5lgdgNMOIFW
IW9604F6wvqc/PZs1/qFE+DjqaHVjK8DfBCsqDZudwdWgWXxtnioEVjW317s2/LKWnY4LR4ThLUs
Byv2JoeylsVb/3SfwsIh89QuOwFukcVTu4yFTf7FSpzKCWx38EtVAgvz27pYGM9OgFtktcqpwrJ5
W+1jIQrLfFv9zCucwHbeOr5tLK1lO291MVBYy3beak99KN8yUcXfoVRYaK195llh4Uywvg+FZYHR
72opLDuX+V0thYVO8BO6mGAsjPsXAZW1bIv0u1oKC51gl1gVluUJzXOw7FvY3+5fBFTWslXmXwQU
WLjpNK/pZCfAg3/zo7TAspnQrAFGOAG2cUbxJVtLfWuf7lPWsm6wZr2sAkurJNYAo7Bs5232tJLC
slDTrH9PYeEEm8Vbliw1e75dWcv2smZXbgUWHqWbtes8AzuZtywwRqkoL14YwbpduRVOgEfp7oqo
sJZt6FEqEli2eO1rPNIJbN52r0Bla2G87fYVDjVk0AmzbBzO25lMwSJYtycOlBPgpSq7yauw0Ale
ms8zAfa3d3tTWVgL8wT/IqDA0phgd2Mfj/WnQxWWhZooFYkhY/PWvwiorGWL178IqLDs4L/aWwQK
y5bDam8qKyz07XMCo79IKqyFq2xdJ8kSyxjXmZ4Afes1HbEc2Ba5zmRhuHjtqWYxZPDssNq9F4WF
i9dLRcK3cPHaa4HKWrZ4z3bzRWHZBPObZQILk/yz9zYL37JVdvbeZoFl0qW/SCqc8JB62chGn1Ev
E1i2eKNeJrBMB4t6mcCymRD1MoFlR+molwksi7dRLxNYOGReL8vYh9TLMpbeIPCYMBruPiyHwu7G
xn2HjKXWunSZsXAv8y/4rY/H+hYpsHDeurIksHDeeuVUYNleFpXTjIXN834RTAwZvMxbXQIS1rII
Vn2LFFgWb6sfSTIWLoc6osxF+Zbdgap+JBHWsjwhKqcCy1K76lqNwLLl4M9RCt9C6bL6SUdYC51g
r64Ja2HzfHWtRlgLZ4JdZRXWQq2mujYurIXlY28zE1g2ZFGLFFi2O0QtUmDZca/ZVdbHD1nUIoW1
LIw3b+sVWBYTml3GV05g+m0bhiosfKe3uVbzeCd4S4nAspjQzk+JCc0+8yKGDAbGZu/0CiyMYFE0
zL6FxZfmInbGUiXfHnh8vBOiuiesZTEhqnsCy2JC9147gWW7gz/wKHwLG2D8gUeBhfM27pcJJ7DD
qX8Y8AnW2icYFJbtvN0vggknsJ23exlOYFlWExfBBBYuh9mZlx2lo7onrIVDNguMzAlxv0xYy2bC
6k3IAgsld29CFlgWwaK6J7DQt96EnLFQco+iYcbSKypeNBRYliytXWc1UHKP6p6wFg7ZLGOEE8yr
e8JaFhPixpbAMiU/ynACy5Sl9TZJRFmytN70kWRhYdy/4Pf4nde/4CewUMk/ez9YHjKqjdtbslbx
/qDk0+fy/L6DwLLdoXiHlcCyxRuFLYFlgbF4qBFYaK2HGoFlgbG4aiewbJX5R7vUBGMZY/F6mbAW
OsEzRoFlyVLxwCiwcDl4YBRYNsGqvd2thowth+pFw8db61WSjIU5WPWiYcbCHKzO4i30rWuMwlo4
E+y5PDUT2CqrYxuTWJYsVb/vIJzAsprqYqDAQifYg5/Kt3Am+H0HYS2cCZN4CyWg6sUXYS3bdKr3
g2UslC6r94NlLHytt3k/WMZC37ZZGGczodknGNS8ZcuhjVYwhYU9oq1ao6zwLatKN/t6rMDSKokf
pbO1sDTfZmkzy2qafYJBOAFukW2WNsMJNtwqrWWHU//EmHICi2DxFKGYCSxtbpMwDosv7TrJGKET
/LUH4QSWJzS/Jpyx8ITeXRHN2IW929xdERVY5tteJkPGJlifpc3spNNnaTOLCX0SxuGG3v3FLTFk
bOfts3jLwni8cJithTtv9/u8GUure8/Jb6MCJaxloSaeIhRYOG+96zJjYX67eg09Y2H6EaUigWWh
Ju6XCSwLjKt9SUdt6GwmrJPACDcd/xaYsBaeHVb71q3AwsUbpaI8ZPAzr6u/D5ax1FrvWcpY6lu/
eJux1Fq/eCuwrO1h9a5LgWV72To5ocM3rNbZCZ1tkefFClvCCSyMx+N+GQvD+NnfaM1Y2C0cFajH
Y+2jtMK31An+IkG2Fp7Q4+HEcTnyQ70MWlv84cSMhcshLoIJLDvzFg+MAsuWQ9TLMpb61utlGQuz
mqiXCSzLauJWkcCyCFb8jdaMpb71x1Qzls5b73IXWDZvq7+JnbHQCdUzRoFlZ97qimjGQnmt+ldU
BJblt9UzRoFleUJ1RVRgWaiJ6z8CyxZv9a//CCxbvHH9R2BhqWjsjpdVYNkBKh5OFFg4wbz1NGPh
Aar6dcuMhbtDdUVUYGEt0j5Kq4YMzoRZvGWrLApbwglsJjRvJBBYJrTGx7AElh2g4ilCgaX3dOxI
IrAs3sb1H4FlE6zNAiOcYKtV97K1jYXxuP6TsTBPiOs/AsvyhOav+mcsrDu0ScYIZYo2yxjhTPCD
v3AC28uad1gJLItg3UvzAsuc0MskJrD0o0/y24XN2ygVCSewCBalIoGFvvVSUcbCNrM+O/izPKG7
IpqthRJQt08qi3gLW/2jVCSshUPmd6AEFk4wf/pVYGFM8NZTgWWt/t3voQssm2Bxq0hg2Ql9XawL
SGBZGF9nGSMbstVbT7O18Eiyes9SxsKPXESpKGPhSWedBUbWYRVfrRLWstRu9c9LCSwLNau/+yGw
LMlf/VMyAgsXr78ZKLAsT4jLSgLL8oT4vJTAwiHzClTGwraH1W9xZixU7aJUJLDszBulooyFJc7z
LGNku8PZa+jZWhjBzpN4C7uAzpPACA9QUYEaDSAfKlAYaw/VCizbIqMCJbAsq4kbWwLLAmM8RSiw
bN7GU4QCyxLRKBUJLLTWpUuBZfE27kAJLNt0ih/8BZZtOtV78gWWDVncgRJY5tuoQAksS5aql+Yz
Fupg8Y2tjIWnyOpdlwILh8y7LgUWDpnX0DMWph9xWSlj6ZD5y0UZC7sp4kk3gd2dHZbXerr//9cf
T7+O/3EZV6eW8Z8f4h/r9XV87uc8Lv283q795cdfTn/4choZiP8r47+t4Hm+d4K0Uzl9+en0+2Vp
R8LkRrXHFAS1Mqq9dqioR+T3zVb7vpCiMltN0xfU5cjWvtlqkv7jqfbKjqIeSZ83W+3KtKAeegZ3
R9WjdegEsVHtuKNsPRIdN2qxzjiFZZOg2IuqAntIct5Za3cpFPbIPrnD2rNbAlt22agFo+X0mQDW
3gJYO5nqeh6V348ZP/s8mF2zUlSWOFmzlaIyAc8EC0U9Mm6bX03IVVS2s9sVK0U9stA2W+0qlKA2
djwzsUJQYbZQ7IOJAgsTvGJPoAgsfD6x2CNOCssWQrEvGwosPqfrIYMaSLHXRJ9grd30V1g2bYvd
9FfYI7vOtsaKNUQp7C6Of3f+ucN6miDi95H0a4/VIYFOME8UhLUs1hbrXFK+ZcG2WIFeYZmq4Md/
hWUxwY//Csv2Bn8oXmGZb/0JFIGFJe9qcqvAwue8XFVQWBYTqp/zxHKAE8z6WpW1LE+qXe9lh84O
W6jxvlZlLQvj1U9l2bcw/ahW9xfWwqJGNQ3kGVg9ZFRasb5WYS3ME7yvVWFhBJvsDjC9bXahVVnL
Fq+/rKKwzAn+sorCslXWTMVVWJZ+NLtgpbDQCfZyoMJCa+0JFIVlW2SzdgKBLdBa+8S2wh6Rq7Yw
3iaBkXaKzs7RcJXNIhjLwZq9xSd8CwNjm0Qw+rKKdeYra9mRpNtNKIEtbPF2extKYOGRpM8iGAuM
/tFqZS2LCd1uQinsEQ1/W7zeKaqwcMisU1Rh2XGvW0OUwEKtpltDlMDC/LbP9EU4wUarirQW+tY6
RZUT4EwYdTiJhcvBXlsS1sIk3x8VEVjYtLN6hSAfSeAE8/fnhbXwosr6HI1xtddEhbXwrel1pjGy
CbbaI6XC2gJ7L63uL7BQpvBOUYVlocY7RRWWxQT/urTCwiGzu5wKC4dsljGyndffKlHWQt9a55LA
wsDoX5dWWGbt2e4WCezC9jJ/VERh2QQ7e0U2h3HqW/t0prKWTbDzLGNkQ2Zl48sopH8oG0P51kov
ggo3SHtjWVGhY8dwKSqbXPYCnaKyM7+VjRWVCcL2vrKislVrdzgFFSb3dtRVVHbeL8tkGex6zI4U
9SweCmuhbOs1boGF6kSxeCiwcMSKxUOBhYJSsZqLwrJoUKzmIrDUCaYBCiyMiMWeiVNYtnSLPcup
sGyvKbOgCK21T1sqa1kEL7OwyFS1YnctlbUst/evlgssrWdZi7vAwghWZ4GRxVuTrq3v15OZ83sT
777F7kAUN+X68VTTZxSVVaJNnlFUVhMoViJ7BnYyXuwxldge8zSgG461gCknwKDYJkPG4kGxJvEn
WGtd4goLg6I1dCssqw7FPpZnQoE5gu9jj8d6di+w0LfWFap8y3SUYpKtwEL9z0P4eFXmCSH84VQP
4ZkK90YP4ZlKM0UP4QLL9hvvwb8ILDvnRgjPWChLeBevshY6wUN4tnaBTvAQLrBww/EQnrEF5gge
wjMW3lWLEJ6xhy55bIXSOIpkLJ1gHsIztjKBpngIz1iY2EYIz1j4Xc9q3zhRq4xpNNWqbk/Auuoh
nMCGrLrqIbDsrOudpsoJ7KzrLaEKy24PeUuowrLA6C2hCgt9O8k94M5b/fwoZgLbdOok+4CnnDpL
P9iZzJss1ZCxvazZFUCFZYenZpeInoD1E6SYCdDaWfoBfTtLP9iZrE3SD7jK2iT9gI/ZNVdCxZCx
w1PzE6TAwiGbpB8wq2mT9OPQJe4tB/NPrKlVxvYy/8SawrJjtH9iTWChwNon6Qccsj5JP6C1vkOO
21RPOJ0/nOr7Y6Y+4nSeqTBlDoFVYNlSiNN5xsLO8zidCyzLFuN0nrGwMbj49pixcCKEwJqxcB8r
vj0KLMsWi2+PAssy8TidC+wjBFaBZSG8+PYosOyoF6fzjKWHfhdYMxYe+uN0nrFwM4/TucCyIau+
PQosS5TidJ6xhcXbOJ1nLBQC43QusNC39jbPRWDZ4o3TecbCjMZSj+toZX586vF4qqUeggqTBDuZ
Kyqbs556PAM7GS+YI9jJXFgLF66nHk/AWuohsJUd+D31EFgYZjz1UFgWZjz1ENjKdARPPQQWhhkv
DAgs3B499RBY+Fy3px4CW6BvLfUQ2Ap3BisMCCxMmT31UFiW23rqobAsE/fUQ2ArW2WeeigsE6o8
9VBYaK2lHgLbWP+Xpx4CWx5QGBBYqC16YUBg4f1aLwwIbGM7rxcGBBYeo70wILBwQ/fCgMDCmyhe
GFBYloM1KwwIbGMV0zZJP+CXtJsVBoS1sCTvhQGBhR/K8MLAE7BWGBDYzlaZFwYEFqZ2zZQPhWVh
3AsDAgtTOy8MCCxM7bwwILAwtfPCgMDCJN8LAwILZ4IXBgQWtul0u40hsDAmdHuqSmDpTJikHzAb
7/ZU1ROsnUgf8KXMbn0JwlqoUvSZ+MES0T5TP9gWuVpbpHICk4RX60sQWDhv14n6ATcdn1/jYfwn
SGsPp/rsElS27frkylS4wkJaE1g2Z72qdxVYdsrxqp7CskN/SGvZWrgUvKonrIXnhpDWsrVwMw9p
LWPhcSSkNYFlEkVIaxkLt8eQ1jK2scNTSGsCy+SfkNYylt4dcWnt4Viv6onlAHeGkNaytVT5sKqe
sBbGhJDWhLVMDQ1pTWBZYAxpLWOpEzy3FVi2ykJaE1i2yvwZVjETYLwNaS1bCw9PIa0JLDtGh7SW
sfQY7bltxsIJFtJaxsJjdEhrGQs3nZDWMhbOhJDWMraxmRDSmsCy9DakNYFleUJIawLLQo333IqY
0NgFpZDWsrXwCbCQ1jKWLl7ruRVOgGWikNaytTCrCWktYxu7NRDSmsCyVRbSmsCypqKQ1gSWVftD
WstYeDgNaS1jYem4z9IPtnhDWsvWwof2+kT6gJeYQ1rL1sLCS0hrAsvy25DWMhYWXkJay1h4JPER
G8/ePEGsejjVxSpBZbu5i1WZCuNBiFUCyxL8EKsyFib4IVZlbGMZTYhVGQs18RCrBJapzCFWZSx8
wDDEKoFl0zbEqoyFCX6IVRkLTzkhVmUsXWVeiBVYuMo8W8xY6gQXqzIWHvVCrMpYqN2GWJWxUGSN
PjCBZUloiFUCyyJYiFUZC3fdEKsyFk4wvyB+zVi4ykKsEli2ykKsyli4l4VYlbEwtw2xSmBZmSjE
qoyFizf6wDKW6jReiM1YuOmEWJWxsHUvxKqMhYs3xKqMhYs3xKqMhYs3xCqBZYs3xKqMhYs3xKqM
hYs3xCqBZYs3xKqMpYt3kn7QxTtJP+DiDbFKOAEeo+19GrGXwcUbYpWwlmXjIVZlLFy8IVYJLFu8
IVZlLFy8IVZlLFy8IVYJLFu8IVZlLFy8IVZlLFy8IVZlLF28M/WDTbAQq7K18KZ89IFlLKyfRx9Y
xsINffU29MdjvQ09Y2FgdCFwvKPyBCHw4VQXAgWVxXBfCpkKQ3gIgQLLVlgIgRkLQ3gIgRkL75SF
EJixHbbu+VLIWHhBKYRAgWXzK4TAjKXfGbC3KK4CCyeY38jI2MLKbyEEZiz8hlh0rWUsDOHRtZax
1FrPxDMWLocQAjMWOiGEwIyFu24IgRkLD/0hBGYsTJRCCMxYWCEJITBjYYUkhECBZRWSEAIzFlZI
QggUWBZvQwgUWNaXEEJgxsL8K4TAjIWLN4TAjIVZTXStCSzbdEIIzFiY1YQQmLEwqwkhMGNhGA8h
MGNhVhNCoMCyVRZCYMbCrCaEQIGFE2wQVbIEs5oQAoW17JZWXAjNWBoTJukHzGpCCMzWwuUQXWsZ
C50QQmDGwqwmhECBZTtvCIECCzUwvxCasVQD8661jKUamF8IzViY2oUQmLGwYSuEwIyFeYLrNNen
NGw9nOo6jaCyHcd1mkyFGU3oNALLNpzQaTIWZjSh02QszGhCp8lYGMKjYStjYUYTOo3AsvkVOk3G
wowmGrYEFk4w12kyFmY0odNkLMwRQqfJWLiZh06TsdRaT5QyFi6H0GkyFjohdJqMhRlN6DQCyzKa
0GkElmU0odNkLMxoQqfJWJjRhE6TsTCjCZ0mYzu7SRQ6jcCyeBs6TcbS5TDJPmCeEDpNthbOhNBp
MhbmCaHTZCzME0KnyVgYGEOnyViYJ4ROI7Bs3oZOk7EwTwidRmBZnhA6TcbCPCF0moyFO280bGUs
jAmh02QstdYbtjKWLodJ+gGdEDpNthbmCaHTCCzLE0KnEViWJ4ROk7EwTwidJmPh7hANWxkL84Ro
2BJYFhijYStjH6B83MYHtB/fofJ4quUeisoca8qHoMKMxpUPhWUbjisfAgszGlc+BBZmNK58CCwM
4a58CCzMaFz5UFg2v1z5EFiY0bjyobBwgpnyIbAwo3HlQ2BhjuDKh8DCzdyVD4Gl1lrqIbBwObjy
IbDQCa58CCzMaFz5EFj4wpYrHwILN3NXPgSWWmslIoGFm7krHwJLZ4KViAQWbpGufCgsi2CufAgs
3CK9Q0Vg4RbpyofAwpjgyofAwi3SlQ+FZVukKx8CC7dIVz4Ulk0wVz4EFm6RrnwILNx0XPkQWBgT
XPkQWGrtJP2gy2FUjFUEo06wm/LKCezVPe9QUVh2m9vfVRJY6FtXPgQWhhpXPhSWtUq78iGwsDfU
lQ+BhemHKx8Cu8BrgJP0A75C4MqHspYtB1c+BJaqStb0IbBUVbInywUWpnZubHlGh8rt4VTXaQSV
JQmu02QqTEJDpxFYliOETpOxMAkNnSZjYRIaOk3Gwp0hdJqMhTtD6DQCy+ZX6DQZC5PQ0GkEFk4w
T5QyFiahodNkLEzrQqfJWJh/hU6TsdRa12kyFi6H0GkyFjohdJqMfYhOI7AsCQ2dJmOpb+3bLmon
YwUt71BRWJaEhk7zeCe4TpOxMAkNnSZjYf4VOo3AsjAeOk3GwjAeOo3AsuUQOo3Ashe2QqfJ2MKu
BodOk7Ewtw2dJmNhYAydJmNhxhg6jcCyDT10moyFGWPoNBkLM0bvUBGBEYZx71ARWJgxeoeKwrJQ
EzqN8C3rCAydRmDZBAudJmNhxhg6TcbCHCx0moyFMSF0moyl1k7SD7gcvEPl8fM2dBrhhEfoNALL
tki/SSScQH3rOk22FoYaf1JIWEtX2Uz9YKHGnxQS1sKM0Z8UElgorfmTQgJLH0CyJ4UEFqqhq72j
orBsla32ZVuB3ad2y2s93f//64+nX8f/uJyvp2X854f4x3p9bfV0rtfL6+3aX3785fSHL6eyxr8y
/ruexy8Zc87bwtqpnL78dPr9shxSyTeqR8lMPRTTN2qf2HqkRXKjruZmYeuRDHqjnhdJXY68nrCj
mpKdbT105NmoF1sWmXro8zE7qra1HNkkNurVjv/Z1kOPQG/Um54DcBWUpWpjj4gKm7GlTKyF2DqZ
skd2np21swhzRLDZYVuXvoXTq3Q9ZHusRdfl9JlwG3/ih7JYuL0utUa47Vu4PeLjjVpGIUZhD6U4
e+xVYpcjn0/ZYW9dY4/MiD32prFHSqgbto6eaeXbQ89y7rF6yJYji3iHHbFBWssmWC16yOqRk+rO
2vHpRWntkR19j50M2RGtbY+dLIcjmcIOOyKZdMKRVGGH7YvGHslK99iJtXCC9Yu09tADYTtrR3L3
DN+ORwMlFi6H82TewuUwKojSWhgYR6eCxB5J8HZDNrJRiYXz9qKtPfQdv521tp+PBezHpwfv5wJ7
RMbcjC03CwkCywJYuU2cAAPYyJ6ltTDSLDa/shMOfXRw823skBlb4Z5TLNJk7KGTyc7akYIqLN7P
bZFlaw9pYjtr22SCwZnQtLUVzlvfyrITDhVidk4Yr0Ip3x6q/u+xeoIVOG99K3u8E3zPEVi6OWjf
HnqZc+db33OEtXDjvWpr6YnED5HCWrifD21Fzlt20CndkvGhCPrOW95P0jDUlNXSW4FlmZ19F05i
4ZH3YmE8W3uoyLXN2+IpWMZWmCdc9JAdeldlZ+114oRdslRP/3mqp3+efvenr/X096+n3/3xa3n5
41+GXH52Mecvf/xt7fw0tPMQWvrldT39crIGlOH98T9efj795fTnd9qQhsYvavaLflORN6op8vu/
T8yVlw8z+1Pfa1XY8P5H7KeaJAR2aLE2BRP2M293Kqxt+QL7mUCfsdVzyoz9VBlMYS2TyNhP1TsE
tkyc8JkPWQusqy7Z2v6ZGCewzQJ9xn6qaCewQ5FV2E/FOIXVq+xT2qbArnbEyk6Aq6yu2lo6wc4T
38KZcJ7M288k1sK3427XM3z7ti19jGCfesD0bm17K6yOSqr1ba9L+4itnxFzBNYuuAnsoXm7s3ak
qhJ7JNTssHZDRFl7ZHfYYyfWfubQInx7u0pr4Uyoi8bCmVDH7iB9u8t7vjv92Hzr1/bFkH2qlpR9
W9uoLgrspwq3CjuZCZ85XQhsn2Chb8fp4hlOGIdtif3MOVM4YZwuFPbQhr6bYFc9b9tnThfC2qFC
SmvZkLUhFyrsoQ19c0KzGr5YDjAmlJGDXdZ+/bjpfErNyb71i1gCC51QhlKmrKVYez9dWAsjWBnJ
ksJ+Si4Uvr1YYMxDtp8Jf/5/twGYmQplbmRzdHJlYW0KZW5kb2JqCjEyOSAwIG9iagoxMjY3OApl
bmRvYmoKMTI3IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNCAwIFIgL1Jlc291cmNlcyAx
MzAgMCBSIC9Db250ZW50cyAxMjggMCBSIC9NZWRpYUJveApbMCAwIDU5NSA4NDJdIC9Bbm5vdHMg
MTMxIDAgUiA+PgplbmRvYmoKMTMwIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9D
b2xvclNwYWNlIDw8IC9DczEgOCAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR3MyCjI2IDAgUiAvR3Mz
IDI3IDAgUiAvR3MxIDI4IDAgUiA+PiAvRm9udCA8PCAvRzEgOSAwIFIgL0c0IDEyIDAgUiAvRzMg
MTEgMCBSCi9HNiAzNiAwIFIgPj4gPj4KZW5kb2JqCjEzMSAwIG9iagpbIDEzMiAwIFIgMTMzIDAg
UiAxMzQgMCBSIDEzNSAwIFIgMTM2IDAgUiAxMzcgMCBSIDEzOCAwIFIgMTM5IDAgUiBdCmVuZG9i
ago0IDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXSAvQ291bnQg
OCAvS2lkcyBbIDMgMCBSIDMxIDAgUiA2MiAwIFIKNzYgMCBSIDg0IDAgUiAxMDggMCBSIDEyMCAw
IFIgMTI3IDAgUiBdID4+CmVuZG9iagoxNDAgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cgL091dGxp
bmVzIDIgMCBSIC9QYWdlcyA0IDAgUiA+PgplbmRvYmoKMTM5IDAgb2JqCjw8IC9BIDE0MSAwIFIg
L0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90IC9TdWJ0eXBlIC9MaW5rIC9SZWN0IFsgMTcw
LjQKMTA4LjA4IDI0Ny4yIDExNS43NiBdID4+CmVuZG9iagoxNDEgMCBvYmoKPDwgL1MgL1VSSSAv
VVJJIChtYWlsdG86anJpY2hlckBtaXRyZS5vcmcpID4+CmVuZG9iagoxMzggMCBvYmoKPDwgL0Rl
c3QgWyAzIDAgUiAvWFlaIDQ3LjUyIDIwNy45MiBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5
cGUgL0Fubm90IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsgNTIyLjcyIDE1Ny4wNCA1NDMuODQgMTY0
LjcyIF0gPj4KZW5kb2JqCjEzNyAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9YWVogNDcuNTIgMjA3
LjkyIG51bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsg
L1JlY3QgWyA1MjIuNzIgNDEwLjQ4IDU0My44NCA0MTguMTYgXSA+PgplbmRvYmoKMTM2IDAgb2Jq
Cjw8IC9EZXN0IFsgMTI3IDAgUiAvWFlaIDQ3LjUyIDczNi44OCBudWxsIF0gL0JvcmRlciBbIDAg
MCAwIF0gL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rIC9SZWN0IFsgMTI4LjE2IDQ5MC4xNiAx
NjMuNjggNTAwLjcyIF0gPj4KZW5kb2JqCjEzNSAwIG9iago8PCAvRGVzdCBbIDEyMCAwIFIgL1hZ
WiA0Ny41MiAzNS4xMiBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90Ci9TdWJ0
eXBlIC9MaW5rIC9SZWN0IFsgMTU1LjA0IDUyNC43MiAyNzMuMTIgNTM1LjI4IF0gPj4KZW5kb2Jq
CjEzNCAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9YWVogNDcuNTIgMjA3LjkyIG51bGwgXSAvQm9y
ZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsgL1JlY3QgWyA1MjIuNzIg
NjE0IDU0My44NCA2MjEuNjggXSA+PgplbmRvYmoKMTMzIDAgb2JqCjw8IC9EZXN0IFsgMyAwIFIg
L1hZWiA0Ny41MiAyMDcuOTIgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdCAv
U3VidHlwZQovTGluayAvUmVjdCBbIDUyMi43MiA3MDIuMzIgNTQzLjg0IDcxMCBdID4+CmVuZG9i
agoxMzIgMCBvYmoKPDwgL0Rlc3QgWyAzIDAgUiAvWFlaIDQ3LjUyIDIwNy45MiBudWxsIF0gL0Jv
cmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsgNTIyLjcy
IDc4MC4wOCA1NDMuODQgNzg3Ljc2IF0gPj4KZW5kb2JqCjEyNiAwIG9iago8PCAvRGVzdCBbIDMg
MCBSIC9YWVogNDcuNTIgMjA3LjkyIG51bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5u
b3QgL1N1YnR5cGUKL0xpbmsgL1JlY3QgWyA1MjIuNzIgMTEzLjg0IDU0My44NCAxMjEuNTIgXSA+
PgplbmRvYmoKMTI1IDAgb2JqCjw8IC9EZXN0IFsgMyAwIFIgL1hZWiA0Ny41MiAyMDcuOTIgbnVs
bCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdCAvU3VidHlwZQovTGluayAvUmVjdCBb
IDUyMi43MiAyNDkuMiA1NDMuODQgMjU2Ljg4IF0gPj4KZW5kb2JqCjExOSAwIG9iago8PCAvRGVz
dCBbIDg0IDAgUiAvWFlaIDQ3LjUyIDMyNC4wOCBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5
cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rIC9SZWN0IFsgMTkyLjQ4IDQxMi40IDI3Ni45NiA0MjIu
OTYgXSA+PgplbmRvYmoKMTE4IDAgb2JqCjw8IC9EZXN0IFsgMyAwIFIgL1hZWiA0Ny41MiAyMDcu
OTIgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdCAvU3VidHlwZQovTGluayAv
UmVjdCBbIDUyMi43MiA0NjcuMTIgNTQzLjg0IDQ3NC44IF0gPj4KZW5kb2JqCjExNyAwIG9iago8
PCAvRGVzdCBbIDg0IDAgUiAvWFlaIDQ3LjUyIDExMC45NiBudWxsIF0gL0JvcmRlciBbIDAgMCAw
IF0gL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rIC9SZWN0IFsgMTI4LjE2IDU0NS44NCAxNjMu
NjggNTU2LjQgXSA+PgplbmRvYmoKMTE2IDAgb2JqCjw8IC9EZXN0IFsgODQgMCBSIC9YWVogNDcu
NTIgMzI0LjA4IG51bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QKL1N1YnR5cGUg
L0xpbmsgL1JlY3QgWyAxMjguMTYgNTY4Ljg4IDIxNC41NiA1NzkuNDQgXSA+PgplbmRvYmoKMTE1
IDAgb2JqCjw8IC9EZXN0IFsgODQgMCBSIC9YWVogNDcuNTIgMjExLjc2IG51bGwgXSAvQm9yZGVy
IFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsgL1JlY3QgWyAxNTUuMDQgNTgw
LjQgMjczLjEyIDU5MC45NiBdID4+CmVuZG9iagoxMTQgMCBvYmoKPDwgL0Rlc3QgWyAzIDAgUiAv
WFlaIDQ3LjUyIDIwNy45MiBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90IC9T
dWJ0eXBlCi9MaW5rIC9SZWN0IFsgNTIyLjcyIDY2OS42OCA1NDMuODQgNjc3LjM2IF0gPj4KZW5k
b2JqCjExMyAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9YWVogNDcuNTIgMjA3LjkyIG51bGwgXSAv
Qm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsgL1JlY3QgWyA1MjIu
NzIgNzU4Ljk2IDU0My44NCA3NjYuNjQgXSA+PgplbmRvYmoKMTA3IDAgb2JqCjw8IC9BIDE0MiAw
IFIgL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90IC9TdWJ0eXBlIC9MaW5rIC9SZWN0IFsg
MTc0LjI0CjU3OS40NCAzNDEuMjggNTg3LjEyIF0gPj4KZW5kb2JqCjE0MiAwIG9iago8PCAvUyAv
VVJJIC9VUkkgKGh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDIvQ1IteG1sMTEtMjAwMjEwMTUpID4+
CmVuZG9iagoxMDYgMCBvYmoKPDwgL0EgMTQzIDAgUiAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAv
QW5ub3QgL1N1YnR5cGUgL0xpbmsgL1JlY3QgWyAxNzAuNAo1OTUuNzYgMTg2LjcyIDYwMy40NCBd
ID4+CmVuZG9iagoxNDMgMCBvYmoKPDwgL1MgL1VSSSAvVVJJIChodHRwOi8vd3d3LnJmYy1lZGl0
b3Iub3JnL3JmYy9yZmM0NjI3LnR4dCkgPj4KZW5kb2JqCjEwNSAwIG9iago8PCAvQSAxNDQgMCBS
IC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdCAvU3VidHlwZSAvTGluayAvUmVjdCBbIDE4
OS42CjYwNS4zNiA0ODguMTYgNjEzLjA0IF0gPj4KZW5kb2JqCjE0NCAwIG9iago8PCAvUyAvVVJJ
IC9VUkkgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ2MjcpID4+CmVuZG9iagoxMDQg
MCBvYmoKPDwgL0EgMTQ1IDAgUiAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5
cGUgL0xpbmsgL1JlY3QgWyAyMjguOTYKNjE3Ljg0IDI0Ni4yNCA2MjUuNTIgXSA+PgplbmRvYmoK
MTQ1IDAgb2JqCjw8IC9TIC9VUkkgL1VSSSAoaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGlj
L3JmYy94bWwvcmZjMjExOS54bWwpID4+CmVuZG9iagoxMDMgMCBvYmoKPDwgL0EgMTQ2IDAgUiAv
Qm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUgL0xpbmsgL1JlY3QgWyAyMDEu
MTIKNjE3Ljg0IDIyNC4xNiA2MjUuNTIgXSA+PgplbmRvYmoKMTQ2IDAgb2JqCjw8IC9TIC9VUkkg
L1VSSSAoaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzIxMTkuaHRt
bCkgPj4KZW5kb2JqCjEwMiAwIG9iago8PCAvQSAxNDcgMCBSIC9Cb3JkZXIgWyAwIDAgMCBdIC9U
eXBlIC9Bbm5vdCAvU3VidHlwZSAvTGluayAvUmVjdCBbIDE4MCA2MTcuODQKMTk2LjMyIDYyNS41
MiBdID4+CmVuZG9iagoxNDcgMCBvYmoKPDwgL1MgL1VSSSAvVVJJIChodHRwOi8vd3d3LnJmYy1l
ZGl0b3Iub3JnL3JmYy9yZmMyMTE5LnR4dCkgPj4KZW5kb2JqCjEwMSAwIG9iago8PCAvQSAxNDgg
MCBSIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdCAvU3VidHlwZSAvTGluayAvUmVjdCBb
IDE4Ny42OAo2MjYuNDggNDM0LjQgNjM0LjE2IF0gPj4KZW5kb2JqCjE0OCAwIG9iago8PCAvUyAv
VVJJIC9VUkkgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIxMTkpID4+CmVuZG9iagox
MDAgMCBvYmoKPDwgL0EgMTQ5IDAgUiAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1
YnR5cGUgL0xpbmsgL1JlY3QgWyAxMzEuMDQKNjI2LjQ4IDE3OS4wNCA2MzQuMTYgXSA+PgplbmRv
YmoKMTQ5IDAgb2JqCjw8IC9TIC9VUkkgL1VSSSAobWFpbHRvOnNvYkBoYXJ2YXJkLmVkdSkgPj4K
ZW5kb2JqCjk5IDAgb2JqCjw8IC9BIDE1MCAwIFIgL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fu
bm90IC9TdWJ0eXBlIC9MaW5rIC9SZWN0IFsgMzI2Ljg4CjYzOC45NiAzNDIuMjQgNjQ2LjY0IF0g
Pj4KZW5kb2JqCjE1MCAwIG9iago8PCAvUyAvVVJJIC9VUkkgKGh0dHA6Ly93d3cuaWV0Zi5vcmcv
aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgtdjItMjMucGRmKQo+PgplbmRvYmoKOTgg
MCBvYmoKPDwgL0EgMTUxIDAgUiAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5
cGUgL0xpbmsgL1JlY3QgWyAzMDQuOAo2MzguOTYgMzIxLjEyIDY0Ni42NCBdID4+CmVuZG9iagox
NTEgMCBvYmoKPDwgL1MgL1VSSSAvVVJJIChodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy
YWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXYyLTIzLnR4dCkKPj4KZW5kb2JqCjk3IDAgb2JqCjw8IC9B
IDE1MiAwIFIgL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90IC9TdWJ0eXBlIC9MaW5rIC9S
ZWN0IFsgMzE3LjI4CjY0OC41NiA0NzguNTYgNjU2LjI0IF0gPj4KZW5kb2JqCjE1MiAwIG9iago8
PCAvUyAvVVJJIC9VUkkgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1
dGgtdjItMjMpID4+CmVuZG9iago5NiAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9YWVogNDcuNTIg
MjA3LjkyIG51bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xp
bmsgL1JlY3QgWyA1MjIuNzIgNzcuMzYgNTQzLjg0IDg1LjA0IF0gPj4KZW5kb2JqCjk1IDAgb2Jq
Cjw8IC9EZXN0IFsgMyAwIFIgL1hZWiA0Ny41MiAyMDcuOTIgbnVsbCBdIC9Cb3JkZXIgWyAwIDAg
MCBdIC9UeXBlIC9Bbm5vdCAvU3VidHlwZQovTGluayAvUmVjdCBbIDUyMi43MiAxNzguMTYgNTQz
Ljg0IDE4NS44NCBdID4+CmVuZG9iago5NCAwIG9iago8PCAvRGVzdCBbIDEwOCAwIFIgL1hZWiA0
Ny41MiA3MDMuMjggbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdAovU3VidHlw
ZSAvTGluayAvUmVjdCBbIDExNy42IDIzNC44IDMwNS43NiAyNDUuMzYgXSA+PgplbmRvYmoKOTMg
MCBvYmoKPDwgL0Rlc3QgWyAzIDAgUiAvWFlaIDQ3LjUyIDIwNy45MiBudWxsIF0gL0JvcmRlciBb
IDAgMCAwIF0gL1R5cGUgL0Fubm90IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsgNTIyLjcyIDI5MC40
OCA1NDMuODQgMjk4LjE2IF0gPj4KZW5kb2JqCjkyIDAgb2JqCjw8IC9EZXN0IFsgMyAwIFIgL1hZ
WiA0Ny41MiAyMDcuOTIgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdCAvU3Vi
dHlwZQovTGluayAvUmVjdCBbIDUyMi43MiA0MTQuMzIgNTQzLjg0IDQyMiBdID4+CmVuZG9iago5
MSAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9YWVogNDcuNTIgMjA3LjkyIG51bGwgXSAvQm9yZGVy
IFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsgL1JlY3QgWyA1MjIuNzIgNTM3
LjIgNTQzLjg0IDU0NC44OCBdID4+CmVuZG9iago5MCAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9Y
WVogNDcuNTIgMjA3LjkyIG51bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1
YnR5cGUKL0xpbmsgL1JlY3QgWyA1MjIuNzIgNjgxLjIgNTQzLjg0IDY4OC44OCBdID4+CmVuZG9i
ago4OSAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9YWVogNDcuNTIgMjA3LjkyIG51bGwgXSAvQm9y
ZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsgL1JlY3QgWyA1MjIuNzIg
NzU4Ljk2IDU0My44NCA3NjYuNjQgXSA+PgplbmRvYmoKODMgMCBvYmoKPDwgL0Rlc3QgWyAzIDAg
UiAvWFlaIDQ3LjUyIDIwNy45MiBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90
IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsgNTIyLjcyIDUzLjM2IDU0My44NCA2MS4wNCBdID4+CmVu
ZG9iago4MiAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9YWVogNDcuNTIgMjA3LjkyIG51bGwgXSAv
Qm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsgL1JlY3QgWyA1MjIu
NzIgMTMwLjE2IDU0My44NCAxMzcuODQgXSA+PgplbmRvYmoKODEgMCBvYmoKPDwgL0Rlc3QgWyAz
IDAgUiAvWFlaIDQ3LjUyIDIwNy45MiBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fu
bm90IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsgNTIyLjcyIDc0MC43MiA1NDMuODQgNzQ4LjQgXSA+
PgplbmRvYmoKNzUgMCBvYmoKPDwgL0Rlc3QgWyAzIDAgUiAvWFlaIDQ3LjUyIDIwNy45MiBudWxs
IF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsg
NTIyLjcyIDQ0LjcyIDU0My44NCA1Mi40IF0gPj4KZW5kb2JqCjc0IDAgb2JqCjw8IC9EZXN0IFsg
MTIwIDAgUiAvWFlaIDQ3LjUyIDI4Mi44IG51bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAv
QW5ub3QKL1N1YnR5cGUgL0xpbmsgL1JlY3QgWyAzMjcuODQgMTQzLjYgMzkzLjEyIDE1NC4xNiBd
ID4+CmVuZG9iago3MyAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9YWVogNDcuNTIgMjA3LjkyIG51
bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsgL1JlY3Qg
WyA1MjIuNzIgMTc2LjI0IDU0My44NCAxODMuOTIgXSA+PgplbmRvYmoKNzIgMCBvYmoKPDwgL0Rl
c3QgWyA4NCAwIFIgL1hZWiA0Ny41MiA1NzEuNzYgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9U
eXBlIC9Bbm5vdAovU3VidHlwZSAvTGluayAvUmVjdCBbIDMyNy44NCAzMDkuNjggMzkzLjEyIDMy
MC4yNCBdID4+CmVuZG9iago3MSAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9YWVogNDcuNTIgMjA3
LjkyIG51bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsg
L1JlY3QgWyA1MjIuNzIgMzQyLjMyIDU0My44NCAzNTAgXSA+PgplbmRvYmoKNzAgMCBvYmoKPDwg
L0Rlc3QgWyAzIDAgUiAvWFlaIDQ3LjUyIDIwNy45MiBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0g
L1R5cGUgL0Fubm90IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsgNTIyLjcyIDQzMS42IDU0My44NCA0
MzkuMjggXSA+PgplbmRvYmoKNjkgMCBvYmoKPDwgL0Rlc3QgWyA4NCAwIFIgL1hZWiA1MC40IDY1
Ni4yNCBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90IC9TdWJ0eXBlCi9MaW5r
IC9SZWN0IFsgNDQ2Ljg4IDQ4OC4yNCA0OTIgNDk4LjggXSA+PgplbmRvYmoKNjggMCBvYmoKPDwg
L0Rlc3QgWyAzIDAgUiAvWFlaIDQ3LjUyIDIwNy45MiBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0g
L1R5cGUgL0Fubm90IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsgNTIyLjcyIDY4My4xMiA1NDMuODQg
NjkwLjggXSA+PgplbmRvYmoKNjcgMCBvYmoKPDwgL0Rlc3QgWyA4NCAwIFIgL1hZWiA1MC40IDY1
Ni4yNCBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90IC9TdWJ0eXBlCi9MaW5r
IC9SZWN0IFsgMzYwLjQ4IDcyNy4yOCA0MDUuNiA3MzcuODQgXSA+PgplbmRvYmoKNjEgMCBvYmoK
PDwgL0Rlc3QgWyAzIDAgUiAvWFlaIDQ3LjUyIDIwNy45MiBudWxsIF0gL0JvcmRlciBbIDAgMCAw
IF0gL1R5cGUgL0Fubm90IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsgNTIyLjcyIDE4OS42OCA1NDMu
ODQgMTk3LjM2IF0gPj4KZW5kb2JqCjYwIDAgb2JqCjw8IC9EZXN0IFsgMyAwIFIgL1hZWiA0Ny41
MiAyMDcuOTIgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdCAvU3VidHlwZQov
TGluayAvUmVjdCBbIDUyMi43MiAzMjUuMDQgNTQzLjg0IDMzMi43MiBdID4+CmVuZG9iago1OSAw
IG9iago8PCAvRGVzdCBbIDg0IDAgUiAvWFlaIDUwLjQgNTkwLjk2IG51bGwgXSAvQm9yZGVyIFsg
MCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsgL1JlY3QgWyAxNzcuMTIgNDM4LjMy
IDIwMC4xNiA0NDguODggXSA+PgplbmRvYmoKNTggMCBvYmoKPDwgL0Rlc3QgWyA4NCAwIFIgL1hZ
WiA1MC40IDYxMy4wNCBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90IC9TdWJ0
eXBlCi9MaW5rIC9SZWN0IFsgMzcyLjk2IDUxOC45NiAzOTkuODQgNTI5LjUyIF0gPj4KZW5kb2Jq
CjU3IDAgb2JqCjw8IC9EZXN0IFsgODQgMCBSIC9YWVogNTAuNCA2NTYuMjQgbnVsbCBdIC9Cb3Jk
ZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdCAvU3VidHlwZQovTGluayAvUmVjdCBbIDg4LjggNTE4
Ljk2IDE4NC44IDUyOS41MiBdID4+CmVuZG9iago1NiAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9Y
WVogNDcuNTIgMjA3LjkyIG51bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1
YnR5cGUKL0xpbmsgL1JlY3QgWyA1MjIuNzIgNTUxLjYgNTQzLjg0IDU1OS4yOCBdID4+CmVuZG9i
ago1NSAwIG9iago8PCAvRGVzdCBbIDEyNyAwIFIgL1hZWiA0Ny41MiAxOTEuNiBudWxsIF0gL0Jv
cmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rIC9SZWN0IFsgNzguMjQg
NjA3LjI4IDgzLjA0IDYxNy44NCBdID4+CmVuZG9iago1NCAwIG9iago8PCAvRGVzdCBbIDEyNyAw
IFIgL1hZWiA0Ny41MiA0NDUuMDQgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5v
dAovU3VidHlwZSAvTGluayAvUmVjdCBbIDkzLjYgNjE4LjggMTE1LjY4IDYyOS4zNiBdID4+CmVu
ZG9iago1MyAwIG9iago8PCAvRGVzdCBbIDEyNyAwIFIgL1hZWiA0Ny41MiA2NDcuNiBudWxsIF0g
L0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rIC9SZWN0IFsgOTMu
NiA2MzAuMzIgMTE1LjY4IDY0MC44OCBdID4+CmVuZG9iago1MiAwIG9iago8PCAvRGVzdCBbIDEy
NyAwIFIgL1hZWiA0Ny41MiA3MzYuODggbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9B
bm5vdAovU3VidHlwZSAvTGluayAvUmVjdCBbIDkzLjYgNjQxLjg0IDExNS42OCA2NTIuNCBdID4+
CmVuZG9iago1MSAwIG9iago8PCAvRGVzdCBbIDEyMCAwIFIgL1hZWiA0Ny41MiAzNS4xMiBudWxs
IF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rIC9SZWN0IFsg
OTMuNiA2NTMuMzYgMTE1LjY4IDY2My45MiBdID4+CmVuZG9iago1MCAwIG9iago8PCAvRGVzdCBb
IDEyMCAwIFIgL1hZWiA0Ny41MiAxNDcuNDQgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBl
IC9Bbm5vdAovU3VidHlwZSAvTGluayAvUmVjdCBbIDkzLjYgNjY0Ljg4IDExNS42OCA2NzUuNDQg
XSA+PgplbmRvYmoKNDkgMCBvYmoKPDwgL0Rlc3QgWyAxMjAgMCBSIC9YWVogNDcuNTIgMjgyLjgg
bnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluayAvUmVj
dCBbIDc4LjI0IDY3Ni40IDE0Ny4zNiA2ODYuOTYgXSA+PgplbmRvYmoKNDggMCBvYmoKPDwgL0Rl
c3QgWyAxMDggMCBSIC9YWVogNDcuNTIgNTAwLjcyIG51bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAv
VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsgL1JlY3QgWyA5My42IDY4Ny45MiAxMTUuNjggNjk4
LjQ4IF0gPj4KZW5kb2JqCjQ3IDAgb2JqCjw8IC9EZXN0IFsgMTA4IDAgUiAvWFlaIDQ3LjUyIDcw
My4yOCBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r
IC9SZWN0IFsgOTMuNiA2OTkuNDQgMTE1LjY4IDcxMCBdID4+CmVuZG9iago0NiAwIG9iago8PCAv
RGVzdCBbIDEwOCAwIFIgL1hZWiA0Ny41MiA3OTIuNTYgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBd
IC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluayAvUmVjdCBbIDkzLjYgNzEwLjk2IDExNS42OCA3
MjEuNTIgXSA+PgplbmRvYmoKNDUgMCBvYmoKPDwgL0Rlc3QgWyA4NCAwIFIgL1hZWiA0Ny41MiAx
MTAuOTYgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGlu
ayAvUmVjdCBbIDkzLjYgNzIyLjQ4IDExNS42OCA3MzMuMDQgXSA+PgplbmRvYmoKNDQgMCBvYmoK
PDwgL0Rlc3QgWyA4NCAwIFIgL1hZWiA0Ny41MiAyMTEuNzYgbnVsbCBdIC9Cb3JkZXIgWyAwIDAg
MCBdIC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluayAvUmVjdCBbIDkzLjYgNzM0IDExNS42OCA3
NDQuNTYgXSA+PgplbmRvYmoKNDMgMCBvYmoKPDwgL0Rlc3QgWyA4NCAwIFIgL1hZWiA0Ny41MiAz
MjQuMDggbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGlu
ayAvUmVjdCBbIDkzLjYgNzQ1LjUyIDExNS42OCA3NTYuMDggXSA+PgplbmRvYmoKNDIgMCBvYmoK
PDwgL0Rlc3QgWyA4NCAwIFIgL1hZWiA0Ny41MiA0NDcuOTIgbnVsbCBdIC9Cb3JkZXIgWyAwIDAg
MCBdIC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluayAvUmVjdCBbIDkzLjYgNzU3LjA0IDExNS42
OCA3NjcuNiBdID4+CmVuZG9iago0MSAwIG9iago8PCAvRGVzdCBbIDg0IDAgUiAvWFlaIDQ3LjUy
IDU3MS43NiBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M
aW5rIC9SZWN0IFsgNzguMjQgNzY4LjU2IDE0Ny4zNiA3NzkuMTIgXSA+PgplbmRvYmoKNDAgMCBv
YmoKPDwgL0Rlc3QgWyA4NCAwIFIgL1hZWiA0Ny41MiA3MTQuOCBudWxsIF0gL0JvcmRlciBbIDAg
MCAwIF0gL1R5cGUgL0Fubm90IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsgNzguMjQgNzgwLjA4IDg4
LjggNzkwLjY0IF0gPj4KZW5kb2JqCjM5IDAgb2JqCjw8IC9EZXN0IFsgODQgMCBSIC9YWVogNDcu
NTIgNzkyLjU2IG51bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QKL1N1YnR5cGUg
L0xpbmsgL1JlY3QgWyA3OC4yNCA3OTEuNiA4OC44IDgwMi4xNiBdID4+CmVuZG9iagozOCAwIG9i
ago8PCAvRGVzdCBbIDc2IDAgUiAvWFlaIDQ3LjUyIDg2Ljk2IG51bGwgXSAvQm9yZGVyIFsgMCAw
IDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsgL1JlY3QgWyA3OC4yNCA4MDMuMTIgODgu
OCA4MTMuNjggXSA+PgplbmRvYmoKMjUgMCBvYmoKPDwgL0Rlc3QgWyA3NiAwIFIgL1hZWiA0Ny41
MiAxNjQuNzIgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdAovU3VidHlwZSAv
TGluayAvUmVjdCBbIDc4LjI0IDM4IDg4LjggNDguNTYgXSA+PgplbmRvYmoKMjQgMCBvYmoKPDwg
L0Rlc3QgWyA3NiAwIFIgL1hZWiA0Ny41MiA3NzUuMjggbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBd
IC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluayAvUmVjdCBbIDkzLjYgNDkuNTIgMTE0LjcyIDYw
LjA4IF0gPj4KZW5kb2JqCjIzIDAgb2JqCjw8IC9EZXN0IFsgNjIgMCBSIC9YWVogNDcuNTIgNzgu
MzIgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBlIC9Bbm5vdCAvU3VidHlwZQovTGluayAv
UmVjdCBbIDc4LjI0IDYxLjA0IDg4LjggNzEuNiBdID4+CmVuZG9iagoyMiAwIG9iago8PCAvRGVz
dCBbIDYyIDAgUiAvWFlaIDQ3LjUyIDIxMC44IG51bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlw
ZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsgL1JlY3QgWyA5My42IDcyLjU2IDExNC43MiA4My4xMiBd
ID4+CmVuZG9iagoyMSAwIG9iago8PCAvRGVzdCBbIDYyIDAgUiAvWFlaIDQ3LjUyIDM3NS45MiBu
dWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rIC9SZWN0
IFsgOTMuNiA4NC4wOCAxMTQuNzIgOTQuNjQgXSA+PgplbmRvYmoKMjAgMCBvYmoKPDwgL0Rlc3Qg
WyA2MiAwIFIgL1hZWiA0Ny41MiA0NjUuMiBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUg
L0Fubm90IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsgNzguMjQgOTUuNiA4OC44IDEwNi4xNiBdID4+
CmVuZG9iagoxOSAwIG9iago8PCAvRGVzdCBbIDYyIDAgUiAvWFlaIDQ3LjUyIDcxNi43MiBudWxs
IF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rIC9SZWN0IFsg
OTMuNiAxMDcuMTIgMTE0LjcyIDExNy42OCBdID4+CmVuZG9iagoxOCAwIG9iago8PCAvRGVzdCBb
IDMxIDAgUiAvWFlaIDQ3LjUyIDIyMy4yOCBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5cGUg
L0Fubm90Ci9TdWJ0eXBlIC9MaW5rIC9SZWN0IFsgOTMuNiAxMTguNjQgMTE0LjcyIDEyOS4yIF0g
Pj4KZW5kb2JqCjE3IDAgb2JqCjw8IC9EZXN0IFsgMzEgMCBSIC9YWVogNDcuNTIgMzU4LjY0IG51
bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsgL1JlY3Qg
WyA3OC4yNCAxMzAuMTYgODguOCAxNDAuNzIgXSA+PgplbmRvYmoKMTYgMCBvYmoKPDwgL0Rlc3Qg
WyAzMSAwIFIgL1hZWiA0Ny41MiA1OTYuNzIgbnVsbCBdIC9Cb3JkZXIgWyAwIDAgMCBdIC9UeXBl
IC9Bbm5vdAovU3VidHlwZSAvTGluayAvUmVjdCBbIDc4LjI0IDE0MS42OCA4OC44IDE1Mi4yNCBd
ID4+CmVuZG9iagoxNSAwIG9iago8PCAvRGVzdCBbIDg0IDAgUiAvWFlaIDUwLjQgNjM0LjE2IG51
bGwgXSAvQm9yZGVyIFsgMCAwIDAgXSAvVHlwZSAvQW5ub3QgL1N1YnR5cGUKL0xpbmsgL1JlY3Qg
WyAyMDIuMDggNTE4Ljk2IDI1NS44NCA1MjkuNTIgXSA+PgplbmRvYmoKMTQgMCBvYmoKPDwgL0Rl
c3QgWyAzIDAgUiAvWFlaIDQ3LjUyIDIwNy45MiBudWxsIF0gL0JvcmRlciBbIDAgMCAwIF0gL1R5
cGUgL0Fubm90IC9TdWJ0eXBlCi9MaW5rIC9SZWN0IFsgNTIyLjcyIDc4Mi45NiA1NDMuODQgNzkw
LjY0IF0gPj4KZW5kb2JqCjIgMCBvYmoKPDwgL0ZpcnN0IDE1MyAwIFIgL0xhc3QgMTU0IDAgUiAv
Q291bnQgMSA+PgplbmRvYmoKMTU0IDAgb2JqCjw8IC9MYXN0IDE1NSAwIFIgL0NvdW50IC0zMyAv
Rmlyc3QgMTU2IDAgUiAvVGl0bGUgKEFsdGVybmF0ZSBFbmNvZGluZyBmb3IgT0F1dGggMiBUb2tl
biBSZXNwb25zZXMgZHJhZnQtcmljaGVyLW9hdXRoLXhtbC0wMSkKL0Rlc3QgWyAzIDAgUiAvWFla
IDQ3LjUyIDcyOC4yNCBudWxsIF0gL1BhcmVudCAxNTcgMCBSID4+CmVuZG9iagoxNTcgMCBvYmoK
PDwgPj4KZW5kb2JqCjE1NiAwIG9iago8PCAvRGVzdCBbIDMgMCBSIC9YWVogNDcuNTIgNjM4Ljk2
IG51bGwgXSAvQ291bnQgMCAvVGl0bGUgKEFic3RyYWN0KSAvTmV4dAoxNTggMCBSIC9QYXJlbnQg
MTU5IDAgUiA+PgplbmRvYmoKMTU5IDAgb2JqCjw8ID4+CmVuZG9iagoxNTggMCBvYmoKPDwgL1By
ZXYgMTYwIDAgUiAvQ291bnQgMCAvVGl0bGUgKFJlcXVpcmVtZW50cyBMYW5ndWFnZSkgL0Rlc3Qg
WyAzIDAgUiAvWFlaCjQ3LjUyIDU3OC40OCBudWxsIF0gL05leHQgMTYxIDAgUiAvUGFyZW50IDE2
MiAwIFIgPj4KZW5kb2JqCjE2MiAwIG9iago8PCA+PgplbmRvYmoKMTYxIDAgb2JqCjw8IC9QcmV2
IDE2MyAwIFIgL0NvdW50IDAgL1RpdGxlIChTdGF0dXMgb2YgdGhpcyBNZW1vKSAvRGVzdCBbIDMg
MCBSIC9YWVoKNDcuNTIgNTA2LjQ4IG51bGwgXSAvTmV4dCAxNjQgMCBSIC9QYXJlbnQgMTY1IDAg
UiA+PgplbmRvYmoKMTY1IDAgb2JqCjw8ID4+CmVuZG9iagoxNjQgMCBvYmoKPDwgL1ByZXYgMTY2
IDAgUiAvQ291bnQgMCAvVGl0bGUgKENvcHlyaWdodCBOb3RpY2UpIC9EZXN0IFsgMyAwIFIgL1hZ
WiA0Ny41MgozNDYuMTYgbnVsbCBdIC9OZXh0IDE2NyAwIFIgL1BhcmVudCAxNjggMCBSID4+CmVu
ZG9iagoxNjggMCBvYmoKPDwgPj4KZW5kb2JqCjE2NyAwIG9iago8PCAvUHJldiAxNjkgMCBSIC9D
b3VudCAwIC9UaXRsZSAoVGFibGUgb2YgQ29udGVudHMpIC9EZXN0IFsgMyAwIFIgL1hZWiA0Ny41
MgoxNzguMTYgbnVsbCBdIC9OZXh0IDE3MCAwIFIgL1BhcmVudCAxNzEgMCBSID4+CmVuZG9iagox
NzEgMCBvYmoKPDwgPj4KZW5kb2JqCjE3MCAwIG9iago8PCAvUHJldiAxNzIgMCBSIC9Db3VudCAw
IC9UaXRsZSAo/v9cMDAwMVwwMDAuXDAwMKBcMDAwIFwwMDBJXDAwMG5cMDAwdFwwMDByXDAwMG9c
MDAwZFwwMDB1XDAwMGNcMDAwdFwwMDBpXDAwMG9cMDAwbikKL0Rlc3QgWyAzMSAwIFIgL1hZWiA0
Ny41MiA1NTUuNDQgbnVsbCBdIC9OZXh0IDE3MyAwIFIgL1BhcmVudCAxNzQgMCBSID4+CmVuZG9i
agoxNzQgMCBvYmoKPDwgPj4KZW5kb2JqCjE3MyAwIG9iago8PCAvUHJldiAxNzUgMCBSIC9Db3Vu
dCAwIC9UaXRsZSAo/v9cMDAwMlwwMDAuXDAwMKBcMDAwIFwwMDBDXDAwMG9cMDAwblwwMDB0XDAw
MGVcMDAwblwwMDB0XDAwMCBcMDAwTlwwMDBlXDAwMGdcMDAwb1wwMDB0XDAwMGlcMDAwYVwwMDB0
XDAwMGlcMDAwb1wwMDBuKQovRGVzdCBbIDMxIDAgUiAvWFlaIDQ3LjUyIDMyOC44OCBudWxsIF0g
L05leHQgMTc2IDAgUiAvUGFyZW50IDE3NyAwIFIgPj4KZW5kb2JqCjE3NyAwIG9iago8PCA+Pgpl
bmRvYmoKMTc2IDAgb2JqCjw8IC9QcmV2IDE3OCAwIFIgL0NvdW50IDAgL1RpdGxlICj+/1wwMDAy
XDAwMC5cMDAwMVwwMDAuXDAwMKBcMDAwIFwwMDBGXDAwMG9cMDAwclwwMDBtXDAwMCBcMDAwUFww
MDBhXDAwMHJcMDAwYVwwMDBtXDAwMGVcMDAwdFwwMDBlXDAwMHIpCi9EZXN0IFsgMzEgMCBSIC9Y
WVogNDcuNTIgMTkzLjUyIG51bGwgXSAvTmV4dCAxNzkgMCBSIC9QYXJlbnQgMTgwIDAgUiA+Pgpl
bmRvYmoKMTgwIDAgb2JqCjw8ID4+CmVuZG9iagoxNzkgMCBvYmoKPDwgL1ByZXYgMTgxIDAgUiAv
Q291bnQgMCAvVGl0bGUgKP7/XDAwMDJcMDAwLlwwMDAyXDAwMC5cMDAwoFwwMDAgXDAwMEFcMDAw
Y1wwMDBjXDAwMGVcMDAwcFwwMDB0XDAwMCBcMDAwSFwwMDBlXDAwMGFcMDAwZFwwMDBlXDAwMHIp
Ci9EZXN0IFsgNjIgMCBSIC9YWVogNDcuNTIgNjg2Ljk2IG51bGwgXSAvTmV4dCAxODIgMCBSIC9Q
YXJlbnQgMTgzIDAgUiA+PgplbmRvYmoKMTgzIDAgb2JqCjw8ID4+CmVuZG9iagoxODIgMCBvYmoK
PDwgL1ByZXYgMTg0IDAgUiAvQ291bnQgMCAvVGl0bGUgKP7/XDAwMDNcMDAwLlwwMDCgXDAwMCBc
MDAwRVwwMDBuXDAwMGNcMDAwb1wwMDBkXDAwMGlcMDAwblwwMDBnKQovRGVzdCBbIDYyIDAgUiAv
WFlaIDQ3LjUyIDQzNS40NCBudWxsIF0gL05leHQgMTg1IDAgUiAvUGFyZW50IDE4NiAwIFIgPj4K
ZW5kb2JqCjE4NiAwIG9iago8PCA+PgplbmRvYmoKMTg1IDAgb2JqCjw8IC9QcmV2IDE4NyAwIFIg
L0NvdW50IDAgL1RpdGxlICj+/1wwMDAzXDAwMC5cMDAwMVwwMDAuXDAwMKBcMDAwIFwwMDBYXDAw
ME1cMDAwTCkKL0Rlc3QgWyA2MiAwIFIgL1hZWiA0Ny41MiAzNDYuMTYgbnVsbCBdIC9OZXh0IDE4
OCAwIFIgL1BhcmVudCAxODkgMCBSID4+CmVuZG9iagoxODkgMCBvYmoKPDwgPj4KZW5kb2JqCjE4
OCAwIG9iago8PCAvUHJldiAxOTAgMCBSIC9Db3VudCAwIC9UaXRsZSAo/v9cMDAwM1wwMDAuXDAw
MDJcMDAwLlwwMDCgXDAwMCBcMDAwRlwwMDBvXDAwMHJcMDAwbVwwMDAgXDAwMEVcMDAwblwwMDBj
XDAwMG9cMDAwZFwwMDBpXDAwMG5cMDAwZykKL0Rlc3QgWyA2MiAwIFIgL1hZWiA0Ny41MiAxODAu
MDggbnVsbCBdIC9OZXh0IDE5MSAwIFIgL1BhcmVudCAxOTIgMCBSID4+CmVuZG9iagoxOTIgMCBv
YmoKPDwgPj4KZW5kb2JqCjE5MSAwIG9iago8PCAvUHJldiAxOTMgMCBSIC9Db3VudCAwIC9UaXRs
ZSAo/v9cMDAwNFwwMDAuXDAwMKBcMDAwIFwwMDBFXDAwMHhcMDAwYVwwMDBtXDAwMHBcMDAwbFww
MDBlXDAwMHMpCi9EZXN0IFsgNjIgMCBSIC9YWVogNDcuNTIgNDguNTYgbnVsbCBdIC9OZXh0IDE5
NCAwIFIgL1BhcmVudCAxOTUgMCBSID4+CmVuZG9iagoxOTUgMCBvYmoKPDwgPj4KZW5kb2JqCjE5
NCAwIG9iago8PCAvUHJldiAxOTYgMCBSIC9Db3VudCAwIC9UaXRsZSAo/v9cMDAwNFwwMDAuXDAw
MDFcMDAwLlwwMDCgXDAwMCBcMDAwU1wwMDB0XDAwMGFcMDAwblwwMDBkXDAwMGFcMDAwclwwMDBk
XDAwMCBcMDAwT1wwMDBBXDAwMHVcMDAwdFwwMDBoXDAwMCBcMDAwVFwwMDBvXDAwMGtcMDAwZVww
MDBuKQovRGVzdCBbIDc2IDAgUiAvWFlaIDQ3LjUyIDc0NC41NiBudWxsIF0gL05leHQgMTk3IDAg
UiAvUGFyZW50IDE5OCAwIFIgPj4KZW5kb2JqCjE5OCAwIG9iago8PCA+PgplbmRvYmoKMTk3IDAg
b2JqCjw8IC9QcmV2IDE5OSAwIFIgL0NvdW50IDAgL1RpdGxlICj+/1wwMDA1XDAwMC5cMDAwoFww
MDAgXDAwMElcMDAwQVwwMDBOXDAwMEFcMDAwIFwwMDBDXDAwMG9cMDAwblwwMDBzXDAwMGlcMDAw
ZFwwMDBlXDAwMHJcMDAwYVwwMDB0XDAwMGlcMDAwb1wwMDBuXDAwMHMpCi9EZXN0IFsgNzYgMCBS
IC9YWVogNDcuNTIgMTM0IG51bGwgXSAvTmV4dCAyMDAgMCBSIC9QYXJlbnQgMjAxIDAgUiA+Pgpl
bmRvYmoKMjAxIDAgb2JqCjw8ID4+CmVuZG9iagoyMDAgMCBvYmoKPDwgL1ByZXYgMjAyIDAgUiAv
Q291bnQgMCAvVGl0bGUgKP7/XDAwMDZcMDAwLlwwMDCgXDAwMCBcMDAwU1wwMDBlXDAwMGNcMDAw
dVwwMDByXDAwMGlcMDAwdFwwMDB5XDAwMCBcMDAwQ1wwMDBvXDAwMG5cMDAwc1wwMDBpXDAwMGRc
MDAwZVwwMDByXDAwMGFcMDAwdFwwMDBpXDAwMG9cMDAwblwwMDBzKQovRGVzdCBbIDc2IDAgUiAv
WFlaIDQ3LjUyIDU3LjIgbnVsbCBdIC9OZXh0IDIwMyAwIFIgL1BhcmVudCAyMDQgMCBSID4+CmVu
ZG9iagoyMDQgMCBvYmoKPDwgPj4KZW5kb2JqCjIwMyAwIG9iago8PCAvUHJldiAyMDUgMCBSIC9D
b3VudCAwIC9UaXRsZSAo/v9cMDAwN1wwMDAuXDAwMKBcMDAwIFwwMDBBXDAwMGNcMDAwa1wwMDBu
XDAwMG9cMDAwd1wwMDBsXDAwMGVcMDAwZFwwMDBnXDAwMGVcMDAwbVwwMDBlXDAwMG5cMDAwdFww
MDBzKQovRGVzdCBbIDg0IDAgUiAvWFlaIDQ3LjUyIDc2Mi44IG51bGwgXSAvTmV4dCAyMDYgMCBS
IC9QYXJlbnQgMjA3IDAgUiA+PgplbmRvYmoKMjA3IDAgb2JqCjw8ID4+CmVuZG9iagoyMDYgMCBv
YmoKPDwgL1ByZXYgMjA4IDAgUiAvQ291bnQgMCAvVGl0bGUgKP7/XDAwMDhcMDAwLlwwMDCgXDAw
ME5cMDAwb1wwMDByXDAwMG1cMDAwYVwwMDB0XDAwMGlcMDAwdlwwMDBlXDAwMCBcMDAwUlwwMDBl
XDAwMGZcMDAwZVwwMDByXDAwMGVcMDAwblwwMDBjXDAwMGVcMDAwcykKL0Rlc3QgWyA4NCAwIFIg
L1hZWiA0Ny41MiA2ODUuMDQgbnVsbCBdIC9OZXh0IDIwOSAwIFIgL1BhcmVudCAyMTAgMCBSID4+
CmVuZG9iagoyMTAgMCBvYmoKPDwgPj4KZW5kb2JqCjIwOSAwIG9iago8PCAvUHJldiAyMTEgMCBS
IC9Db3VudCAwIC9UaXRsZSAo/v9cMDAwQVwwMDBwXDAwMHBcMDAwZVwwMDBuXDAwMGRcMDAwaVww
MDB4XDAwMCBcMDAwQVwwMDAuXDAwMKBcMDAwIFwwMDBHXDAwMGVcMDAwblwwMDBlXDAwMHJcMDAw
YVwwMDBsXDAwMCBcMDAwWFwwMDBNXDAwMExcMDAwIFwwMDBFXDAwMG5cMDAwY1wwMDBvXDAwMGRc
MDAwaVwwMDBuXDAwMGdcMDAwIFwwMDBSXDAwMHVcMDAwbFwwMDBlXDAwMHMpCi9EZXN0IFsgODQg
MCBSIC9YWVogNDcuNTIgNTQxLjA0IG51bGwgXSAvTmV4dCAyMTIgMCBSIC9QYXJlbnQgMjEzIDAg
UiA+PgplbmRvYmoKMjEzIDAgb2JqCjw8ID4+CmVuZG9iagoyMTIgMCBvYmoKPDwgL1ByZXYgMjE0
IDAgUiAvQ291bnQgMCAvVGl0bGUgKP7/XDAwMEFcMDAwLlwwMDAxXDAwMC5cMDAwoFwwMDAgXDAw
ME9cMDAwYlwwMDBqXDAwMGVcMDAwY1wwMDB0XDAwMHNcMDAwIFwwMDBhXDAwMG5cMDAwZFwwMDAg
XDAwME1cMDAwZVwwMDBtXDAwMGJcMDAwZVwwMDByXDAwMHMpCi9EZXN0IFsgODQgMCBSIC9YWVog
NDcuNTIgNDE4LjE2IG51bGwgXSAvTmV4dCAyMTUgMCBSIC9QYXJlbnQgMjE2IDAgUiA+PgplbmRv
YmoKMjE2IDAgb2JqCjw8ID4+CmVuZG9iagoyMTUgMCBvYmoKPDwgL1ByZXYgMjE3IDAgUiAvQ291
bnQgMCAvVGl0bGUgKP7/XDAwMEFcMDAwLlwwMDAyXDAwMC5cMDAwoFwwMDAgXDAwMFRcMDAweVww
MDBwXDAwMGVcMDAwIFwwMDBJXDAwMGRcMDAwZVwwMDBuXDAwMHRcMDAwaVwwMDBmXDAwMGlcMDAw
ZVwwMDByXDAwMHMpCi9EZXN0IFsgODQgMCBSIC9YWVogNDcuNTIgMjk0LjMyIG51bGwgXSAvTmV4
dCAyMTggMCBSIC9QYXJlbnQgMjE5IDAgUiA+PgplbmRvYmoKMjE5IDAgb2JqCjw8ID4+CmVuZG9i
agoyMTggMCBvYmoKPDwgL1ByZXYgMjIwIDAgUiAvQ291bnQgMCAvVGl0bGUgKP7/XDAwMEFcMDAw
LlwwMDAzXDAwMC5cMDAwoFwwMDAgXDAwMFNcMDAwdFwwMDByXDAwMGlcMDAwblwwMDBnXDAwMHNc
MDAwIFwwMDBhXDAwMG5cMDAwZFwwMDAgXDAwME5cMDAwdVwwMDBtXDAwMGJcMDAwZVwwMDByXDAw
MHMpCi9EZXN0IFsgODQgMCBSIC9YWVogNDcuNTIgMTgyIG51bGwgXSAvTmV4dCAyMjEgMCBSIC9Q
YXJlbnQgMjIyIDAgUiA+PgplbmRvYmoKMjIyIDAgb2JqCjw8ID4+CmVuZG9iagoyMjEgMCBvYmoK
PDwgL1ByZXYgMjIzIDAgUiAvQ291bnQgMCAvVGl0bGUgKP7/XDAwMEFcMDAwLlwwMDA0XDAwMC5c
MDAwoFwwMDAgXDAwMEFcMDAwclwwMDByXDAwMGFcMDAweVwwMDBzKQovRGVzdCBbIDg0IDAgUiAv
WFlaIDQ3LjUyIDgxLjIgbnVsbCBdIC9OZXh0IDIyNCAwIFIgL1BhcmVudCAyMjUgMCBSID4+CmVu
ZG9iagoyMjUgMCBvYmoKPDwgPj4KZW5kb2JqCjIyNCAwIG9iago8PCAvUHJldiAyMjYgMCBSIC9D
b3VudCAwIC9UaXRsZSAo/v9cMDAwQVwwMDAuXDAwMDVcMDAwLlwwMDCgXDAwMCBcMDAwTlwwMDBh
XDAwMG1cMDAwZVwwMDBzXDAwMHBcMDAwYVwwMDBjXDAwMGUpCi9EZXN0IFsgMTA4IDAgUiAvWFla
IDQ3LjUyIDc2Mi44IG51bGwgXSAvTmV4dCAyMjcgMCBSIC9QYXJlbnQgMjI4IDAgUiA+PgplbmRv
YmoKMjI4IDAgb2JqCjw8ID4+CmVuZG9iagoyMjcgMCBvYmoKPDwgL1ByZXYgMjI5IDAgUiAvQ291
bnQgMCAvVGl0bGUgKP7/XDAwMEFcMDAwLlwwMDA2XDAwMC5cMDAwoFwwMDAgXDAwMElcMDAwblww
MDBmXDAwMG9cMDAwclwwMDBtXDAwMGFcMDAwdFwwMDBpXDAwMG9cMDAwblwwMDAgXDAwMExcMDAw
b1wwMDBzXDAwMHMpCi9EZXN0IFsgMTA4IDAgUiAvWFlaIDQ3LjUyIDY3My41MiBudWxsIF0gL05l
eHQgMjMwIDAgUiAvUGFyZW50IDIzMSAwIFIgPj4KZW5kb2JqCjIzMSAwIG9iago8PCA+PgplbmRv
YmoKMjMwIDAgb2JqCjw8IC9QcmV2IDIzMiAwIFIgL0NvdW50IDAgL1RpdGxlICj+/1wwMDBBXDAw
MC5cMDAwN1wwMDAuXDAwMKBcMDAwIFwwMDBFXDAwMHhcMDAwYVwwMDBtXDAwMHBcMDAwbFwwMDBl
XDAwMHMpCi9EZXN0IFsgMTA4IDAgUiAvWFlaIDQ3LjUyIDQ3MC45NiBudWxsIF0gL05leHQgMjMz
IDAgUiAvUGFyZW50IDIzNCAwIFIgPj4KZW5kb2JqCjIzNCAwIG9iago8PCA+PgplbmRvYmoKMjMz
IDAgb2JqCjw8IC9QcmV2IDIzNSAwIFIgL0NvdW50IDAgL1RpdGxlICj+/1wwMDBBXDAwMHBcMDAw
cFwwMDBlXDAwMG5cMDAwZFwwMDBpXDAwMHhcMDAwIFwwMDBCXDAwMC5cMDAwoFwwMDAgXDAwMEdc
MDAwZVwwMDBuXDAwMGVcMDAwclwwMDBhXDAwMGxcMDAwIFwwMDBGXDAwMG9cMDAwclwwMDBtXDAw
MCBcMDAwRVwwMDBuXDAwMGNcMDAwb1wwMDBkXDAwMGlcMDAwblwwMDBnXDAwMCBcMDAwUlwwMDB1
XDAwMGxcMDAwZVwwMDBzKQovRGVzdCBbIDEyMCAwIFIgL1hZWiA0Ny41MiAyNTMuMDQgbnVsbCBd
IC9OZXh0IDIzNiAwIFIgL1BhcmVudCAyMzcgMCBSID4+CmVuZG9iagoyMzcgMCBvYmoKPDwgPj4K
ZW5kb2JqCjIzNiAwIG9iago8PCAvUHJldiAyMzggMCBSIC9Db3VudCAwIC9UaXRsZSAo/v9cMDAw
QlwwMDAuXDAwMDFcMDAwLlwwMDCgXDAwMCBcMDAwT1wwMDBiXDAwMGpcMDAwZVwwMDBjXDAwMHRc
MDAwc1wwMDAgXDAwMGFcMDAwblwwMDBkXDAwMCBcMDAwTVwwMDBlXDAwMG1cMDAwYlwwMDBlXDAw
MHJcMDAwcykKL0Rlc3QgWyAxMjAgMCBSIC9YWVogNDcuNTIgMTE3LjY4IG51bGwgXSAvTmV4dCAy
MzkgMCBSIC9QYXJlbnQgMjQwIDAgUiA+PgplbmRvYmoKMjQwIDAgb2JqCjw8ID4+CmVuZG9iagoy
MzkgMCBvYmoKPDwgL1ByZXYgMjQxIDAgUiAvQ291bnQgMCAvVGl0bGUgKP7/XDAwMEJcMDAwLlww
MDAyXDAwMC5cMDAwoFwwMDAgXDAwMFNcMDAwdFwwMDByXDAwMGlcMDAwblwwMDBnXDAwMHNcMDAw
IFwwMDBhXDAwMG5cMDAwZFwwMDAgXDAwME5cMDAwdVwwMDBtXDAwMGJcMDAwZVwwMDByXDAwMHMp
Ci9EZXN0IFsgMTI3IDAgUiAvWFlaIDQ3LjUyIDc4My45MiBudWxsIF0gL05leHQgMjQyIDAgUiAv
UGFyZW50IDI0MyAwIFIgPj4KZW5kb2JqCjI0MyAwIG9iago8PCA+PgplbmRvYmoKMjQyIDAgb2Jq
Cjw8IC9QcmV2IDI0NCAwIFIgL0NvdW50IDAgL1RpdGxlICj+/1wwMDBCXDAwMC5cMDAwM1wwMDAu
XDAwMKBcMDAwIFwwMDBBXDAwMHJcMDAwclwwMDBhXDAwMHlcMDAwcykKL0Rlc3QgWyAxMjcgMCBS
IC9YWVogNDcuNTIgNzA2LjE2IG51bGwgXSAvTmV4dCAyNDUgMCBSIC9QYXJlbnQgMjQ2IDAgUiA+
PgplbmRvYmoKMjQ2IDAgb2JqCjw8ID4+CmVuZG9iagoyNDUgMCBvYmoKPDwgL1ByZXYgMjQ3IDAg
UiAvQ291bnQgMCAvVGl0bGUgKP7/XDAwMEJcMDAwLlwwMDA0XDAwMC5cMDAwoFwwMDAgXDAwMElc
MDAwblwwMDBmXDAwMG9cMDAwclwwMDBtXDAwMGFcMDAwdFwwMDBpXDAwMG9cMDAwblwwMDAgXDAw
MExcMDAwb1wwMDBzXDAwMHMpCi9EZXN0IFsgMTI3IDAgUiAvWFlaIDQ3LjUyIDYxNy44NCBudWxs
IF0gL05leHQgMjQ4IDAgUiAvUGFyZW50IDI0OSAwIFIgPj4KZW5kb2JqCjI0OSAwIG9iago8PCA+
PgplbmRvYmoKMjQ4IDAgb2JqCjw8IC9QcmV2IDI1MCAwIFIgL0NvdW50IDAgL1RpdGxlICj+/1ww
MDBCXDAwMC5cMDAwNVwwMDAuXDAwMKBcMDAwIFwwMDBFXDAwMHhcMDAwYVwwMDBtXDAwMHBcMDAw
bFwwMDBlXDAwMHMpCi9EZXN0IFsgMTI3IDAgUiAvWFlaIDQ3LjUyIDQxNC4zMiBudWxsIF0gL05l
eHQgMjUxIDAgUiAvUGFyZW50IDI1MiAwIFIgPj4KZW5kb2JqCjI1MiAwIG9iago8PCA+PgplbmRv
YmoKMjUxIDAgb2JqCjw8IC9QcmV2IDI1MyAwIFIgL0NvdW50IDAgL1RpdGxlIChBdXRob3IncyBB
ZGRyZXNzKSAvRGVzdCBbIDEyNyAwIFIgL1hZWiA0Ny41MgoxNjAuODggbnVsbCBdIC9QYXJlbnQg
MjU0IDAgUiA+PgplbmRvYmoKMjU0IDAgb2JqCjw8ID4+CmVuZG9iagoyNTMgMCBvYmoKPDwgL1Bh
cmVudCAyNTIgMCBSID4+CmVuZG9iagoyNTAgMCBvYmoKPDwgL1BhcmVudCAyNDkgMCBSID4+CmVu
ZG9iagoyNDcgMCBvYmoKPDwgL1BhcmVudCAyNDYgMCBSID4+CmVuZG9iagoyNDQgMCBvYmoKPDwg
L1BhcmVudCAyNDMgMCBSID4+CmVuZG9iagoyNDEgMCBvYmoKPDwgL1BhcmVudCAyNDAgMCBSID4+
CmVuZG9iagoyMzggMCBvYmoKPDwgL1BhcmVudCAyMzcgMCBSID4+CmVuZG9iagoyMzUgMCBvYmoK
PDwgL1BhcmVudCAyMzQgMCBSID4+CmVuZG9iagoyMzIgMCBvYmoKPDwgL1BhcmVudCAyMzEgMCBS
ID4+CmVuZG9iagoyMjkgMCBvYmoKPDwgL1BhcmVudCAyMjggMCBSID4+CmVuZG9iagoyMjYgMCBv
YmoKPDwgL1BhcmVudCAyMjUgMCBSID4+CmVuZG9iagoyMjMgMCBvYmoKPDwgL1BhcmVudCAyMjIg
MCBSID4+CmVuZG9iagoyMjAgMCBvYmoKPDwgL1BhcmVudCAyMTkgMCBSID4+CmVuZG9iagoyMTcg
MCBvYmoKPDwgL1BhcmVudCAyMTYgMCBSID4+CmVuZG9iagoyMTQgMCBvYmoKPDwgL1BhcmVudCAy
MTMgMCBSID4+CmVuZG9iagoyMTEgMCBvYmoKPDwgL1BhcmVudCAyMTAgMCBSID4+CmVuZG9iagoy
MDggMCBvYmoKPDwgL1BhcmVudCAyMDcgMCBSID4+CmVuZG9iagoyMDUgMCBvYmoKPDwgL1BhcmVu
dCAyMDQgMCBSID4+CmVuZG9iagoyMDIgMCBvYmoKPDwgL1BhcmVudCAyMDEgMCBSID4+CmVuZG9i
agoxOTkgMCBvYmoKPDwgL1BhcmVudCAxOTggMCBSID4+CmVuZG9iagoxOTYgMCBvYmoKPDwgL1Bh
cmVudCAxOTUgMCBSID4+CmVuZG9iagoxOTMgMCBvYmoKPDwgL1BhcmVudCAxOTIgMCBSID4+CmVu
ZG9iagoxOTAgMCBvYmoKPDwgL1BhcmVudCAxODkgMCBSID4+CmVuZG9iagoxODcgMCBvYmoKPDwg
L1BhcmVudCAxODYgMCBSID4+CmVuZG9iagoxODQgMCBvYmoKPDwgL1BhcmVudCAxODMgMCBSID4+
CmVuZG9iagoxODEgMCBvYmoKPDwgL1BhcmVudCAxODAgMCBSID4+CmVuZG9iagoxNzggMCBvYmoK
PDwgL1BhcmVudCAxNzcgMCBSID4+CmVuZG9iagoxNzUgMCBvYmoKPDwgL1BhcmVudCAxNzQgMCBS
ID4+CmVuZG9iagoxNzIgMCBvYmoKPDwgL1BhcmVudCAxNzEgMCBSID4+CmVuZG9iagoxNjkgMCBv
YmoKPDwgL1BhcmVudCAxNjggMCBSID4+CmVuZG9iagoxNjYgMCBvYmoKPDwgL1BhcmVudCAxNjUg
MCBSID4+CmVuZG9iagoxNjMgMCBvYmoKPDwgL1BhcmVudCAxNjIgMCBSID4+CmVuZG9iagoxNjAg
MCBvYmoKPDwgL1BhcmVudCAxNTkgMCBSID4+CmVuZG9iagoxNTUgMCBvYmoKPDwgL1ByZXYgMjUz
IDAgUiAvQ291bnQgMCAvVGl0bGUgKEF1dGhvcidzIEFkZHJlc3MpIC9EZXN0IFsgMTI3IDAgUiAv
WFlaIDQ3LjUyCjE2MC44OCBudWxsIF0gL1BhcmVudCAyNTQgMCBSID4+CmVuZG9iagoxNTMgMCBv
YmoKPDwgL0xhc3QgMTU1IDAgUiAvQ291bnQgLTMzIC9GaXJzdCAxNTYgMCBSIC9UaXRsZSAoQWx0
ZXJuYXRlIEVuY29kaW5nIGZvciBPQXV0aCAyIFRva2VuIFJlc3BvbnNlcyBkcmFmdC1yaWNoZXIt
b2F1dGgteG1sLTAxKQovRGVzdCBbIDMgMCBSIC9YWVogNDcuNTIgNzI4LjI0IG51bGwgXSAvUGFy
ZW50IDE1NyAwIFIgPj4KZW5kb2JqCjkgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1R5
cGUwIC9FbmNvZGluZyAvSWRlbnRpdHktSCAvRGVzY2VuZGFudEZvbnRzIFsyNTUgMCBSXQovQmFz
ZUZvbnQgL05BQUREVytCaXRzdHJlYW1WZXJhU2Fucy1Cb2xkIC9Ub1VuaWNvZGUgMjU2IDAgUiA+
PgplbmRvYmoKMjU2IDAgb2JqCjw8IC9MZW5ndGggMjU3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PgpzdHJlYW0KeAFdkM1qxDAMhO9+Ch23h8W7PYdA2VLIoT807QN47UkwNLJRnEPevrJbtlCB
Dx75G41sL8PjwLGQfZPkRxSaIgfBmjbxoCvmyOZ8TyH68ntrml9cNlbhcV8LloGnRF1niOy7ImuR
nQ4PIV1xV7VXCZDIMx0+L2NTxi3nLyzgQifT9xQwqd2zyy9uAdmGHoeg/Vj2o1J/Lz72DNJESpx/
IvkUsGbnIY5nmO6k1XdPWr0Bh3/tqtT0t2l+E9FBbcWWoXpHxu0XcsrVp51vZopkswplbmRzdHJl
YW0KZW5kb2JqCjI1NyAwIG9iagoyMDgKZW5kb2JqCjI1NSAwIG9iago8PCAvVHlwZSAvRm9udCAv
U3VidHlwZSAvQ0lERm9udFR5cGUyIC9CYXNlRm9udCAvTkFBRERXK0JpdHN0cmVhbVZlcmFTYW5z
LUJvbGQKL0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lzdHJ5IChBZG9iZSkgL09yZGVyaW5nIChJZGVu
dGl0eSkgL1N1cHBsZW1lbnQgMCA+PgovVyAyNTggMCBSIC9EVyAxMDAwIC9Gb250RGVzY3JpcHRv
ciAyNTkgMCBSID4+CmVuZG9iagoyNTggMCBvYmoKWyAxIFsgMzQ4IDY4MiA4NTAgNzM0IDY5NiAz
ODAgMzcyIDcxMiA0NzggNDkzIDY4NyA3MTYgNzEyIDU5MyAzNDMgNjk2IDY3OAo4MzcgNzE2IDY3
NSA2ODMgMTA0MiA3MzMgNzc0IDcxNiA4MzcgNjk2IDY4MyA3NzEgOTk1IDYzNyA2OTYgNjQ1IDM0
MyA1OTUgNzIwCjcxMiA2NjUgNjk2IDc3MCA2OTYgNjk2IDY1MiA2OTYgOTI0IDY5NiA2NTIgNDM1
IDgyMSA3MTYgMzQzIDc2MiA1MDAgMzA2IDM3Mgo0NTcgNDE1IDgzMCA0NTcgNjk2IDU4MiAzODAg
Nzc1IDcxNiAzNjUgNDU3IDQ1NyAxMTAzIDQwMCAxMDAwIF0gXQplbmRvYmoKMjU5IDAgb2JqCjw8
IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL05BQUREVytCaXRzdHJlYW1WZXJhU2Fu
cy1Cb2xkIC9GbGFncyAzMgovRm9udEJCb3ggWy01NiAtMjE2IDEwNzIgNzYwXSAvSXRhbGljQW5n
bGUgMCAvQXNjZW50IDkyOCAvRGVzY2VudCAtMjM2IC9DYXBIZWlnaHQKODI1IC9TdGVtViAwIC9Y
SGVpZ2h0IDYxOSAvQXZnV2lkdGggNTczIC9NYXhXaWR0aCAxNDAwIC9Gb250RmlsZTIgMjYwIDAg
Ugo+PgplbmRvYmoKMjYwIDAgb2JqCjw8IC9MZW5ndGggMjYxIDAgUiAvTGVuZ3RoMSAxNDczMiAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1e3tgU1We/zk3j9Yij0IfPOWmpZRK7btU
KwX6SNtAm5Y0LS2wpWmbtIE0qUnaUqA8BER0UBBRRAYrr+GnjMO4Ojur1dlZx9+sq+A6yuw4DCA+
xnVF1/U36yo0l9/ne25uU9DV+eP3S0hz77nnfB+f7/OcFsYZY9FsM9MxVlOXmfP8zv8uwsiP8Gno
8PS7Vr3zYTOuP2Rs8kOdTkd7R67FztiUtRib14mBCbro13F/CvezOruCa71TTMtw/w5jfLrH1+Z4
u+jd3zM29Qs8393lWNvNlrAOxqZtxr3sdXQ5/67p9K9wP8jYjE8Z1++ThpiB6Q0V+jcYU0rUb6mO
S5IrWpLGROt0Rr0k6bH8ZxOYvBhUxKvEHQwwmclXJWOcEscPRHXxD/CAdKOXxFzKI3qX4Si0jGJs
UqwpNsUUa3Lp2XBAN234I+WRqHFff+k3pmFFDGOG1YazYh7m0DvG0KLEKpuUCYazyvmrVv2zRNF5
7QOjy/AFG89mglFSlDHRmJhQkFAwLz8vdbZOn5gQOyHKaJJTZ0+SCubpXKccrZy3Ok6danU4Wk/x
zjfwUvYrj71xhvMzb+jfvXvrp5e3bOV865bLn269myfy02eUfcq+02fOnOZr+Jozp0kb17X3DSvB
08RYijHKmArqsRMK5plyEhMSY2enzk4Oi5ELMQoMK9f4gxuU+9794x/f5b0bgv41no7OwJnePs77
es8EOjs8ttunzeBv/Qt3ctdb/zJ9xjzl9crkpG3b/u3jbdt4sgngcvYx0NADDaAyyRRrELDFmr7g
duUIX8G93H71Mo/RvVrJjZVX85WvsOItgHMH30r+hBWmt3insp9vVQaI2hCeFYFa+NkQ36JsMpy9
MpeenQSnifr1bDpuYk35sUCR3snQM5GMED+vYF5uQmKCYaKy3xg9Pn7WrIy7FhZz5QB31a5c4f21
q116KtTg44/vvr1galL8JF6/7LHQu/qWo46sDN67FhymMaY7ajjE4gUH0CSD5caaklJn58cmx+bG
Srn8LuVBLs9c+Uvl9DuNTc8+azik/OM1pqRYAdQ11tT4Dj/HGV8Qlld3GfIStTD08ZqcBWQQ3eXM
jKyM+y1LSETz8saNE+Pj0nSZCWNiGpuOhYb1Lb/sysvmXKcnb2q89oEhFdRGvCk+LjEhNwdmBG2d
HPEmsrf067VFCxcWre1ZUMR50YIeLh89fPio8p5y4cjRo0d06+uXDT5Z39BQ/+TgsnrODh5ULiuX
D+LF43jcwYPgtgJ+NM4Yx+LYrDAW+eROAIKclaTXgTU5suZRuuNkxyWNTT1vbr+H83u2vxlY0fik
f8H8+Qv8/vkLOF8wXzckNX5z+XBbRiY/doTruQ4/M7KG/9le9+SgHa/BJ+vssMIgNDXqWyhqEIfx
cWrgAK+EAuJJEJIwyRBmkHdyifPoqNiEWUmZvuJF3KUcWLp8peeVdhd/TjrZvfLe+zLuLZw/LXlS
HG+oPyClXR083JqR2dcLPo3X3tfnA1HECtdig0ClEC2IHRU9KVBXn7+4cnHNoza73fZoXfXi4vr6
ZcuUt57Gi2c2Ntj1RcqfsqdMXtZ08FBDE+dTJ+co5+RxsfzgAZ7A4/FzfCxQhQdLE4GqmmOgB71P
ksz00bdcHURy+hP5zmHG9BcRx7fghmZx+HYBoQ2xomLJ0WFxgiZKskp7rr4imSzJSby8omfFak//
ls2b1vGb9z28cOE/82nKR3wav1SycGFZJ+BJSa3ilXMTE3r7frfOveYUZFoGS8cAhaksGbziTYBZ
JAcNALK3CcwMFGzIHlGGmOEXx1qtP+pe2zuweePmjcqbP3mK858c40k8+okfK3t44fwW96LiCVKu
a+PChUgTZcrlrMlT+eMHkLNiD/34icGHXAuLMKsLeiLeDV8h3m+iXMAJDvwY4s9IM3mXYgtdUvYa
zg4zPbsyF5lY5OmVitkwTt8Pv8wL5ziKzjwgQiGVb4qVkFSNkDWWNCGH0UFqESxkVwqW4+SlZ7bf
c8/2Mz1NjUvgQ//raWVotaO1rXl508qf1dkudxctmH9nsFuNnpfhMPzw4NUrhwczMluPD8cqXz7w
II+dYOKJBVOmVVcd0xltdfset9byOtu+fXU2itZl1z7QvwpUx7JMoAqjxSOVEK75+SkR9y2YXTAv
JVdEkWbXAtQF6fBdBXfwzNuWtpebuVt5tHL58i3PeLyc79zBk94uLdsVbG2rDwQDPTxzx3b+NYxq
Maek8sUV3rQdoS3HXRmZrvYjv/mbFXy6PS2VJyRm8Njp48dy3tuvIq5/XUNc9UAgrh8f8ksdocco
2yrnlX9Xzod2QHD2FGNRz0GPDNyQ1wFTyrV5BXn5mj/gNnw5kt1omv6F0lUr7/q1s50r+yWelGx1
QSck+pmyrbPgdlx0ljTYOwPLG3XHO26fh/z7fqhBqhw7buy03oI8brc/EfqjVPnCPFw2HBRZujk7
ixfcAWzJZ3ZCg5tZInkNfDMR6KUkk+8IiClOhqRNfMZjj3L+6GPKB4qyiW8561tQVLTAZzi7cfMn
lwc289AV/cvKKn57vrN93jyyGSqYMRV0o+iKm3QmLt46fXno+CplQErjr0tpykDoBH/sDT5B+YLq
kpQiCXufVBoMzcBJ5EtYOFKNqMhTqpoU9kKRwyChNJGi3rJiec+Ze7Zvv+dMz/IVx4LzFyyYHxQ5
83DoOWOMqExHjikhZfjIscwMXYG94dAT9gauJkyyjxY/Y9RaOmJPvkW6nWpn6J/IoqHfSndA1n7V
pjuR9z5HbkH8wDkS4gHeSMAI6WDO5OR8kQUgqAh6kXLgmpRydC88UmulkHkx6O/p9qxxd+6vW8pt
9iMHDu+pKOdm88bm5lXNd93V7eFJD+02m3UpqS2tD18IBHlc7GyeNg+VMj+v3ZWf9zV8/G/qUXzj
E+bwqTNjJ/Dmln/YZqMaAL30l2CLG/XS/FQ6evWc5qnKU8p5wiIV9pPUNRym0/7phiWj4lOOKMeV
LlyN4w/xCl7OH5auhIxcUSTpinROmckvqVyj7hCeRdlITbzJIiH9O7fzBv6J8rBy4i/KCZGVLulm
IiuVDZ/TpVyFuBGZDZot0L2ocl61koQSWwnPzQV9CXmBgb7OhJ4Cfou39KWynB9fxE+ePas8HFqt
3x96UPfMsE35RPmCT+CLiT7qITJ1C2GCtZOEhDp46W8VD1//0b/x9fg+oWwf/kbZLhVJycpzvCp0
MfRr3qocwupI7RFdl6g6xrhvLhPl1chWrfDeXNyMroSJiTB5IkxOHdBIQqU6lIp/IutSK6BPDK72
NLuyc2bPal3IJ7Y0823blCu+3rUbVvu7g+78PD5rtmfhf7S0rOsPtXq7UCu/yJo8ecq0vPSEyTE3
zaqpffpvly+fOGEWn5A/ZeqM6YVZkxPGRd+ydOmxZxvq+fgJJOFeVKnb4LMjElJKRa1OxD/hwSmj
JaSMOiIh9b7619f39HbcV1Jy29zeo9+43XzPXuXtBx/Y/cADO7YNDJSV3pa5Y997HZ27d/Nx67Zu
MRxXfjNvxnTk1Zr5puREU46r48Wv+9bxadPyubk6JfXWW63ls1NmmrLcnX97ce3aiXEkoehOUdun
E4bf0Z2KCIKwP9SdPvbQ6O7UGBc6EW5Pwzz6wQP5CZ2z6uCigeAH+WDovGRVrAqaSWPc8M/54yEl
dJi/rdyGdYeAHkVGiuqZolGmtEmWNY62bDiRR72reynUOzdjbjaP3f8oP/YT5dzm9QPr+32e1vtt
NZzX2O6va161BgH40cdjoo337vzL/7l3JzU9PLMiKdlc2ttbVsrjE9PJ5xEaRgbeMSwJyISbxtTk
2Fhy+3DujgIuiZNMOmIvXezPz8vL7z+sbJKqeOp993JeXrm7ZmFR8VuK6xe3F9zRrFt4W3qnK30u
V7YoX4VQy9rafr+vedVtExcWb1YaeaA7bQ62dRJzUw9r+JzJLIuxAmoHKLsVwHOoj81H7TVpmzCA
oIlG/Sx51ukV9XV1J1taYs1V1cv/fP8ufuggj+LJTw6+OKS86G5x8M3tebm5ee3OXLxMPC49LpG3
NL+UM2Uqet8/fvHQHv6bV7F92/W7d3jsOOk/ShZtu7sEr7u3LSqBbBshWzJkG0+yif5gVDevxiDk
jNJKLgyVEt4okjtLH7myc3OzXa5cbA+yc3nvKnt9zU9XtUwoqa5a+dGu+/mPDynfKOefeJLzob/n
5a5Wh3SJLyol3iRH6SLpjHI5PTGeNztezJo6mW+/590vdj/EX32Fr+b+d96eEAufmaKUY7fVwmLJ
Z5BvSEiqCgRhwRTu4rdxhq41raK55cCb3StunTMZuSkULX19dd6QZcmnM6ZXzQSVncjjn8P6RqIS
DyqmnXpn6AVlp5QayjacffeqXv8CRU8l+owZ4HYzzUNqo+xmQnKr5CuHXuJz8VmpvKv0vzSk9Otb
hod1+pBeGr46qJOGFXTTA9gxTER2IDQXqXjSXlt0f0gFKfAr6hDJ3KJnJncj3wekNF4wKQy+yBuw
v/Sap/BOzu8s9KwuvOOOQmVgZ5l51y4ey8fv2mWu2PFoTRXfu0+5qJx/eJ+16rHlOdkrm3Kys3Oa
VmbnSAeps/UW3nlnodd3Z+GmOQ32zS+1tXFH28ub7Q1zbm1etftit9/ffXH3quZb+dymLLyaGrMz
eBY5gsjxU4CDwItQN80E1InYRHQoFUofdL+iM14dxMxU7FV3IRfQ7jJeOG081RET7VNFO6zb9b+r
Z9zCc5QzyoFnn3U5/9UY9+m0GaXWa2x4UNfCmfUXTctAxwXsrgA75AY6MUi+8cQgFYOieybDU7Ey
XNlz4PFjdGpw4QK/++H7dqwbQG7484aBtWvP35mfm/ap1OhDFhCnBu433xSnBuWzkjjfdPfnn23Z
Em2MxU5BQgycBOdmaDCe9pgp4cyghZ8u7Ppa+5RK2umYup8UfdK663onC3VTH4d3kqJLkn5PiTPS
PbUeBi/p2pBSLvZgY1XPjoUfaM0OwYe66PGc/vkC1+wUHt6UPXept+9Tnpmxw8iwOdOxoWvXRP8Z
wxJYGtBHV0/biuTk2Em4FN08bECtlehLQRRpTjROE1dkZnCekbni7PuB+YWFdwbff5+7NiBX8j0P
Kb8PbZFK+Lxd9+fm6vbytDnWqlvnKL8JBXhOdltLTpbSL02Z5Wj90R9Wr+GGs82rzniXVDOgOO5a
ke5r2K+YLSVPIEHCGQz8RWmk7ErsqQtNzccNbXCFq4fjgqSndEhtO4V5IhVW4E+FXtfTVlN7e1XK
7KEp435XW4MOvKcqNaV/3TsNTSud/pUr7lg0J/W5WZPewKSCu6pmmnjQ/5p9+XLlQJkpmS8o+sUi
WN5cbvjFB6lxkyZPzSiz3qxfXt+4oaemNuvWgjssD9ns48fe8llafCJtmtPKF4+9adnyxq0d1qq8
3NsLluxeupSPnRC6Z0ZKanZZVk5xQtrs/NJ8alzZK7qn+ClkFpwUcbglP/UZ+tyzEp0UXduluMQp
Eros1Ek6ZYNBSGl0ZI/uV05b569dgFOmK0PKJ/fdx5N5WclWUDylfKmbAR+JErkKZos3nZK6lI/5
lNBeY9ylK4OXiK+PD0kfSBeJL51e+aRg6EcSUgHZAp5hpP4xhs0gqbT8k8pFoQubAWndmGKSiu77
dOOGDQOXQ//FH+H2nxzvc1Mhca89cUI5pazWPzt8V0/wvQvBAOfJWTkB57btx5/aek97MCsHtY2z
+5Uvpa9VWbkJm158pK9De/kU5WOI/OUlQ8slyONAlckUeZFOICeorhE7Qc2MHLik6NUDHZJP90xe
/oaBvPz8vIH1aNnuHnxSOaf8gWrIk0/wOTzlyUHpMk8M+v1BNKUfBoIQbYqy67XXOX/9NR7ggddf
e+11SIYeV1+ODCZ29Mj4EI2benRvhZ6VrMMJkjX0ur7lSujANXZFcpEmXcp5cRqods265Ek4D/zv
s+04EHxTuZ/3YAZ1EHcJVAlxreuh5nou/1UoWzdFuSX0jNjmXJRMoaLhz6Wq0HPQfgX2ZHRSIPKL
dv6q2WQSrKAdZ2knBybphfBJlV/kmXWjT7PUkwJlv65PPahSU01obuQ06+gROh745ivSil0rkS6H
vTOXJ0vjLoT+87zh7Dd05vEz+JneOJHyDzch9AqoBJko7lCzdHrlXx+zLOaLLft52uZFxZwXL1S+
/Oq9C+fOXbr41Wfvf/inC+9/QByOCg8QVCYhVkU8mzQXO7qpeNGi4k087dElFsvi/cqXn3/w/oU/
ffj+Z19dvHTu3IX3hIxFONbH8Ypac6nWULnBjyJ+Fw7VGGzK8O1VBpUy5T+VvyhlhrNXX9EX0Qcb
H9/VPcD4I7i9Fda+7kTrIzq0oI++RRnAtmuAYuMe5fEon2EQ1nBC/FHdDqUryjqiKSMoxDlOLvXL
lJjoTVPoLTp+SmBUiyi50hp6CwhpAa2lt4h53cL8vOWNOELgefOWN+Xm8wO3lJQ1/nS1x+N5urGs
5Ja3NmC7yqffUrjqgQePB1evadq3tG5enqtt65a9GzdubFozsHffoy8cObZpc2kZLyvdtPHE8ecv
/vLv1i9JTeFHjip/SJWmbSivqCxf319RXl6hLK9ITeMDG/7ptxs38Dlp5VtDSyY52w61NTUs7i8t
uUUubDtw8Pl9d29tb4UgmRlLD7fm5POSRRs3HD/y8vPHjw1QGcCxbKs/OKB8se8RRjYWH6/9hcFV
4+f/F/0S5sYXMp05GskJc9ExhF9YF9WlIAONwW7pWm70XkFJe0rfFfrTzCW9hv1kD4sx4tpwEZ89
7GNdDHtLusKGDM+yk7q32TTdl+ykYRNrNLzAVmJsUP8ya5RextgedtjQxRqNz2IuPXNhTh8bim5g
TxnOsyFjNovB+EnxfA/bSc+Mc1lq1FeYPwWfPViTxmYSLf0rbLXhFbaXeBpsgvYh/J6F5qzGZ5Oh
gE3B986odlaJ7wHcz9StZ6nGPZAZPKSXrw0ZQROn5OOkAHtFunJtl+4EO6WzMZ/xKBvC9f1Y16o/
wVZCvy5jriqzhK2vmHeCHY1+mxXpctlHQHgH8InHO421sYPsefYKewtRkMZr+Q7+Kv9GypEqpA3S
i9I7ulRdUHe/7qye62fqV+h79L/FiYVkMBlyDEsN3YaNhjeNstFm9BpPGj+JKoi6N+rpqF9FXYgu
jW6M3hD999F/uSn+ppU3/eGmP8fwmLiYpJhlMatjjsYMxZyO+WRM6pj8MY1j+sc8PubUzRZhvQrm
ooqDF3nFja8EPm5kvBAP1TmcTWKF4WsJZ6jW8LWOTR4Z14+6NiAT2MJzjOhtmsPXUeiqfx6+jmbj
orvD12PY5Jt2hK/H3jSJBSEh1yPvs+BNT4SvOZsdMyl8LbHomDvD1zqWNTKuH3VtYJNjSsNzjCw9
ZkX4Ooq1jOHh62g2feqm8PUYljX9p+HrsRNnx+wo9XX3+90dnUF5TluanJOVlSu39sv027+g3+no
Spct3rYMudjjkW00KyDbnAGnv9fZnjEyR25w+h1yncMbkEt8nnab0+N0BJxydkZ21sgcmkIzbqMZ
fxXPsTHfxXRszAhJla07IDvkoN/R7uxy+NfIPteNso+NGRtT6/R3uQMBt88rY36n0++Ejh1+hzfo
bE+XXX6nkxa2dTr8Hc50OeiTHd5+udvpD2CBrzXocHvd3g7waQNYNDPY6ZRdPi/QcLS1+bq6MZ0m
BDtB3eNuc3qh/pykcpqRlAZi7bIjEPC1uR3gJ7f72nq6nN6gI0jyuNweZ0CeQxTFArnO5wr2OfzO
pDQhid/Z7fe197Q5BZl2N8zibu0JOoUMxGFkQbrs9rZ5etpJkj53sNPXE4QwXe4wI+IgDB0gBXsC
UJTUSZe7nELr7p5WjzvQmS5HeKQTz0yfXw44YX/MdkPUsPo3sCYdQRaYgWEYOsGor9PX9W1ZyQyu
Hr8XDIEIFrb75IAvXQ70tK52tgVpRMXY4/H1kUJtPm+7mwALFJJB7VDG0errdQodVP8VIow4gtcX
hCFgIBKM7CJEU31AfSYHOh1Qq9UZxg2CuL0yDUU09XnhGX65y+cXHkIyXae4HOzvdrocYJShiXX9
8y5HP3Ho8rW7XW5yNocnCPfDBcg62tuF9gJnYt7t8EPqHo/DL9RvdwbcHYgqQI4/HOjuxJVfeKmj
DUQCtEKTKCDfwEn1unYVNIfnuwmE12hyRKhBPK+nX3Zf5+rAwO+kvzAQFqOLgAwoyTZaiDjhd05V
+D6fvz0gJ42EaxIJT+LSAzmJEkJSGDRYpyocNa1OxBPR7YEdyHa9PrdgRyuda4OIG9nR3Y0gc7R6
EAQ+YQ8BzPXABzsdQbnTEQD6Tu8I/oIk2EV8vF3u8baHRY4IK3JLkvhzih+wbAD5DNEtTEeGcsiw
XgcIBsJxjCdtaxwdThlRC7iEw9LEv961NNMKVkhcyM1Oj0vFrtIsl9dY7XJdTbl9WbHNLFvq5Fpb
TYOlzFwmJxXX4T4pXV5msVfW1NtlzLAVW+1Nck25XGxtkpdYrGXpsrmx1mauq5NrbLKlurbKYsaY
xVpaVV9msVbIJVhnrbHLVZZqix1E7TViaZiUxYx15XK12VZaCcrFJZYqi70pXS632K1EsxxEi+Xa
YpvdUlpfVWyTa+tttTV1ZtAoA1mrxVpuAxdztRlKgFBpTW2TzVJRaU/HIjsG02W7rbjMXF1sW5JO
EtbYK802WUzJgJSgIZsbaHFdZXFVlVxisdfZbebiapqLqXKFtaaaMKq3lhXbLTVWucQMVYpLqmgQ
sgGF0qpiS3W6XFZcXVxB6mhMaFpYnQgctKDCbDXbiqvS5bpac6mFLoCjxWYuhbSYCeyBBEZBqbTG
WmdeWo8BzNNYwCCVZqEHFCjGv1IhmVDfCnWJjr3GBkDCoiyz1JnT5WKbpY4sUm6rgbhkT6wgHeuB
J6ZarGF5yUY0Rs+u9w7MotVhFMvMxVUgCCexfnuu8C/z2jZnNyIuoAW5miRFQlWzKIoUIlNNBvDq
Ci/CVx0TlwhPxJcodWqWG8kHorFAxhdJmNII0iSqkpqE23udyIQByvzIGj5KKn1uFFUqMX5fly9c
/wIOD5hh1cgsud3p8GBZODki1K9PC1ph7Pa7QbjP7w4ipciOHpRLv3tduCSDg9DqRg2Iy43y+52B
blQsd6/T058BZn6qayQvsrPL5+8Kqy5yZFuwUGsbgnIHIYW6FwTVjozOYLC7MDOzr68vo1XrvTKQ
Clkp87Fu1s/8zI0/8+pE0yizOWi10/Cdg0YzC7/ikVkrZsisBHOCLICPH5tGB+ti6Ri1MC/mZ+Cq
mHnwltG0arToT7xsmBvAx8968bMdM79NR2YNYoYD8+tA2YsVxM8Heu2CggfPHYKOzLJBIxuSfZuO
RkWjcdsIjf93eo7FcdJfqynN/baUo7V1C01Jb0LVAW2dwNWB6zUY82Gb8UO4Ew/61AoEu4B9AG83
1nqxVqXfKZ45w3bsEJy84Ej2IBu6MOLEW+PYBk8gGTowRs+DoCZjxCv8oBujfvBQOfhANYhnbjyl
T4eYKcMnVM/SaAZBkzi4xDryI6LYJuZ1wQdV6hoFmq3K7sF3G1aST9D6OfjFVfkIjSThqbS2XdAj
3X2Y7wY9VT8ZT2ikB7gSFZI1iOeq9C5ckW+RNHMwrsoY4UD+SFYIsj6sI5SIYwQTGunGuA9ceoSc
Kk4kTTtoq9HiBkY9oEHyazw0Hb7NgagTDm2QrEdQUVHtwyit9glaMp66oRONjdZIox+JaNJNtWCP
wJDoa9aha8IlYutuUG8VtAPgRc+/Sw8aV1HPhDx+3JF11PhXabtxT5xVH9ak+n6tNTuq0qp+pmoo
A+WI10U06hN4dIHPD3PQosEFDf3Al6xD9iZbqRzJU0gTn9A7IJBYjRlteK7N0fiQH5O+PniG5rWk
OXki2UT1sAC29lqE2gU3wq0V8ygbRuwQsZaGK/H7dkbwYiXRpoggFCKIafESQW10Hhi9jjSk+Fat
1SrkGO1vKiI0QvT/Z5uSrqSDav8u8a3eU9bScPqfLU5z+oVdXeCjapTxLbS+bz1lSqpMqg4kAWFP
Ma1lNpKf4o7iVM11qrSUaSnXaraP+LMae+RvFO8q1j2gQncRrWgtZdkOYBDx8g7MI406w2O0Qsul
pKEqCc1X0b0RI3ry/TpFLK5qEPE00lSGPH+tBNfzuRGPiKYa/gERE2Rz4kAajLYyRQPlVtUnCW1Z
YO4FbpRfNJxlzFJHaKbqlWoUqJmZcKEPVREnrlSERiPfJ/ysXXBK+o7qmoSVqo01dLUVMnK31iEk
oYcYHZdqrakCx9G1hvyKYpo0UOUlTyCctbjrxVP3KO00nk62VlibtKLZ3XirlYyinyoOIUzZJoKv
Jrc28u3KoFqFsr0sIphkIhmprpHnXO//ESlV7b4rj5NderCa/Hk0yt+FbKRvIYwjdrweSdLs+zS4
3u8o11KPR7KSNlrUaXWDOiM19qgXIQlpxeh6rK5pQ7/kgNcQd7XWqt4VybAaxf8fWevGqI1opXbO
5MdqfXRd53eVzAx5y1kNDoPtuKrDVTmulqHDtIlnFozJ6O1seNKAXrsMo2UYScIMekLPk0RkLsO1
HX+4UcPqBS2Vhg3ziHYT5hJt6tKt4m4J5ltBizKfmTUKHmZQI6o14Ee0qzFahW/iSfNoRSlG6nFP
1xUYKwnzs2IV6UDzq/GxhyW1YzzC9XqpiLLKjySrxp0N9CvDMheDtkXQI/mJf7mgaxWraB0hR5IW
41OLnzZwtYBCPVbRHY3W47sW8+qwSpWD8CNprZhrBQ2b+K7Ac5JAtYSKVSlm1YI3zaiAXHYhBXEi
7WgmSWXH82IgQuuJ6xIxqkpGmJCVSZYIFdotEW9VDsK/IUyPfID0r8KbsCUc6wQHM0arMabSVanK
kIo0IblVNOpxX4aZhANpSDToGVmF8KwamanipvoC2bQYM6qF5LSeNCFEIt4wWhON2vXW+S7v0LyN
aJHdCKkqwaUOyJphK5JLHaH15Ffk+aXQIOJxqt8T3tpcFQWyj1VYdinsrFpEpScLFCJaEK1lwhIR
e6gWIAnJL4ijhlnE+sSTZNbkIW8mL9PsEEGF4o98jDiRF9AdcaAYIR8jK9EzLT5VHpod68VajSqt
u977ycsojrR52rrvyx0qRhpvoh3RnbyVsFQlJCuraPww3Ui2N6PGUbXsDte4AKioHbC2H1TrfqTX
UevQ6F6UENFqZqSiaLm6AlVGrb6j50VGCVnaDVH9iuyBaK5Wn79r923BfDqxoHmjO2GtG1G7SXWv
RJVJlZ86JOrZ1Z6Qej+1S1F7DerK1V027QbUnaq2i6HdIdXm6/d/AchIfQBJofLS6n+EFu296NyD
OgfiRgir0hA3Fc3vq7U37hhpp0r7Ej/o9InroJDKi3sHpCCq9NTN1uFe28Oo5wOkQ8RWP2QDTZcf
wp86xQA8SN1juQXC1F9mgBdpRpKq+zUNXxUBl3hGvYQmJeEY8T7qtQvF2tF9KfVN1LGrPqWeDNAY
8ekATzr/CkKaQvw3kUwgRO8M9BNq/Y6ce2UITl3s/wKt8h6nCmVuZHN0cmVhbQplbmRvYmoKMjYx
IDAgb2JqCjg2NzAKZW5kb2JqCjExIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UeXBl
MCAvRW5jb2RpbmcgL0lkZW50aXR5LUggL0Rlc2NlbmRhbnRGb250cyBbMjYyIDAgUl0KL0Jhc2VG
b250IC9PVUhPTE4rTmltYnVzU2FuTC1Cb2xkIC9Ub1VuaWNvZGUgMjYzIDAgUiA+PgplbmRvYmoK
MjYzIDAgb2JqCjw8IC9MZW5ndGggMjY0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl
YW0KeAFdkM1qxDAMhO9+Ch23h8W7PYdA2VLIoT807QN47UkwNLJRnEPevrJbtlCBDx75G41sL8Pj
wLGQfZPkRxSaIgfBmjbxoCvmyOZ8TyH68ntrml9cNlbhcV8LloGnRF1niOy7ImuRnQ4PIV1xV7VX
CZDIMx0+L2NTxi3nLyzgQifT9xQwqd2zyy9uAdmGHoeg/Vj2o1J/Lz72DNJESpx/IvkUsGbnIY5n
mO6k1XdPWr0Bh3/tqtT0t2l+E9FBbcWWoXpHxu0XcsrVp51vZopkswplbmRzdHJlYW0KZW5kb2Jq
CjI2NCAwIG9iagoyMDgKZW5kb2JqCjI2MiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAv
Q0lERm9udFR5cGUyIC9CYXNlRm9udCAvT1VIT0xOK05pbWJ1c1NhbkwtQm9sZCAvQ0lEU3lzdGVt
SW5mbwo8PCAvUmVnaXN0cnkgKEFkb2JlKSAvT3JkZXJpbmcgKElkZW50aXR5KSAvU3VwcGxlbWVu
dCAwID4+IC9XIDI2NSAwIFIgL0RXCjEwMDAgL0ZvbnREZXNjcmlwdG9yIDI2NiAwIFIgPj4KZW5k
b2JqCjI2NSAwIG9iagpbIDEgWyA3MjIgMjc4IDMzMyA1NTYgMzg5IDYxMSA1NTYgMjc4IDY2NyA1
NTYgNjExIDYxMSAyNzggNjExIDMzMyA3NzggNjExCjYxMSA1NTYgNjExIDU1NiA3MjIgNTU2IDYx
MSAzMzMgNTU2IDg4OSA1NTYgNTU2IDYxMSA2MTEgNjExIDY2NyA4MzMgNzIyIDU1Ngo3MjIgMjc4
IDI3OCA2MTEgNjY3IDcyMiA1NTYgNjY3IDU1NiA1NTYgNTU2IDU1NiA3NzggNTU2IDU1NiA3Nzgg
Mjc4IDcyMiAyMzgKXSBdCmVuZG9iagoyNjYgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9y
IC9Gb250TmFtZSAvT1VIT0xOK05pbWJ1c1NhbkwtQm9sZCAvRmxhZ3MgMzIgL0ZvbnRCQm94Clsw
IC0yMjAgODI0IDc0MV0gL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA0NzggL0Rlc2NlbnQgLTE1MCAv
Q2FwSGVpZ2h0IDQyNSAvU3RlbVYKMCAvWEhlaWdodCAzMTggL01heFdpZHRoIDExOTIgL0ZvbnRG
aWxlMiAyNjcgMCBSID4+CmVuZG9iagoyNjcgMCBvYmoKPDwgL0xlbmd0aCAyNjggMCBSIC9MZW5n
dGgxIDYzNjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBfVgJWFNXvj//m5sEcAWy
iIAhBhIRA4SQhBB2AQFZw77KJptsEhGR3aVKqVbrgh21UkctUp+1jra12qrtzPO1aqtjGaafM23t
e7bT75v62vf1zQLk8v7nBqoz33svN+fec8/6X37/5VwChBAxiSEMCa5t7Kz5bcMnp7ClmxDJ7+rW
V1Svfz1ZQ4g0B9uMddjg0uwUi+8v4LtvXdOmLXZ3t4P4fgHfv2psqap4aWTPcUJk+/C9raliSyuJ
IDhezuK7T3NF0/rlN0LV+O5LCFzCPQ2ECEeE40iBC7a4KwEvd/yzTCVE2Ke5c/bvIbwaHnJdH4KW
eyAcnwwALRAmiQAZxBmjOFeAT6WrEka5R6CgI7DPe+YeUyesJnLsU7kqXVVSvSvjJzOaDCKRRqRW
m1z1TN0J7tGePQx4arM00mULvf2WMSdYC/hzE+/bC7gpgHnzP2IFAC6aZKYIadXO3Gf1bDVRkVW4
qtFoCFVr1Gq1RoQ/qUQmk+lDjEajSSkSqZbTHo3JqJfJ5PhndQBL3MOvHrR2vrczIX77tY7SU8+V
e3CPvTamR5Uvk7ox7NLrxmKlu1QIn7pK51kPW4Z7AwCyj33x/HOfHUjXle3IXp2kC/IqyHh/GnQr
FSkm5HGAEOYvSM8iQtyRxVB9iEzuqlaJRGLDACimpSu8PVzWjwSy1qnzTOq0kAUVA1tbP3fMZMtw
pptjJhItk+IKSPJyx2To2vAOKODmhdaRCH7+kcp2hvmNPY95/PYtKCgawa1JGMpDh6usIGGE+FGZ
4gI+AiUKwagPkSIdVDJivMslKAV9iEkkkyuBF49BbTSZ6EATq1N7ATz+kovxAAnrEZRsPANLZYvk
Pha97fRJSNc9t/bKMCyQgok7A+1Na7MgtbDSy1cuWajyiQhgas6OATewMlzl2uKtne/k4uQilnif
O7AvJ8T4SkCgDK71PpcYHZ3o7sY6iZ3FyPtJQlgOUTPPgRpkm79gnLltNwjYqY/YkukJZjsQsAJB
tOEwkoCcannNE0CN8yoXiJ7VOFV3qBE5MhlR3Vrn5K6ztT0ffAyQsPNmd/VrvWnzuCde5VktW8Hb
c0lxdF6ZB3OpeqTVApD5Dfd48PcH0iwtI9UbSgEun8oY0muDAcoaUcZJuPMe3NmdoBWi6P4BaZQU
MVIhk9MOBJ1abQhFmTJ1/R/tTU7ee7u/999eTANI2XOnL7w8wQ9AnVButpQn+PomlLPVkHXk97uG
Ph/OyBj+bNfQH36R+Q2Elm7PyhgoDQkp256ZPlAWihRYZu6xJSgvGVlJiJLKSk0xxhOCWpXpZUaT
gBKBCn+WCEEkKLhHxkM11WO9CVHm8MGq0JpDxh+N+TG+4BtTEGoqilEqY4qE4/Yn1gwoOvFZj208
M2vNEkjPFrCgLxtIT+0uDtYV96Wl9pXqKd6e2rv4qe4cVk8tn+JUOD5DRyZysWwOj8wIHCl9SjBP
LippjlaNUkINlCLR5CqkXDwVpUmNrYL42MOl1a91r47ueK02KDMlyR/8YopCs+sWcxOGsNhr/ZN3
1oB9MrQ4Xo3SjS8xheZGKgGUUXmsdayiGIpOft6/7cFwFizyiwo6HJoVqYiNialaZTQAHD9SxXb8
EYzrBlJTewqCgwt6UlHk6BDReyETAyhz3nsZ1CYky4DKReuUSqknU6L3GhiDDLcA6cqEFQv2DR09
Coox1tKUCyBgJhgGYHDoufentwt6UBpZM58KfxA+IZ4kiGKI5c1STuErl/mxlHejQc0ggnk1PhUA
jyWB4pUZUqZPM3kCeJrS9NchGiJvBqcZl0FTVRV3vGy40QxgaRouLhtuCg9vGhY+gboa0/aDI9bc
Vw8OhN5nmPv6/oPHs94AbXN9Dfd3SB76oHPTtd1JSYM3Otpv7E5BfjsQYzmsFVFOKMAojkQmrEh4
dEnZHO4RU5qrvwLco+u/ahmJZK321Or8ZXCLuTXNvXML8kq34yqIDzYHpbZ01h9SpVLt8r4tlFoo
ejfXQVAoLFkhZTrneQtAsVHXn9hwwkKjBnMkMNOMulu9yDMg1F7CPL5btiIACgsZFa4diWsrhLeJ
P0Ueldis2KhWkFyxSK5EcVFFSfhXelOyHvaX5/tG1WWV9qYoYc22t9psF66ghsBtQ/W6JvBKf6mj
tDtNIxD8AYhniCXDEt/evHVt/dnOWIC4q39yUwZt3QnQ1WRZV9aRE72l/2iVAxvsR8jlMzYgkMDl
qRz4NejZcSAzZIpGwE6kuBLHUT+HolS6mjC24v8ItZU2cIJMrgk6uXeZUwIdurmGHs6DuQAnES8Y
/4UNONOXhFBuQ2RSiVgkkfKAUSIOTcg0/jRG6u/VKrq2K46SU9tBbGlgAsorSxGErLNkEST7LgOG
naeOCls+DeHG6mvTX4IebDGJXkYAbw+P5BgmM69EskIR4mpICQtaanIL01l799cEeLmuA7eCY+aa
yQBBJux0lQXXmrIxwvEe2YJ+0R8tHB0D75Gf9UgyOVoyWrhKhOSpNUoZi6EHNRaqoUEKtRQiZ12Y
+J43Wjac3RypUCxYpjH7Q54hADZWheV7ypc4cd+KwMn+uCsyAT7nDlkCmMK0OwLmSf5ghQH0Fbty
zCU+i+RS2bwGV3+fUDNI3RcFrnr73cqQF3PGY+tdVcu1YXCI+qEOLo49glR6EC2VJAoKfQ2fJIRS
AfJSRExSjP6z+4TDVE/64fqq0e414KYI8PROK67U1Q/rfzQWRvuCX2x+qNHhQlnr339gYksLIP/4
RJ/Z1lCuUUcHLoXiYrPDjfYW63TF/Rmp/SV6xIUBRplK5tpc1sRU2h8wWuYa92fsUyJmktAOKWZA
KRBQwLi7K5kJqONGL17iRvG5DwquXYUCnOPHXYR0+0P7AyjgRnF2FyEiyq1qzv6oOSDPDrvACrKM
3PJ3TDO6QFFTlpQNPz+YK2fqjkWvPFYbnNUQ78g61tsA0uLsCubIXE2w8NVfMRk56TngZrIOoozD
0Xeo0DKlPFopAhn5YpQojUuIUOrXMEY6RDxrmyoqet67ISyYoM0346IjoTbmzsDm6/FdoNfH3ekz
5Xq5uM4XiV0WiJcWRtoMcpnQeaHzkiLhbSgvyuG+vs/1n65vhtKyU3D4X0GSW9f8LUSYPLKadiRH
b65Nl8athpag8YPRWxsyl8QlojjJECECkfAcb7coCxUjlMK3oHg/gdst+G5aLjzH2eE68tOJ/PwC
rU9O4y3mdYY5yDwDGFd3ihiHp0YQ8ax0giLkMKKlJwkg2uSdXlylqzus/zG0INYXwDe2ILSlwhFv
JwM2ZqdDwSvjfa3j1hWxiJQMK+NmHwF9aV9qWm+JDoYGstZ2F/MxNwwRXIQ65aM/RlINOjYRdQW8
QPUy6qX5uDkXUWepEVhq7q4/2xMProFmz7SiCv299aCw//DP0Z+1nroMUHj8d72WTa+m+sdol8Bl
+3XR4j9CSOmODEwAnkUu+iX2JEpGiOKktqSECe6ugLMb+FMBlXHczH3hYox01CvwyTlPriPUIcFi
Pj+hDkE5Z4QaRAI6BRopMG97qDek/zSy68H+tQCB1a+23R/eBsyJF46/LubGF0IE+Ox7dCIbgvZ+
8l12SzQGxN2dL73izC6sORBpzQeI2jzWmL+jPE7q71VdWF7X2/njdGzXJVv+7kMrtAtVWot/bhVA
RxvSuQstBakm85FOdMk8L5QleBcWoHN0Aj2n4ya5/+LQ3bBDU+20CMenSthTeLjB+UXIZxfyiQhB
76dR+1I+GanEjWbZNDjhGURM00H0dvhGfTOyJ2x3CgzK5356bcR+sbTkzcnjz//H6Qpnbnzx6y8W
vVChB331vpLM/lVy2SInwcOyoai2ToCmu9yXly9zX97ekLr/k237X6b5bFfXB7uT8PyjMGkxUQHi
xkWx6eg1PPGF+gwpxYJYpNZIEboy3B9pMJpAoHn8E/drOAaeKamuyqXLgpZ6mHNWeGtVKje4xVqn
Hwr8pgYYkf/qVACh84RQiI9Fi+cpgxJDhPw+aEHCFJSaMyFKqn8eBKwchXXXfgFX1gvHp50Ef5sM
YJ2Qqu1IzVsQMOfn4C3uLoo2gBvHPjw5wSVcae7keIn2zZ4cjyDKLjh2caCM185tZo/dxjye+hPo
n54N0FqPIU2LeU1KcU0HrFAjlDwaE6USDIefQl/N6c0xAH/9zt6ENCg6N2/uZCTx267YvnoCGN0k
cLN1Y1sLIGWUxzhcbx6uRjeevdiFEMp9bL9I6WTO2GnWfJ8JwpzlDM6hsVCJHhBPYcD7hZ9dA01v
5yCB9kDzPPwhWDBfkWIaM4t7iUoF1/yCl3tLkjCB9DFnBN5ZwH2X0H9po+3qziTYtLWqBGI7z9b3
3orKY8AFXOZLSmLySgEzhkFMZ4SszJapywpXwNfNb3TFRne93th7PiLqQHXRS7VhADkZG254mBO8
Ak0AVUUPkUgaDYXmWS4R/3N/QRHc5Y5x3yP0D8Atzh+qwRtPoY3MJPOQk8Cf7Z72xYzIPoly16GW
tOhNXcgCXBBP+CClstL7KYHVDnPn7d8ziaAY5lK4ndDFBAl6pnf9yL0Pcd8zTbi/CSWmwtn0K4SS
Hlip9fMmg87hZ4nxssKA5a5EB/23AWBk5aubuoDp3rCuhuUeQ2Lf+UbbzSGEa1zn6eo1HVFBTIHw
3PSEwQzMSzu3vQjFhRXHWyPWDt3saHl7ZwqsDARMwBkSi7trUF9aEoX7U4XM6sThWtFW5bwRz+3P
mw/SiGaMGfoz+Tl2sAvnLZEusLzXsXt8tTLQez7owmLGtzdeGFiD/qjlaGnhrli0SZFIYiuIt3p9
tL6dAWVkVqCeaqvAylbGx62QpqPv2tRkbN99svLqZG5tC6zd++GW2vPovCMSwuLUiiVVTRAZz3Uy
ezojKpLVfonlls4mehwlFtSCGeWIeTu1FaQfkUVvSqObm5uJNU8zzIPlxevSpRqLVrUAlE4JPe8N
CM/NEL+uF3cFZR5/7WbbGJhAAxo0JKDfgERK9CToF5V8/kHdCWYg7LcQzk2MnuEejV7gJiAM1G+e
Ro8xKRDRMnVeMH/6JwyvJBAla0DJLscIEI0LOhDOy5GShXELpSd/1iYgZE6iqAOUp94hYTGGMTz8
JapWugaEAKzpPltdO9YbD8VVPa2QPPiere3a82uhjWsNzMxneIup3AyQnxHCNGxlmO6Ghg7oFMjd
lrr6dyfn7KvHY76lYX9u3d6Q+It99WPdcXHdY/V9F5nF3qm5K9foPaE+PzvV236TGbBt6ALobm7t
R2mg02NTUBqiOWkAcxd6uPtf/Sd3H7Yj/xMC/6nzVG55M/eEFzAezGaZvBYcnwPoGRbzXWRS6RAD
OxcnZEaTXC+8YB+DHJGvj/lEYdkxWySYm45Wvlq7bKUElItrz36165fcX2/U1l6defng53l+7whU
MySqQJOQkjp0o33L9Z1roMgrxtx2ZUciQNs97uvzr3Nf/9YGtt7fUJw7cbGAJ3L8PuXAB/pCER8U
MDUzUMcG57lHGu1C+cJVpcodW2i+i1mfNlgDwAofo//v2CU6jOd5ARmdmRHSk52M+NATmF6JxPNW
MefU0IJUiBRel3ggcZ2rjTIjfW/FKw0aKXT1NK+DNdFxZ9vtNeiE0+tbAFrqMYVtacEk09bC7QeD
2TM5tyiw+eLa+H3r0g6FhxlmCORbs3PBaj8PVWXrKlHWNYIPgZ7NHVmIu94dBrjHVluecJz7C/c3
cMIPnTiKL19Ur1y0blHEfxPCt9KeZ35clOgI6gyofmd/OE/wgLtLiPPzhMy8KTrCrzTXS59hLN6E
t4iBMZNBZox4szaiFXiTAfbfsdiIGduJMI+cxHoitiVhsdCx+Eyk40VmYsV6B5ZBHBOJT7pGJ655
Cp8W2ofjDFhXir1JF99mI0PY3onFjOUUrh8nGiO7cE4R9rvhcwj32I6F0nEE+4/RNjoX61p86rCY
sMTRNqTBBZ9BWCg9eTjPCcePwrekhmd2GX5hzSOvkKvkCzDjlQ374D4jYwKYIeaiQCBQC3IELwv+
RfAx68W2sFfYW+w3QqWwXTgovCeSIcq6REdFX4tlYq3YIk4Wl4t3i0+Kp5y8nCxOW52+dBY7a5z3
Ov/S+YmLu0uhywbckeorDL+BYz4w+8ZXnrkJSRz24okWB+NX09k6kKX45mhnyEJYNVtnsT18ti4i
yyCHrCYtpJV0kjZST2pJHdmESC4hwfj9O5jkEivJn33TkQC8Vv2v43XEzF8+pBJX+v/m+5B4sp7Y
+L2acaQaC23ZjKWRp6QJa81IhQV7Vs/S1Yh99aQKW2qx1on01uEaPqSCVOO1HsvcznnY1ogtG7Al
EefQea14teAOT+la/TNPPng2C8ZLhx7KUTOQdJzThJy083tk44rNfC0VpbEeKWjHVStQXv/3uGd7
HPNTcf04pKKRVP8Pq08AbgplbmRzdHJlYW0KZW5kb2JqCjI2OCAwIG9iago0ODIxCmVuZG9iagoz
NSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHlwZTAgL0VuY29kaW5nIC9JZGVudGl0
eS1IIC9EZXNjZW5kYW50Rm9udHMgWzI2OSAwIFJdCi9CYXNlRm9udCAvRU1ZWFFNK0RlamFWdVNh
bnMgL1RvVW5pY29kZSAyNzAgMCBSID4+CmVuZG9iagoyNzAgMCBvYmoKPDwgL0xlbmd0aCAyNzEg
MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2QzWrEMAyE734KHbeHxbs9h0DZ
UsihPzTtA3jtSTA0slGcQ96+slu2UIEPHvkbjWwvw+PAsZB9k+RHFJoiB8GaNvGgK+bI5nxPIfry
e2uaX1w2VuFxXwuWgadEXWeI7Lsia5GdDg8hXXFXtVcJkMgzHT4vY1PGLecvLOBCJ9P3FDCp3bPL
L24B2YYeh6D9WPajUn8vPvYM0kRKnH8i+RSwZuchjmeY7qTVd09avQGHf+2q1PS3aX4T0UFtxZah
ekfG7RdyytWnnW9mimSzCmVuZHN0cmVhbQplbmRvYmoKMjcxIDAgb2JqCjIwOAplbmRvYmoKMjY5
IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9DSURGb250VHlwZTIgL0Jhc2VGb250IC9F
TVlYUU0rRGVqYVZ1U2FucyAvQ0lEU3lzdGVtSW5mbwo8PCAvUmVnaXN0cnkgKEFkb2JlKSAvT3Jk
ZXJpbmcgKElkZW50aXR5KSAvU3VwcGxlbWVudCAwID4+IC9XIDI3MiAwIFIgL0RXCjEwMDAgL0Zv
bnREZXNjcmlwdG9yIDI3MyAwIFIgPj4KZW5kb2JqCjI3MiAwIG9iagpbIDEgMSAzNjEgXQplbmRv
YmoKMjczIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0VNWVhRTStE
ZWphVnVTYW5zIC9GbGFncyAzMiAvRm9udEJCb3gKWzQ5IC0xNzcgNTUwIDcwNV0gL0l0YWxpY0Fu
Z2xlIDAgL0FzY2VudCA5MjggL0Rlc2NlbnQgLTIzNiAvQ2FwSGVpZ2h0IDgyNQovU3RlbVYgMCAv
WEhlaWdodCA2MTkgL0F2Z1dpZHRoIDUwNyAvTWF4V2lkdGggMTc2OSAvRm9udEZpbGUyIDI3NCAw
IFIgPj4KZW5kb2JqCjI3NCAwIG9iago8PCAvTGVuZ3RoIDI3NSAwIFIgL0xlbmd0aDEgMTYwNjAg
L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB5VtNbBvLfR/S8kfHjRsn7z0UDZKOiQSx
AT7qwW4fCrktHiVREvMkUiEpOe6lb0UuxbVJLrG7lKz00ALpsSh6aJO2QNFLDu2pRdFbr80lRS+9
9FTk8BLkGKBAgQRI7P5+89/hkqIsyLL8UdSypNnZmf/31/w1VDml1DX1R+qSUvXm4t2f3Yrex8yf
4Ht3v3/UDf/uL76D8Q/xvdrzvU77v6q/qVTuNp4/7GHi+m9d/3s8f4LnL/cGyZOr/6i+j+c/xvO1
ftj2VEG9i2fCuzLwnozUZfVLeP5zPJuhN/B//fHW3+L5n5X6nWsqt3Aj92dYoS7fu/xXmP2S/L70
n6qb/5xS+etXLl26tpDPL/xYlZ79h/rFM/3lT+4AktruVjrqI2WePbvyztN3cn99dZD79BOVe/aD
Z3yr8qr79NsL3cvfBZdXlfr8zVs3v3Lr5q3ugvp5fOkLP//R029fvfHT/46u3FE51cn9IP+H+W9R
Hp+/9e6tTv4Lv/hR/lvfxRsQpNQf3Pu0/fu/8tv/Q6HN/eukWHLqyuQd9lwdPP2iUje++mzv2d5C
10KavMYgv/Dv4O9T1cH4XcjL4gHN1/DNf8R8/N+v5X53Mv+XubvpOKeu5z5Nx3m1kPtZOr6kruff
S8cLGC+l48vql/MQkwV+RWlwLeNr6mb+n9LxdfVFiELmP/O5v7n9e+n4hvqN+3vp+LPq+v1/SMc3
1cL970F6uQXq+QPAlnFOvZf7t3QM3nI/SceXMP80HS+o9/KFdHxZ/Wp+LR1fUe/kB+n4mirk/zQd
X1dL+X9Nx5/5ytKlL6XjG6q39NN0/Fn13v3vpOOb6tr9f1ErKlQjdaQiFah91VOJMuq2aqs7+H1X
fYCvexjtYYVRy1iTqBjfkfKVpwaqiNmqGmJ9CaOy6uPLqMYEVmyffOzxsecAPztYqc+A9UPsFKwt
YDoArkegdAgaSYcHSl8M4ypwP8K+XTUGhDb2exYaaTMYkyMDuof4OcKaPXASYJ0BxSGwe/adVmol
HB1FwX4vMbfbd8zdDz64Z/aOzHKQxEnke4OiqQ7bJVPu902Dq2LT8GM/OvA7JT239UNubXkHg0fh
cN8se73nbFz1H3m7Y9PuecN9PzZe5JtgaEbjvX7QNp1w4AVDUDbLYtMyGGNaNje9IR6WwUyoHmMQ
hvh5li1nWbNr9RtDRtQRLacEu7mHsOlHcRAOzd3SPTxNgzpGn5A3vcCoroVGizOwObE4x043HEK2
CSSurNUm0NqSWsRXJ9X0AbRYwt4QvyNo0rfwIliQj/khfibYmiSjpcXFDmR0MC7F4Thq+90w2vdL
Qx+v16YocDbivGPeG+g5tHRa0h5+9rH7EJ5ES53l7Lz2R0jrgHsEbntWLgFscwQ8kZVQB++7GNNi
6Y+06gM7R72IJI/zkfnXGGsy/3oeNxr+exLvYgMesE1LbT6+aPX+S3wR+zzMVx+zTop+BtGEcY08
B9CGtiNGR89aIaNGBGcz0EcXP+elNh0/ydm2hTew0DJvImwDfROXn0bFfYuFOmVMJRzqXWxPsImN
ib3zfQIqGOmGNpaPLDR6B/01BNQE7xj/+E0rIFdtvGF20PhNDhJLxaxneljFdbRDge4gcLXQLrHU
B2T6B7VVmLKSgs023Ev79bCGdLWx10v503jDmTGwEAppTfBeqO9i1Mc8pXR7QmOGwagmVnbx5hD7
KCVizGTCmRHmQ2AZAwspdNR0LAfUaQAZjQGDb0UOesLDPAZCpxzaoGwMuE4mhxhxN6MScy0lQ33P
cuTknGVliYHU4NjKkPCddjimXJyuNbhxGSwGLr4/iQ/OC5+LoCfCE7UjOVxgB3gm5lntO/8+mWsn
ObE3sTPhkHSRSrG6jKNDKw9GLMf38zGIp9ECGdVpreSQPuAsnJZCTkLLd2wl8Qgr2lbeQpXTXxer
yC/jtNMQOaclUidiYTEyC72zZTFRZntYw2om00GmKSdT0jMfCYbYSbi0Mkogk5bzlUxi9ANn49P7
yB3rF1KuQQvpmLY1kQZnCP/5+iSf3Cu6H9jf8jzt66fpIrGZiJmVUYAcsbrLJHXaXkZHVpVCP7FT
5vRlF9FIO/2N/ikxTihldGWWdzrP7FjkwAqOfi5yHgMKnzSeaSn0BVLKepfxyFn3PtZleVUwuRhK
7oQSrhfJOmiOR745nSenbeYJcpBZGDk1oOesFMziOS6PeT+KrS9Q38RADqY1TC+Q6oCUUdrG/hzi
iXHFydlglcyQV7FI8QCJyJQLv5k9fMud5KyMnkNrYx0r9cIJ+bCAnSJ5J123QyNmu2xbmLIyyS+b
wEb7c/mFNiU5SbxsiCggfuD87QB4ginOHD5fPbGaJkfU1whfkr3o9cwyLs5M611odjN6Lt+IBJiz
mMeZ4cTuSTGtZtb2nZ1QT1x5UuymTliv0ZYZuR39J0lVT0luWofn9VXG1r6VnXDivM15EisH8TnW
2pJXZvOveGgbtZEHa6FMJbeKVWmrO9YdDuKriFTHvTXjSs6d9E7Jh92JvW2oCmhaU3VVQzZg/qvj
qaUeoNZu2HdVzBnUcQ282cXZeBWzq5gpYAXf8H3BeuMDjFtqA+t2LCyB0cA6wn6ItYTNKr5mnz7G
+hpgMdpV1DcsjgqgNRHZ6sBH2FuY3cRv4uQ67ljBzA6eOV7H3HKKr4Zd5IHrt/DdSiltYT7DOksV
IZMLoWwLTw3A30hpLgN21cIj/UXQtWbh1uwu7qPkSGkZ39v42QDWKiDsYBefOLuD39tY18QuoYPy
I7U1rK0BRsP+Xsd7UiCaEIpWsGobuLliHXS1rBSIidxxJalq4X0ZEuF+Yv3YrhLKKBNqmbRkUHju
Im6hg/LfTeHRBsj/Jr4oW8qxaTFUMLuFOYErUHl6Iyekm9Kh7qlT0lfFEzEs451ohfLctE+Z3MQW
qNMydmxZyrmfnFAioh1SP80JdXxcOydZh8YqwUBY1BsltWmxNCHZCnRFSDJDidCuaPkr4CCzOLF7
ytutFSlQPzWr2a+Dc9GIwOMJeZoL6umB1USmD9EAKaRdEKOTWaZ94iTNjh5aM63M6SGTCv2PNkaq
aQV8Igb6CG2MWuI755/EQduRGLBj9zqo3DcrX4OV9CO3zu07LXaIjBzuWQ3SWilLoVAiCeUgcMWW
xBOOxySJ8hXkNWbIUZrXYuyVSted+yTPZ7WN5J7pupPScHlmuhKQ08E6shFPgb6VmluXzcppSXJW
dnojTJeT58/HtFHpLnJdVvVm1YdUj3ImYk4U+lkRsT6XGpC1nlQlzNM8ywp1ka365UTqTivSO+EK
ZiXHRQwamftJheBydUoGS+pKrhNslLBQQygiTVchzJ+ctKWFK93JkCdSVv8R4BzacWKpGuLZAxWy
lmu+iWd3Vpnu/zjqMx1Ib+a4Dhwv8/LXM/JnZRjDguQsFVgJs54sgSJyRkrlXCaY+UwJdO071qyO
Ssoxsz7W1kt2r6tDySFrJVboYlOULmVN7fGcS5w8aZTxJD0uJ1vKfQWrZrvar6PrdNE967epHyS9
Lepsui5zFkYNywmCmrvIfhDxzveDxBpeXz+IVEh36qRaPIsT05V829qw6yBwDfsSTmLzvjbdTXS2
PB8nmBfpU2+irzT9lxHpK7Evx8g22x/LYvr/r75S1mGgP/zf6yvpmQz75vpKlCM7MW9bX4n9y/m+
UubTr6evpE/pF7yevpJUchLv6euM/af3lZgVLr6vlPmb6xIx9xdQE5/8F+OCpZVViYvCbp+cz6WS
eNu6S1LxSIUlXakmJD791wzhRyqmV9tdYhfuedLlKcpJ8O3uMmnYK3Px8Wrm9XeZmMvf1i6Txolz
usuUnXVfZ5dJ217JaV0mega7Lq++y8Q+GztyZ+ky8WT+arpM7EGU0X/aUl8DPa6nV0Zf4vX1jngu
nO8svqnekZ7rHZk31jtibjy5d+R6NVlPSPo9r6J3REvN+man947oP7Sjk/rZr7Z35Lr7z88o8x0f
9/fOF+n4EI/rSPDvvBfV8eHph7eSztfxYVeH0f9lOz4atYC78fM8SV5UhyaZq6w+QtRxN0+07crw
qaTUmr2gxatqvCc3uR9nbse+b/b8fnh4p2TOcLGtZNb7R6NebILBKIwSv2O6UTgw5cg/MHIJzOGw
F+nGcpFuGo3WGXbcR/OMkDa5jaffP/Wfnr+3d+Yrf1N8W8xBrD2TRF7HH3jRYxN2swVycVDrbT8a
BLG9NBfEpudHPu4I7kfeEKwXwTukh224CohLakWThMYbHpkRrtnhll24l+AqYAAReKaNe4oaK5Oe
7+TUboeDEZZzQdIDdFwf9IcxNFSwIincAbCO8eI4bAce8OlO2B4P/GHiJbzE1w36uH14mxDtBtMM
u8khxF+4YymJ/FEUdsZt34LpBLgRGeyNE580aGKYbCji/mK7P+6QksMg6YXjBMQMghQRMdg7lrjh
F5pxDEbJTtEMfHKt7c3HuFc0GY4icS6GkYl9XL3E6gCkpuwfQ00eARYyA0ItorOIDnswLOKe2WAg
qO44GgZxD8aHjZ3QxGHRxOO9R3474Qz564Z92DQZaofDTkCBxUtatwDO2wsPfMuBXBy1BEyMYBgm
UANudZIsasUSJhYg70zc8/p9veenUgMZuP6JqSk+wyHsIjKDEA53EtsmORr5XQ+ISkLULI8D7whO
ie2doBvQ0Lx+AtPDAEC9TsdybmVsb556EWge971IU1wdPw72h1bcuCVPX8UmWqjXBhB47nAi1dgc
w0S2NRBYgXl9cyKAdI+jI4MG8ob9IxNMmblmOIh8Xqe32uIgNhAk9eLcw4fN+ZGFcxhGndgUJiGi
QOLJFV/oAt22YEUGzWym/rLnw5MIdQwdUG8HYWCRcZ//JIHHGG80gnt5e32Yf5iGHECm2LXzG+Dx
EtPzYsjeH06kb0ECXWbdHTMedlKCM1K1Jc5+cuBUrcZhn15tRlAbjcMz0Nw+wMWp/+JN+7G3j7gM
PxyGms7GhWc3KqdWiwoBC9eh/X6XctuomLV6rWWa9bXWg3KjYqpNs92o71ZXK6umUG7iuVA0D6qt
jfpOy2BFo1xrPTT1NVOuPTQfV2urRVP5xnaj0mzqesNUt7Y3qxXMVWsrmzur1dq6Wca+Wr1lNqtb
1RaAtup2awqqWmkS2FalsbIByOXl6ma19bCo16qtGmCCuIYpm+1yo1Vd2dksN8z2TmO73qwAxirA
1qq1tQawVLYqYAKAVurbDxvV9Y1WEZtamCzqVqO8WtkqNz4uGgCrg+WGsUtKoBIwTGWXm5sb5c1N
s1xtNVuNSnmLaymd9Vp9q6LX6ju11XKrWq+Z5QpYKS9vUnCgDVJY2SxXt4pmtbxVXic7DgmXCTuZ
ODQ3rFdqlUZ5s2ia25WVKgeQY7VRWQHVEBxkD0lgFpBW6rVm5es7mMA6h6KoH2xULB9goIz/K5Yy
y34N7BJOq96AQFJSHlSblaIpN6pNamStUQe51Gd9zVrADuSJpdVaSi91xLl568Aq7k6luFopbwIg
jKTGtZDSlCXBuipP2v4IvhY755bQaMOoxE4kJvikBAFY9PoQjitzdoi0BM+y6U2i2yQO2Hv8iPIM
vTZ8IDwiE0no7Rz4iIAxo30Y6ZDB5DBAImVaQXUSSs4zsdcHMuxiTLGrECu9PralQRFOPhOHtUuG
oyjAlsMoSBBMjDdGioyCb6ZpmPUPubIcAIDjgFgm9Gt+DqGISBiPkKWCA79/VMLaiLmM9CIq46L7
IGXdxsZ2suRKhcTsU1LIdYnGdfiS0dpWXKQ2NivuMxAvXjqd9SMPF1MHodpysYwC61rqvbPVQTqr
gyCGc9VBmrkhi+JWaZJi21butuogYROtGVsmzthEUb9MrSSfEkGtpDM6rKW/oVrJFgyvsFbS4rAv
VSvpC6yVNJOu1EpW/eeolbSrymxdcI5aydbe8Qm1kv0k0dlqJau3tFaa/sTSTLmEfI5j2UWVSwg8
s9ERAnzxckkXpsm158bCBZdMehhOwsy5SyZ9oSWTTksmm3XPVzLp4yWTOU/JpE8smcyLlEy6Vd7d
+lqdlV5541zVkc6KxZepjnRagKFcfYnqSE9XR7YCeuHqSEuNeaw6mq2zX7A6Yrk/4yiTwofnzpML
Hylpzlb46NMLn0kX4JTCR9vGzzSRZyloEvfxyo9s80SX8AvtKX7S9XyfGVy0fbvH6N0t4ltuYD9B
x4ufyBthbvYu+umfMFw8DB4HiwHOdk9Ko95oMT1gzn5SkpdAeP3k9M9y/i/jjZeqCmVuZHN0cmVh
bQplbmRvYmoKMjc1IDAgb2JqCjQ2OTEKZW5kb2JqCjEwIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9T
dWJ0eXBlIC9UeXBlMCAvRW5jb2RpbmcgL0lkZW50aXR5LUggL0Rlc2NlbmRhbnRGb250cyBbMjc2
IDAgUl0KL0Jhc2VGb250IC9GRkxUQ1ErTGliZXJhdGlvblNhbnMgL1RvVW5pY29kZSAyNzcgMCBS
ID4+CmVuZG9iagoyNzcgMCBvYmoKPDwgL0xlbmd0aCAyNzggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+CnN0cmVhbQp4AV2QzWrEMAyE734KHbeHxbs9h0DZUsihPzTtA3jtSTA0slGcQ96+slu2
UIEPHvkbjWwvw+PAsZB9k+RHFJoiB8GaNvGgK+bI5nxPIfrye2uaX1w2VuFxXwuWgadEXWeI7Lsi
a5GdDg8hXXFXtVcJkMgzHT4vY1PGLecvLOBCJ9P3FDCp3bPLL24B2YYeh6D9WPajUn8vPvYM0kRK
nH8i+RSwZuchjmeY7qTVd09avQGHf+2q1PS3aX4T0UFtxZahekfG7RdyytWnnW9mimSzCmVuZHN0
cmVhbQplbmRvYmoKMjc4IDAgb2JqCjIwOAplbmRvYmoKMjc2IDAgb2JqCjw8IC9UeXBlIC9Gb250
IC9TdWJ0eXBlIC9DSURGb250VHlwZTIgL0Jhc2VGb250IC9GRkxUQ1ErTGliZXJhdGlvblNhbnMg
L0NJRFN5c3RlbUluZm8KPDwgL1JlZ2lzdHJ5IChBZG9iZSkgL09yZGVyaW5nIChJZGVudGl0eSkg
L1N1cHBsZW1lbnQgMCA+PiAvVyAyNzkgMCBSIC9EVwoxMDAwIC9Gb250RGVzY3JpcHRvciAyODAg
MCBSID4+CmVuZG9iagoyNzkgMCBvYmoKWyAxIFsgNzIyIDU1NiAyNzggNzIyIDU1NiAzMzMgNTAw
IDI3OCA5NDQgMjIyIDU1NiA1NTYgNzc4IDU1NiA1NTYgNTAwIDI3OAo3MjIgNTAwIDU1NiAyNzgg
NjY3IDU1NiAyNzggMzMzIDcyMiA1NTYgMjc4IDYxMSA4MzMgNzIyIDUwMCAyNzggNTAwIDgzMyAy
MjIKNjExIDU1NiA1MDAgNTU2IDU1NiA1NTYgNTU2IDY2NyBdIF0KZW5kb2JqCjI4MCAwIG9iago8
PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9GRkxUQ1ErTGliZXJhdGlvblNhbnMg
L0ZsYWdzIDMyIC9Gb250QkJveApbLTEgLTIwOCA5NDEgNzI1XSAvSXRhbGljQW5nbGUgMCAvQXNj
ZW50IDkwNSAvRGVzY2VudCAtMjEyIC9DYXBIZWlnaHQgODA1Ci9TdGVtViAwIC9MZWFkaW5nIDMz
IC9YSGVpZ2h0IDYwNCAvQXZnV2lkdGggNTg5IC9NYXhXaWR0aCAxMTAwIC9Gb250RmlsZTIKMjgx
IDAgUiA+PgplbmRvYmoKMjgxIDAgb2JqCjw8IC9MZW5ndGggMjgyIDAgUiAvTGVuZ3RoMSA5MDk2
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AaVZCXgcxZWu6p7R6Jr7lDRHz32fPT2j
0X1ftm5bsnyPpZFGPiQhjfERgg/AGGMg5ACS9UfYXEuM4xBijoQz1zokJkDY7O63bDbZBTa7gSVf
srAhWBrvq54eIQwJm+zUN9PV1VXV9d7731/v1SCMECpFRxGN0OBoOPb76hMnoOU0fHfO7D00/dS9
MaiiNxAyPJbNpKem7+o1IVT1JWhLZKFBXl5yHdz/M9w7svtyB5/Sqz6DUDUZc2Hv/GT6uP7kLNxf
gPut+9IHF1AE7UGoRgH3zFx6X2b452+I4D4Ci9iIaNGj+BNIjErFnxOzCOGawpV+EU1TqlIxVVEi
oshHdB+ivj6EDl4mryGfaOtoO2pB1suU+KX8MGYlTfihnQh9/hf/gJCoTnwMujCIgtKBEDUlhjch
CUKs0qp0WpXWDorJO/A9+ax447sPdIieQxjdj5CYgXFahKxYp4eiVdqVLHa5oXBKVimqW5FhEabx
2X+h3qVpGlPnRA/Gwt5g2La8SXzsck8k5otFg/SZd4/AK9H4lTdEBtEA8qEkyKUhE+p1bCyZSOpL
JHyx29wuZRwaSOEfQxcteZ1d6CHBGpXC5UilhvZ3d1bfqzQzMXZ9/97fXne9y9neOjGeObl1S23S
oMPflvf03ByMxnx+o0mEfz/W1cNyNaZwqDcYDIbtLp3hjttxzd17ZtvazEaM/cH1A7O7DxlOnR0a
wFK509XUmgYNWK78hvKJA6gKIScswG3jlHaOTbJaVmtXggCsDtZJ+by+QPIfP34jd/CHP6yuaq6q
NphKK0pK8dvUT2/43e9uWNk4YGGwWFQCQl9ZAZ1eEtUBApDVTvOadBdEo+2YVRdkLsivvvpWdNeL
XyuTlEsqSsvKS8sqJA+9kH/xoUdLSktKJaXQXCaRfP87T0K1FKplEmh++kHq29Vej8sfCfndHq9l
pQ8sZtVb7RaXy+m0MBYd9auVqmqrzWi3OZ1mu7Wa+gXYaezK6yIT2EmLOFgyBXKXEBOAzRVOwSiS
eKGlaBZtyRprwvJFJnzdx99c3DTR2Gyx4teu37qlPmUyPqnWOF2JZHtnstbtUWuxXud2JuJNnbVJ
j1urpcz5V289jbHd2t25Z/YOKoyxzd7Vnd1968dHh2NRjRqrtdHYyOjh60dGozG1RqOKRUdHwEon
AVwnYb1BguY45+ILS1aq0Wu0bEGbiWSMYInIYSuATa+8HdzoLKYwOJNKrzUZvZ6UTqOuVBkM5iZ/
oMZUKcN0k81hs1lNRoPBaLYwNWZ1YzhoNiqkmBZTXxaJMDaaImx75/DKJVjJKfA0WnwJVRCPkRBn
UWIWYzqS/+SNFy7gl1/K9+Kf4Df35Y+ILy2nKWk+vHI3qBiVISQ5AZ5W99GoINKsIoPISPyn0Cj+
1atvVVTKyiorZRUVldLy/3k1n764olDKK6QVMiWPklJJyduPvk2qBDYKOS6VSCvlUsUfLtJHnFw8
nEzVJyJs3Ll8THxs+VhLY1O0nu3oqGEsZpOpRk/vW/6UvsbEK6Kj027l2KZ6juZ9+xYQoxEk5zlF
zbFaGmS/5cKFC2Lm3Ll3fymqu/y3BUvRb4KlwP+tSh5S4NmCOQi3rBqPkAN83288kFarpFO4XFpV
7Qs0tcY4u0utuUCMSGyI6SrG4vUk4t2bW1v8Po2aOj/IxW0WuVSn9wUam4dXbqNHbS6H3WrQl4p1
+hqz0aIOuZ3GKrCmTh8Md/dNroQB/xvzY/RvROtQLwLWxiUFpLuT8HqerEDZHFcEPmEsUpIuwQwE
ZWyRwtgSLRR9iV6pkZSoiz5TxN9VPkM5tvX0sHGLVfqwqqkh0xiLOmwghNZoBnqp7cn29IXCWj3G
ek0sMrB+YXFsNAxCk0I/ADqA6/w1QUO12xvjuM4oa7HKlRgr5YwlFu3gONbrqa7Kj2ON2mGLRRuq
13m8SoXb2dAwdt7rdBvNCpXd1tmRnb75eHamr8ftxHEubWDMphqNWlSm1ZvMDpdr+QevLOboiwsj
g3HWAB+WGxxe2D84FI1ptKCc6NAA2Hjmyuvi+8R3oU6E1EU9EJySIrnK5sTGpCSLIOasnFUpUH2R
dWaC/s2bbjh+/viudG8PKOWRaoeL5do7Nx3dvrOxycxgq7W1ZdeOoyPdXalkwG/Kb6E2hptbB4a2
7dj9zRtPjG/2B6mLXzpx445tbBSDof2Bhub1CTbgM5uVCo+3d91M9sjR7J51/b4AlkkNWlO1KX9f
vjriD1itag3GtYld6RM3gWQ3XXmdfh24m+xehP1JKSIiCXAnhgbG0dt5BgJMrIJEwBCnxHWV5TVV
AV9zMxdzOYDSLvD0AwDmDUhXWxiPL851bWlp9fnUGqDrkaF4AiAh02thVOMItbT8NbvDZbXrDRKR
Xge+aNRGnO4qo1SO9dpwqKcnQ70IGL4xPw4c3o9SaIJguMB4bgJWuwaWCQt9n7/xsqzxN5bAGMof
4/miwYDn1ZpQeH3/Qm58PCTm4Ugc8jyPSwqLwCV9nni0ZaF/fTikUT9RKTWao7Hexjjn9ur0sJm7
HAmue10sajZKKynbdTPZdevADgF/hlIo9VVGizE/IS5xOxxmo05bRqtUVTVGcxXrchh0leUeb3df
Jnt0amAgwZmMWKGMRDaMncgNEEDqsclYmxwaBLsxYLcssCvEbGKigaQgLbEdpySIA+8kBT/7wL55
2+Plep3V4nF7Zxob8r/FzxlN8eT6Ac3Epu9YWkNhs0Uq6+m6le48s2zPDA+n6s0MKBg9Dj/Xo5dJ
BMkC+z3+vZdfBiuQCIq8WQ8xD+wIVqA4q6BZrfBOCaaLvABRmOAHotP5T+Z7n6buPrhtS0szgaHP
39K6BX/iHZ3e62toWJ+vx8+NNDS4nRoV1bvyqPhYjYnl+tZt72hpTSTcbsXKX9NvtIRDVrNSvvKO
Vu20x6JklbCz0z8C/m2Em6Lr6YC4VuMvAajJouOSjUVYcMF5Be7CapmUsSTi/TtbW+SPlJnNLNfb
lz66aSJZW1WNVSqrJejn2FRt/ZbuLo5lLLJvyVKp2X6WszBSGWXbNjCYTEFQhLn43sqOxuZQ2GjC
AV9/X3b64L4NIy2NAV91VWU5Bp4P1jW0yzZzcaizXP8AkeJ2hOg3Ya+BGAqTBa5dJGhY4Bi3AHo+
ZiUW1kKDFjea7TY/RKXNMx1tbicw/8NYUmao8ge6ivsJuCTgmD6WdDv5RRhNUbare3QlTJ3v4OJ2
m0pBWMQHZli3clx8KX+91Wo1mlQaCKYxeiz/Lj4GOIDY3rlqYjuskLNz+JhIXF4hVag/Fqg2bHr5
fs4fcLqsNktLe1vryzAW0CLKA1ogeoCoXAtw4L/3i4LLn6Rjyz+h7xYfO5Nv+Fxee4bsUlfeoH8D
WvCjdYXolGxFaoWzsAFxZEeKkyD9PVYi+xSwUtHyReriivgTFEZzsZENh36yYxfGtx8eHYnxzCTw
1Dnew8G5V/6JACAS6eyq5Vx2jVqtcbjiia62SNTCyJXns8HgqVtwFcXhYChdptcadOC9+IuX1cST
zVp9aZkGoqyaqhq8cM3gEMvpDXodx46OHFoaGohF9FpQMMsOjxKNPgk/14FWiGeBOE8+LT4G6QRG
W/AL1CC1QNrVnFW7Bb+FX7jvPpJnEK/LwAgVcsJYQSo78S6B1ASE8E0F/IgzOJ7Ysu266+9c+S3+
6RdPnZyarE0+gz2+3r6Z7GFggbr5Hds7O91u6vlv3HTz5q3BsPiYx7th7NgN37x9ZqqthTFf/obD
0d21Zze8n8TPS+BlvWhHgXFW3SnJFV8t+JHELQCYEK6WTykIBRCo8mRNuhd3EbdADhxXYCtAM/gw
vvdLw6PY62lr2bhh/L8hdzGa/ME6zuuzMCqN+IkyUw3HDqyf/3F2Rqutl8vlMjtjd7IOl05fWUmX
mGz2UDhVb9/Y1hzwabU/aK9rCIaqaiIhzdjGu3d3tXvccjklqm8Ph8xGuVRSqtZY7TFlSyLucem1
23Y8mA8NebxA8wulIjGWVZpqIP7ivH4IJ5QnGXMsUl/HTYgoSVlVdSDYOxGOgN2AhakG8Y+QHWwD
3gr5FCewDb/p8BG6YDMt5Fl49sI991SUW4xxdtjisFUrdXqV11AjVYhKXqIfXe6lH73hcF086nbo
tTRdcgskoRiXV6q1ZrM7fQPBTwi86gKggbgn4V/ACvXCU3mj6ITotcs1otfOnCG9ADMlFPSq5SNT
HhSFRWB7Id/lnYffOHhCAYAWimC/JGaV4jF+1xPJ5DKZUpb/9In8HSVCdqZU8I/OXsYHSirKy8pK
JTRdKqksqygvxQtv0+dAB0E2Eo8GwjHXcgv9jFyjNuigxOtqk2GWcy1vgHg8rLEwkKuZFQqz2cow
Fg39Iu8JJOI6BBEXYfViMF0MT3QFfH+Q4dfGqxIBlbTh0JbtjS0Wxm5rbd6xbf9IR1stF/Bbz7iT
tev6t++89tyR4xvH/QGMw4GJ8aNHvvzLe+7uflhjs8fi7Z2id9fGUl4fhCNudyLeNjDU3hmNAb8X
4qj7ipHYpolzDdFw0G7TaUH/KdiZHoGYeyPIIFh/1QHIfr1KVsJSeXNAHXiusEMVZSDpBIQ3RfOs
XulHsNGSrB0eze7o66+tc7pVn9f19hxNxSJ2m1aNdQaPt66+q7UFdgHYmPZkf/zQnqzpC2UGg83u
DQQP19VD4K11O5OJVn8wEPC5HCYjGNXfX9fg8UJULpdaLQm23zLu8ZZKtGqrJRplLFqNUqZR6LR2
G8v2f3pgPW5uvlXjMxlVijKJ09UXMJrUWqlcATmbQq0zWG3+ALAHH0lAlPleJsXHE9/7Hr3n+eeX
P/P886AtPeyAv4Y+fJ4JCCVJJskzrfmf51/+Lj6Wv/MiluHKZ/N34hP4iXwHFaBk+S34yytvrfyU
oP0koN0ODDVO0F6k/yJ0wEn+dB72vowaFMxHkgWDvJfM0ai8QlfldCVTobDFplB98700TW8yuhyx
cOvHerpMtMFs8npi0daRhjq3U6166P2j/pwULhrb/YFsbnW8FuKm5paRldtAesjScROfq/I7yqkL
4kvvxqGd7L93AgdANo75vRfYQotnaNXym0/T/yl6beWte1d+AFsw2WNuhLMsE8zhBZaHMxJrIbIW
iNkeB8aHQrZfDckA+TyW0Jtw4rN6nFVE6pp4Or/0seHRWHGfPQ9qg4BaFN0wcvjSrp1PYqnMwoQj
nd2JWrtLBdmJEEG3RSKMRSmnbCs/Cvqnqo0mfZVCKSrVAw86HG7Rf+UnzDUmTbV2JhQ8dSr/bwtD
gxykcGSbjY+MHswNDkVigGK9Lh4bHSYIEefH6WVAmB8QIvgjn+pyRV8EwhNOq3T6IgeqWWqry+2N
xOobBuxwSqA2GJSDHe1xZX70mVfLlDKlvLKSoivLFVKFrOLvnto1MJRIGc0ULr0Zjg7r6477RdzK
2Ro4oAs6HGXlNkjmvR4LtZusZwZsUwkc10Li6+L74LoavFy9oRbD1tUgTJBCYtXOsH29w8NDA63N
XrdKBTtgpC4ZijjhTFDyWJmVqU+NDu/Jjo6kkhYzOWhI1jY2NTYlan0BPfWLI/s3b+rraWpsbuxs
H68PBxiIsOVys8UfqlOu62hnIY+BSDUS6+7Z3t3SmqrnEiwXZVk2zqU+S3CzE3CjAjlq0SYQa61m
CbERpitCIXnVw7W7ZDEtW41xi3RfzB9U2OZoa9u+49qRllaWdTh054wNdVt7muoDPoOB0jpcwXAi
kUyvH0gkjWbG0lA/MT7/68OHvq/S2EkY1xrn7A41nLQ6bFy8M8qxPo+xivr5E7fdsW1HKKxU2G2p
5FDNVm8Aw6FBZ3bmtrDTZaiWyuy2psaJ8T17JzY1NVqt589/faCzk2XJASs5gmlo6utubPIHq6qV
MHEyTvQxBLGSHfRhQc3v6aOY+a8VmTD6Wo4nrkbiH1KKm4PIjp3uto6JzdPZTZtb2pxwytnWtnli
z9TmTW1tLucjkKu6PclUT3+q3uVVa7RqrztV29dVV+uFaIb6zo9Pnd4w5nRh7HKMbTh96tLPTt86
OmK3Wu0jo7ee/tnfXDPX0WqqMZpaO+au+coX5ufbO41ms7GzfX4e8AmkIJIDd5QTfFqVYs5JQvgz
eCb/Xdz/FTz+WVHDK2dfu2z4LPTdBjK/AzJnQGIhC3QzgvXXilPEdoFaC7+rKuEFh95FnVwNhYJm
Cr+id2z2np59c3fl//CpT3m+JTUb2Uhf7/TG7q44azJamFRqcGhHQ11DojYctYHdvZ6enl3ppePb
t7a2uJ2GJ+RVNeTQZGRXW4fbp1BB4pfo7hpuaWuB8I51OSFcv2li3bpErYnBW7d83VkbCFmsKpVc
ajFHQu0dAR8cIqn0lUo4wzAZfeSAbqqnKxzSarFa5/E2NA1aY15PTY1MirFCZTZ7fKFmj7emRgVT
yCEkNpp8vlQd6I3wAMqvuy++Q97wNvnD5urPlZX8GJyjkpNYOGwXPjBG0pQfQO2lzyF0hZWc4Gcq
PiXXIPUG6hBfRPeLltA4lUIW8cUrK1Afo86ik/DHzCloQ5LbUBm+iG6B9pPkWUkKzcD1JvjeCH0Y
6PM4PwdC49B2O9w/Jh7j5xyD+pMw15Y17zCJXkGhkrPofmjLwvgUGQ9XPbSdhPecgudkPWRuMVzJ
u3bCdwi+Z2DebbBuDWpAn0FPYQXO4q/hZ/GzlI9qpD5Bh+kz9O9EB0VnRQ+LVsQ7xefFl8SvlIyX
TJYslDwoaZYckJyS/EdpX+nzpf9ahsuOlp0u+0K5qnxz+VMVXRVnK56p3MprKIhILkM+RPNXf4x4
bLV9O3pKqGMkx41CnUISvE2o06ga/5VQF0GfvxfqYlQJryjMX4JklF+oS9BhmuQK5FOKNPTPhHoZ
kolKhXoFMoqGhXolComI1clHio6ILwt1GfKXvASRFBbBno6egG+hjpEZm4Q6hWS4X6jTKI4zQl0E
fR4R6mJkwP8u1EuQkZIKdQl6iyKRGpm/FHnoB4R6GTLSvxbqFahWpBfqlWiraE6oS1FedFmoywBP
H0PtaB4toENoEc6dZ1AW5RCDvgrfGJx0RODUkUEjwBlTcO1BaXgagFovmkOTkOMwqBXthcKsGb3E
32XQEoxaRNfyY0nP9TCqDc5nR2DMBqgPogFonYV+DMzLwMyLcJ2C/vvgugj/VTKwsmn4/ePvR+3z
C4cWZ2eyOearTCwSSTIjmSmmJ50LML1zkyGmde9ehn+8xCxmljKL12amQsz63rbOkdYNvYMDzOwS
k2Zyi+mpzL704h5mfvr94xEsehbt4gUhos/CguZgQaOwwDlYOFo/uyuzmM7Nzs8xo+k5aCBLnUH7
QSVEBDSSmdm/Nw2VVug9Cc/meAEXYY4gfD9i9talyczcVGaRCTIfeNFHDP1A/zFeiKVVEaJgPWJd
NJZZXCLrj4YicPdh036ItAVhP6zz/9eiBElEhQQXOX7NBezN8orfCKse5XE3BAomz+fgl+CHKJYB
XH0QQ4OAoWmYj6j/vZ7kbhHGpuEJMek81LN8GwMMtB+ekRVM8eOKhl+CN681+UegByA3M7uUyywC
JGfnmI2h0RAzlM5l5nJMem6K2bAKu8Hp6dnJDN84mVnMpaHzfC4Ldt+9f3F2aWp2kgBsCd79QRQR
510E9yW/7yEUrSKnfX5xYb6AUASaIxojHsmgfr47uV/iQY1Gc5lrM0x/OpfLLM3PIZ4IcjBzHQpD
OcCXEAx6P44nhfeHQL3z4LhhGJjLLdSFwwcOHAilBQBPwipCk/P7yFNYw18ybQ4YagFWS/iBoHgG
rEYsSGxC5twHLvcnX507tJCZyizNzswB4EPZ3D7ovxGGE2UUaIYAoEBHHw7saV5RBG5EZdPw0gOg
DwLXIuiXADi7AD4Z0Abpl4N+5JcAi4EFFkBImIPcp0EIMpoQXhHI+3kgE8EYmJ2sZxJ+GRB+HuYm
YyahZEAVxHQE8sXZ/9w1A5w2LmUI5eWyAOQ1hDE9Dwhdmp/OHUgvZghFLu3ftTszmWNy89A3w+wF
sM7B0PTMYiazj8B5P89SB7Kzk1nm0Px+Jj05mVnIAexJ9z82MyzgLwUD0eTVrPx/hMHeVcYWMIDQ
/wIudga+CmVuZHN0cmVhbQplbmRvYmoKMjgyIDAgb2JqCjYwNzMKZW5kb2JqCjM2IDAgb2JqCjw8
IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UeXBlMCAvRW5jb2RpbmcgL0lkZW50aXR5LUggL0Rlc2Nl
bmRhbnRGb250cyBbMjgzIDAgUl0KL0Jhc2VGb250IC9WTFdBWk4rTGliZXJhdGlvbk1vbm8gL1Rv
VW5pY29kZSAyODQgMCBSID4+CmVuZG9iagoyODQgMCBvYmoKPDwgL0xlbmd0aCAyODUgMCBSIC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2QzWrEMAyE734KHbeHxbs9h0DZUsihPzTt
A3jtSTA0slGcQ96+slu2UIEPHvkbjWwvw+PAsZB9k+RHFJoiB8GaNvGgK+bI5nxPIfrye2uaX1w2
VuFxXwuWgadEXWeI7Lsia5GdDg8hXXFXtVcJkMgzHT4vY1PGLecvLOBCJ9P3FDCp3bPLL24B2YYe
h6D9WPajUn8vPvYM0kRKnH8i+RSwZuchjmeY7qTVd09avQGHf+2q1PS3aX4T0UFtxZahekfG7Rdy
ytWnnW9mimSzCmVuZHN0cmVhbQplbmRvYmoKMjg1IDAgb2JqCjIwOAplbmRvYmoKMjgzIDAgb2Jq
Cjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9DSURGb250VHlwZTIgL0Jhc2VGb250IC9WTFdBWk4r
TGliZXJhdGlvbk1vbm8gL0NJRFN5c3RlbUluZm8KPDwgL1JlZ2lzdHJ5IChBZG9iZSkgL09yZGVy
aW5nIChJZGVudGl0eSkgL1N1cHBsZW1lbnQgMCA+PiAvVyAyODYgMCBSIC9EVwoxMDAwIC9Gb250
RGVzY3JpcHRvciAyODcgMCBSID4+CmVuZG9iagoyODYgMCBvYmoKWyAxIDY5IDYwMCBdCmVuZG9i
agoyODcgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvVkxXQVpOK0xp
YmVyYXRpb25Nb25vIC9GbGFncyAzMyAvRm9udEJCb3gKWy0yIC0yMDggNjAyIDcyNV0gL0l0YWxp
Y0FuZ2xlIDAgL0FzY2VudCA4MzMgL0Rlc2NlbnQgLTMwMCAvQ2FwSGVpZ2h0IDc0MAovU3RlbVYg
MCAvWEhlaWdodCA1NTUgL0F2Z1dpZHRoIDYwMCAvTWF4V2lkdGggNjE1IC9Gb250RmlsZTIgMjg4
IDAgUiA+PgplbmRvYmoKMjg4IDAgb2JqCjw8IC9MZW5ndGggMjg5IDAgUiAvTGVuZ3RoMSAxMjMw
NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGlegl8HNWZZ72q6m611N1Sq7v6Pqrv
+751t+77Pmz5lKWWJR+SkWQMxBw25vCBwYHAxPFwB3AghBmOwIQ7TCYcnpAwzOwm2YEMO+GXQHbZ
HJMFW+X9XnW1MDYz7Ozq+blfVb16x/f+3/993/eKQARBlBHXERRBDIxE4p9692XhzjHIW7fvunLW
fGegCsofE4TzkbnC1Mz0e11mgnDdAffSc3Cj4moyDNdvwbVzbvfKFYOVvpfh+hOCQLpdi9NT7f9a
fz1BeMrg+fHdU1fsIboJeNfzF3DNLkztLlz5wYefwfWzMIgxgqLPoNsIEVEmOilKQAvm4i81RcyS
1WUiUkJLSVJE0vS9BPm9JuKKs9AK/xfLj7QQTYTtLEl/yF1DusWnye1bCeKe9/6JIOgaURtUYglE
kEQrQZAzIuiJkBBEQmlTumxKWyvJck70F9ycaOyzR1vpM1Dv2vMf0TfT/UQXsQVmE8+kM4xYIvbY
PW4+OeACJ3wj5YanOGVSyeJjh734VOIpPkgn4loNo1RrNXxL+GZKqCHWwl26r7KyUuFgHa6E063R
ymSU2GxzBIK5mq57BgaRz51vHBka/ViuMJp9gUzc6zeZq9Wi56VmYzzW17Pz72ZnGGb158MN9T6v
WoVezKZzgZDJjEKBRRLRe8poEVLIzEafN53yBUyWKiUaH7trR3uL161UkHRtSyRsMVXKJWUqtc0R
Vzalk163ltm05QkuPOj1iVlrNFJbk1pPk+IynS4U6RmJxUGIxJPcBN1MDxL1xCZYqZI8xCUBqbVi
SGpG6VAmUyAjSAmNlk9MQhBLBsSCk+QiuTHi4v0Eljskuhmp1OFId+/ubCweCLIOjYhEkJ4mSfJ7
uACJ1rMWnzcea9zd2x0Jq1XPyeQmSzTeWZtMuTwaLVJXO52pZFtnPGYxKWSkff/2uZ4efxChCqlW
47AnyEqlRmeymLj1IsrjdllMGkZKVav1BotVn3S7DDpZOfL6Oru3z+2f6e9PJ82manUkPjZ+00rf
YCSuZszGbGZoCDB2IyBuo+gtQgq4sTG2FOArZSPfR/vP+dFD3Hvo3ePHj9NPHAcJ3go1C3xN+YV1
PakEQ/5GqP8K+sOPfwxvUJbjP3v5ZRA0cQCQmQVk5ghCVUKeIEetBNBZAh9InxcuL0StsD4OYX0O
omCgo31ycstUf28u47ArXlY25veO19TZnZVKhJSVTntdbnxXR3v1i1K7I5sbGJw+snmqps5oJC0P
7NqZbzLqkd7gD9XUtSg2pJJGcyLd2z9T6B/MZE3mVHJB1lrfGI4ABoP+vu65WTzuF89/Qn0qGiUc
MO5UQgW6x9iUMMaEprjIvIJhrXBgnVK++J2aK9AT3CAK+rZ5gj6fx2HXae2gFIlE+v6hIeqx48jA
/fr46sqgy41ElIiWiEWHJZIyCcC9reUb5D0Yo1hWXSArLZGBIaiLOleSQYaEjkFyVAl9gowY0Eic
1tDXZXM0NE5uvGxhYrK+0e5A6Lqrf/PHfZc/z2hd3mSqKZ/Jun2MVqfxeVLJXFMu7fNqNaTl1rmd
bR02B3LYOtp2zt+KtLccRUePcR9ePTIUj4GaqphYfHjkqmuGQZ9UanV1PDYyjOX0JKBCD2OGEduU
paEJhKK9UJvwMCFfok2MkpqpqjZZvL5IbaII/qdAUb4DWkIiSmezBv2pZMtwvikYgHF+fyAVZy0y
mUbrD9Y3Dq3eQo3Y3U6HTactE2m0RovJqgp7XCZ9lRxptKFIR9fMagRGuXT+Y3o9YBd2DS1KoCUq
9dfnfqIWvf8Zi+ewGeawm64hKmAOCIHEEvw/6kHuJe6FV9E93PLfoSDyv84towfR81wrGSQV3Ab0
7dU/rv4M3kf96G3qGnIPbh2lbAzqJ6Po7XvvhZYZaPlZaDkJLTuoIhkX141yUAkVv3AgkyLBqEo3
SnqiSlCfvXVrWXlFWYW0vFxaXiG9483v//UmSkxLaBFdLoPbZTe9clBUIYVnSESL4Y8qPIH+yeiw
s06328HanVYuRNes3qfzByNRgHjIB+JSo0e4CcbusvvCllAoGg76DeQWGO0RGG0PSCkA84ClAyJI
JYtoxzsCn5jiHD5XW8bGkK1PcZ8h0I14bGhgyeTz+LxOuwYIzONzOFXNsbiVxVr6EfXYuVFQBP1M
V3skxDCIpChaRJ2g4A9RqLzCYApHesqPQ+fE72EkDKAqBBe4xwsBJVB2iZ61JXrmb9BMJJGqH21p
DUW0BvSUGFRMKhU/KikTl0lENCUyspagrzY3ksmk/dSdEgmN7I5cbX//Oo4mX8jU5lIJn1evs7Ks
w+Yw1SdiTjtgnxZJYEzTMKYZGNPIVyNdDUhXryGdF97aKEuSxLpRnAqmQEZJqsRiuYLRWu16g0ot
rUCnQQu+AZmUV1cb9A57ZF3QryaVWrXZ5HRG6v1+g15ejh4R3mpxecjHB1JJu7VSrjeEo03NQ6v3
fa4cYpVGbzSZVR6n3WRQVkajM2G3w6BTyNe0ZO3t0dFHVm+B+T4HbGQF7GIuwsYATiWSSSkTQIbY
GlBrHfx26XFnSlZGibFSSrRbVm7SB/2Njak4wE71NN77sG6DaoNyG6ys159MtW9oyvv9KjXgdHgw
mbba5AotAy/VD5PL577rcLptDq1OQms1ZtjwmKjLozfJK5GWiYS6OwrkTzFzHgL9boe1iRMtMNrS
VlKi6rXtRLCHMoKClVANWBTIVGIT8I2akVrldtVkejKRkNtp0MvuVlptyVRv3/aVyY0NjcCUYOi0
Nq+f2Hpw42QuZ9BzrkgsEQiaLBTZKdUbXZ5YHP15vL0zkTKakaJCy7AWZygUijjcGp3T2dG+a8ct
39q5I99kNvn9PX3zO6/VoZ8heaXL3ZCf2tzY6HYpwZAliSPn/5XW8zrZA7su3m/EHreyyoVhlABT
JYPzF1ajCKoMEpYsI1gla9aeMFVqc3xw6Mo3N29BN18xMhjnV+Sp4vo8hlcHp9VfVcpZSzTS2pZO
uh3q6mq1w5VMteUjUStbpXx8RziKjh1BejKFAsEpWqM26LUaKXrgLMDMabEw2jK6WmnQm01GtOuy
gcFkClRSp0slR0evWB7sj0ZB7jCJxNAIzBP+6LfA8pUQBtAvykY5MAsLq+EpLQ9lo8uPrJ45/Bri
/iv60+r/Usgry+USKSiotFwmU8juQj9B13AHRW2f/YD6G5cXdmGTXi4zmuwOj8fFrYd+9nLjVCvI
00X4CEIktFtCrCclMHJJaBlMgtjCoVqR3VVT2z8w5vf6XR6rTaexWJwOn9uXiUedTkaFuHmy58c/
Ni1094XxxESUGChHegy6AJIDkxYLMtxK/S1vGCHiYUCsk+4hJjBehZ1egKcnI4yipG0ZgSgE5nPz
+BXq8EYUfuCwl+zQoqqCne5EJmsmOzQyt6W7L1vj8lTfIzPqPc54LFcTj/GD1hsDwbqG9nxDYyxu
YRHaueP1gba2dMrtVNxfptHaHD5/+E+gah5POp1vam+pybidKNVX1+ALarQKGWtJxfusWau9qpoW
SyUald0ai7EWhqlUqKsYuErE+m8fGUaAaysbi7epg2aTskosvitiNKvUssoqpVpjd6SzmG1g/THO
g2BvJZTY9ikxZsns5q2JzxkTywxuPfc03j90rNXvTSfyw81N4ZBOg56+2KIQvcVdlYglwpcYB5da
FLAgxP0wGj+gEVsE4HU5QMFskKmdq//20ktk+Uvk4uoJUdvqG2T6sx/g+r1Q/zoevaWdkyH/9kWu
jU7Sp89O0KdPncK6jFvdArXU2KpcW3XcvE1YTexaOKA3gbnoLchkqWuY3HgV9+FL6K39mzc11LPW
l4dHHvg3bqih1udWq6i/Guvtr6tzOlc5URvUTqa7ejbvb25a/R3Sqt2uRBxGBx4svQP61YEPCQa+
ADdPSmCGDDZu/xJ9Xx2J1Te1dzR3dbU31seihofQ1Alq1Wd36Q2wf9+hrGItfn/8bO8JGDwCj5n8
BQpgmwdLBn3yEQpw72JZ3Aa91YkmiTrcW9Gy4f9fI6CL3c3SAjOCxctrg425LdDVMTI0MtTaDJsD
Y3dG4zXpcNTu0GjFz0pZay4zNLhzfnS4LsdaA8Hm1uGRvv6mvJV8Z+/WkaHuzubmfGNrc3ddMGA2
AUtUWqyBcI2yp7UlAR4VsFA40ta+bsvAUGdXU74p35hv/zoBc9kPWjkAY7eCdw6+99oaCZpZModK
Ciq5iJ9KtnhGWL+UCKiDHkAuT3Pr+snZuXWTTc0ut9vV3Dy5fufM5LrmZrfrGXAWPd5MrrMvV+v2
qdSMyufJZbvba7I+8Gu5dR+RD/zw0I1DI3an0z4yeOMNP3zrxhuGBlgrQlZ2YOiGG9+6e+eOxkaD
HiG9sbFxfufd35qbb8rDnoPMxnzT/Ny3rvj0U8BeAWY2CzMz8tbdRYxTiglgE4qqAh2D50qyuN3T
s2AiNbds3nrFdVu2goBZ5LDnm6Y2X/3nQ4deHxi861R/Pxoc+OYD3V3k6ccPXr9uMhCKhDesO3Tw
4ccOHhgfCwbQY49z30GKQwcROniI+z33+yNHjh0VdOxNQceQhNcxTPnUR5z+AVCyul9xZWQbec1p
LgCatoW8b/W1c3/G+LoMZnI5zCQPFxeZJZmLd/rSgpV2+gvYkkeZGNWoVQF/c9OmxkTM5zGbNPeY
vb6a2t7+2Vtm55rbrDbW2tJcmDk609ebzXhchkeq9AanOxKvXd+Y98JqkacPzcy2dzicOp3HA75e
viPfmkhb2URs04aDB+5+6MC168cjIaM5FKlryOfDwQDQNAPybJ0u4Lk0Q1TiMNhYYHHbLlwTvA/x
7J8BkZSYvqRLqgT5itvji8Zr6/odJotVpdMp+zvaotWc/2VUVq6sqqyUlVOUrLxKoayUnXtxW/9g
OmeykKjsJgqRtTUHY3Rk9Rqjxwf7GFtWzlrcTpg6eYAgi1oN4+HjTTzjFXX7I167qcqijpNoK/cN
qrpUD+E6KvCcPvmIu+E0knKvFyuevZG8c3UHYG8FraMnqI+LraqwhwR5hfrgnJn6gFp3xx0ccQdQ
FCKOg8VZD4hwwUWJpEqaB32UzLoSbSkTdD0wXk3d5MYrVyYmcrUm80tgacGmlBwczqUd9ko5ehH9
9vDUtroG8O2N+rrclk03UbvPfXdba3sgBF6sKgwcM0e1Q9+vAmvhviEOgnhfH0iZQQfIB1c3vkR9
jT7NVd+9+oGoDXicIm6AcbbzCNxGHIT6Am95wDLDqQS6TEqgh9KNksuyRnSMsLQlnx7rHU4lHlkz
AFRCS18aLQFc0O0mc03t5Mb9V6/fWFNnMmPvPhHL1IYj2FAzm7KZ0eGFpfHRbMZorFJa2XCkvg74
2KVl/lmuwFtzV0c0jg3vinKLKZkYHEvGzUapBHxhuQICKrVjg+ms3QGhOKSscthrckMl+V412tmd
SmPTgbWkk92dI+21OeyZlNNy2JL98Vi6pQn2ErMJmczRaGNTSyoW9/stbAVdoTf6A5kaMhn2e62W
6iqEqqotVq8/7Pb6MMlrNU67z+tavSsUCrjsWo1G63CGwuG6WMLlVjMMmJipOGDrOGiQBeyoLmIe
o6a4ArwFtSa81JpjIoDpC/Z/QnBxMwkxAwmcGmx9qC7wzb6wIgKzk9s3tLRhm0n2bFVNZlM2ErJZ
VVWIVJtgCplsx2xnZzii1iKwnaLhvt6FPWPDYYp3ehD5aNH92bHTDqThiyWTrSB7FmKqlawlHm1O
JuM+j0HHrQMPxGmPx+r0PV6fssrjqqsbfxV0FkKi1Ta2taUwc/PB7bMdbW4wyad0rMVsVKtoKaM1
W8D1P/ejD5ZWqLf3DA7Eo1h2sXj/4J69/QPhiEqNxxTtB5MFER9w47QLrK6Oz2WXUQpY86xt3sqS
v2Rj1gBYsiIkJQxr+egYWMqmfDrt8TAwdw1wYiyeSMRjHg8YZSU7EknfDVttDAM+LoSVbHZvwBvw
e+1WMKKRz7PxXW4Cavq82Uwr2tIYDBgNCjl5GMeEDcFAA9rans34PAxztByCQC53insoF47YADBS
soKBkFsoUsN9e2cgdBQMFMRQfdQzMD+ezxCEXHCmjh33vs8xt/jep/rIa1cPkNcS6PzZ8076p+cP
QU1CAuwkov/xl1u3goQ+Bl7AUU9sCV64S32d+/qhp55Cv3iH60J/j/6wjVsUvXVuipRzkdW7sGSd
8N4jwCdwkoBjKXxIiXztec50Bl2OVs6QnavPkp3k6upfktNQuwtqX19kH5sthcDpYJCNvv7sj6j4
qpZ69dzfU1O30oZTR8/+C277fqi9DWrDmIpxSRybtDH3U3eteslTqzMUAqLiJk9yiVNQ+3aoHQSu
BmZLlJpmbidPr15L9a6Okz85TLmPHj73c5AXRGuhbg+0jONVsOpYNYqUBOGqEizcnmJ4A+/YqiKB
AQNBArudOo2jdmR1laKqWv7g4YfEEHiRSqSSahVJ3vu756SyclmFQi4vl8ukz/2KmkmkkqF4PJsM
g1Jz3eiZSkal1xh0ukxdNBlKphLnTonaOK3O5XUFY+Ggy+M2oN+CwY3WvMVmGOeFIxP4EzT2gvha
cXTFEQoD5ofNDxoPm/rs7TkRHyIqk1RXqapwsAhHZne8/c4LuyFGJKZFlUp8D7J49/d2i/iiuAys
YooP5YrnXkDXqwx6q8lmtbT19bVbrDaTBeI43NWitnMvNNc3xHKJ1lYTa7GYzUYtupW7TGuEaIaF
NbW2gT2ViDfUp6kWWAFEcd8gny7a1fyeChKFDRVu4q0UZn4dWD89sPeshwth38ERaD6VzFKe+Uo+
owMOMoSZ4lvY+L7wnAc7i5fsR3SPla1rWDe5fP36yRrYVqV/IwFnwplNdd/c3wvmYCJV2xCf3RbP
piMhsKabWw/u6+qWPV3u8zbUDQ6sv3x8NJ026CFa4E7nuoYb6wM+LYOWNnZ0x+JGo82aSba3dCuz
4Qhrq65ubLiqJRwy6uHA4hTs3mZjKNC0o64G1TcsKDa1tUZCWo3JHIk25buy8ZQ/CERJSy2WAMAD
2P9OkEYnSCNLrAN5CKtfkgcPX7zspZCbBMRUIjA+5io8uORA5yKzku4EMyNXOzq+sH/DxvoGc9EE
3rJxX2djQyrh8WgfM9c1DHXX1fn9wLTr161sGezPZiyW71dXO4Gc2+OxuNenN6hVHheEsptSCacD
H3wVRifqm+yOSHh8bP+V33zi8M0bN8TCqLLSBh7xgHWDz2t3tLROTR/YEA2DrZ+tGRjc2QLcB+H6
qmqrLRZv6mzKg0DNWo3PW5sDbOwBaWDvpb4YKcL7VkkWF1r4fHzgC7IAU/8LEQ+6zxWO1tS2tPXf
OD3T1Aw2P2vNNxVmDk/39WQzbpfuUXdbx8JkY6PHV1WNxke+G/V7HaxBq+B+gd67QWc0arSVlank
pk0Hrj350MFr10+EQuCdBEJ1Da3Z3Q11eF7ThQPcH44cQ1KJvFwhk6LBezG64eSTvgm4SoP1+ktM
X5Qg33yXG3gDySTlZRXlUolEBMHx8oryMqR+HeKHTVoLa3dYWIZhrTYba9GSr0KrT5z/iPo5sBqc
BJd0hj8avVBfUjjSQ/1cb4wlenqnHp3dbv9BOcOYTWAbb08nudfRn9CDhcGRbC3YOuvXvWLNhyIW
q7yys/0oJcUsi/n+dJGT+cMDiA/igwRyFvWd4frQL89wR7ijZ9Avub4zVCtE1vavNpL1qz8kXyEP
wdtFrW4jgM8uRvHn0SBBjdf86BLZOVTA/xQGumBO0j2Al8bGTVuuWhweyeVsDvkz5QzYEolYV3su
5/OAxjO8yxkGD8CuN2meiFC21RvM0c7O6fnR0doamxU9Xxgdx8dHBn0k2FDXwficHpMVFlurxmDr
rk0l3GA9IolUrqhWq8j/coKbcMEpG7LaMrn+ARztKHD76csAjVGi6XO5S2CIPB994Xxa2FrW7DKo
dKkbqjdABKlj0guWj4m16tyhSHS8MR+N2x3Gy0bGMjkw8f8D1/T2vfvGxtNZ5ppcDk5KRDdKxWXI
oI+G29smylOJ9euu2X/qK/zVN2CFYWPFuy4WOHYSIJhie4PKcK+hunOvozruNdh3z/7h1ClaDmv6
MEQaf1O0reAEEZyWlLJkaq45BmtHAI6UTSAj/uCdV1EsIpzgTrHgefhdYAU1xNX83qDf67PZVUx5
hVpjtYXeRdKmTNoDEQOdxuuJxxKJWNzj1egYrRvYvombOBoK7EQbaiIhh13LVJD4FNkWCefQZArW
USMrPwqQ8GWy7dy9DYGgwSxToMOkXGGA+GAjd19rJuuFM0MEs1ohTtIT9HcIMT4XRQxCvCP3EDVJ
1p5B95/kvs6d+CbW5AvqZVIIQdUVavLcQ9QHJ7+JFtHCSW7zGbC1/MBY94n64Ez+KgICMKLSTibM
vMRea0wuAKXEZiXAr21gggJosTLwsYAL4YZKW6IQgOLjpbgmpBRv3mBhl7xMTfEBHfW74ADCZNaY
7c5AMJ6qWegfjCd0BqTVQFQ02VgpV5RXiMVgsgYDzc3r22prggGdDp9Cd3X3W1iLw+Z2+f2sVX3C
EAjG/PGIT6/XMTqTmXsejjHhqMkTdLr1xspKMPe1TblM0GfQdU8ODDWPhyPgbbHWeDQPpzZWM5zp
V5RXV+k1RoPOUK2ukJnBU2trG+xtgk3I52WN0JPT7XLXZ/kjXexP2R2wS3Sk04Gg3WHLxOJROAIM
T0xvuypw7LKVTWm9AcLU0ptkYOB02cwmtaqiHMkUfNg3X1PrN+DQvcsePXdq5rI9K5Gu3plUCCzt
ajV8hAAB3mrQ8SfBE24GjAeIHlh0sng64XEAXnnwOpKwcpDwcZEae1fFMzFAesnjXduOL95ym9HM
7AsrY+MRMCex3/Q4OE1wLkxHxkf3/nDb1HOVlVZbONrckkw53diTd8PnEvnGaJS1VleRdu6/33IL
fDOwzWA0a7RVSrpMy0C43umhf8etN8NaGjXzsKkeOcb9y54hOFE26OAcIjUy/rV9A4PhqArGkoyP
wNcR6CQ3Qb0A84Ovb4pRAbDLT5IO7gRa5CYke49+eh9EspACasWEWpgSICMF1DgBNSeOircc/d9H
AevYascxYjucUsE+V9qJHPBCSfUFPcckiRMG7AXR4NSaUwqxCSEIQl/nD7R3bN6ynfOiU3s3bsg3
OmxVSpsjlmgZa24KBXQa7n/29N353q+GcjmnU1k1VDwbHDiHyrsa6yMhiBvun+voDEXUjKhNpXb7
6hvHcrEEfLNjlUtNZn8okyO9OyIhbit8ZYE/yomvPgw+mcWokHN2WbnZFIHPqbA9Drn77P94Y0tl
3Z/wB1oX/50/C57mT0FGCDOH8AfviE+vAl3Q4GWd30b/lG+p9BT/tsPXTfgLp+sgPwn5Rsi3Qj4I
+UXhF99fgrwZvsbqh18G8hHIv4c8Dfk5yDdAxvcIyHshPwwZ38fX90PuFX7vgDY+gfJtkPdDnhXu
Xwa/zcVnaCuUVyAfh/wqZNw2HtMH8Bz6Pn8Wyh9DdkLugozbvx3yAcjQH4Kvxvj53AW/uN02yE9A
xvWvg4z7fAMyHiPuB+cAZJgnOglZAWXAEpwifBvFUDuaQi+gP5ND5IPkk+Q75PtUhtpP/YhuoO8Q
IdFe0WnR78R7xc9D+gfxhxKHpE8yKXm2zFW2UHak7BNpVtornZbukz4tfbP8REW04t6Kpyteqfhv
FX+UVcjssqzsmOxTuVR+m0KruELxgOJdxR8rN1f+qPKfq7qqNlXtUQ4qX1a+o/x19SiMBmOgHXxN
8J+FK75wwX8mNL62vpuJF4UyIipRvVAmCQnaJJQpwoC+JZRpqPOPQllEyMhibwAeQkEGhPsS4ioq
KpTLCDX1rlCWEgq6TChXECYaf/OE/2REmMZoxH9y4lrRWaGsIALid2AWiAZ/mXgecrGMCAsyC2WS
UKA+oUwRSVQQyjTUeUYoiwgd+rVQFhMmUi6UJcQfSRxfxe2XEV7qUaEsJUzUb4VyBZGltUJZRmyk
F4SynODos0JZQYyLvwan3YvEHuJKYgmiX9uJOdh1WeI05DhYXVE4uWeJYaJAzMBvJzEFT4NQ6iIW
4FuGMJTyxC5I7AVvL/NXBWIZ3loiLuffxTV74a1mYK1heGcUygNEP9ydh3ostMtCy0vwOwP1d8Pv
ErET7i0Ss/D/v98/0bK458ql+e1zK+xpFramDDtcmGE7p1aCbNfCdJjN79rF8o+X2aXCcmHp8sJM
mO3tam4bzo92DfSz88vsFLuyNDVT2D21tJNdnP3i+wQMep7Yxk8ET30eBrQAA+rjfxfh8fy2wtLU
yvziAtu3uAA38FC3E3tBJHgKxHBh+95dU1DIwzSn4dkCP8ElaCME+Stazy9PFxZmCktsiL2ko694
9ZL64/wkltemEIPVw6tLjBeWlvH4Y+EoXH1Zs18y2+Jkv6zy/++KYiRhEWJcrPBjLmJvnhf8GIx6
hMfdIAgYP1+A/zF+sGBZwNWlGBoADM1Ce1j8n9fEV0vw7hQ8wUu6COU5/h5L7IAFxNqwDG3i90oL
vww9X7jkX4EegNz2+eWVwhJAcn6BHQuPhNnBqZXCwgo7tTDDjq7BbmB2dn66wN+cLiytTEHlxZU5
WPcde5fml2fmpzHAlqHvS1GElXcJ1Bf//zlCiTXktCwu7VksIpQAyWGJYY3EEMbV8fUyD2ZiZKVw
eYHtm1pZKSwvLhA8EaxAyzVEBNI+PoXhpS/ieFroPwxiWgTFjcCLKyt7aiKRffv2hacEAE/DKMLT
i7vxU77X/3yzK8BQe2C0mB8wirfDquEVxGuC29wNKvcfdr1y5Z7CTGF5fvsCAD48t7Ib6o/B61gY
RZrBACjS0ZcDe5YXFIYbFtksdLoP5IHhWgL9MgBnG8CnwIMGU9oiPCsCi4UBFkG4IPQ6BZPAb2PC
KwF5Lw9kPDEWWsfjmYb/WZj8IrSN4TsNqQCiwEuHIV9q/T87ZoDT2HIBU97KHAD5AsKYXQSELi/O
ruybWipgilzeu21HYXqFXVmEugV2F4B1AV6d2r5UKOzGcN7Ls9S+ufnpOfbKxb3s1PR0Yc8KwB5X
//dahgH8v4IBS/JiVv6/hMGuNcYWMEAQ/werrqi8CmVuZHN0cmVhbQplbmRvYmoKMjg5IDAgb2Jq
CjgzMTkKZW5kb2JqCjEyIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UeXBlMCAvRW5j
b2RpbmcgL0lkZW50aXR5LUggL0Rlc2NlbmRhbnRGb250cyBbMjkwIDAgUl0KL0Jhc2VGb250IC9G
RU9TTEsrQml0c3RyZWFtVmVyYVNhbnMtUm9tYW4gL1RvVW5pY29kZSAyOTEgMCBSID4+CmVuZG9i
agoyOTEgMCBvYmoKPDwgL0xlbmd0aCAyOTIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0
cmVhbQp4AV2QzWrEMAyE734KHbeHxbs9h0DZUsihPzTtA3jtSTA0slGcQ96+slu2UIEPHvkbjWwv
w+PAsZB9k+RHFJoiB8GaNvGgK+bI5nxPIfrye2uaX1w2VuFxXwuWgadEXWeI7Lsia5GdDg8hXXFX
tVcJkMgzHT4vY1PGLecvLOBCJ9P3FDCp3bPLL24B2YYeh6D9WPajUn8vPvYM0kRKnH8i+RSwZuch
jmeY7qTVd09avQGHf+2q1PS3aX4T0UFtxZahekfG7RdyytWnnW9mimSzCmVuZHN0cmVhbQplbmRv
YmoKMjkyIDAgb2JqCjIwOAplbmRvYmoKMjkwIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBl
IC9DSURGb250VHlwZTIgL0Jhc2VGb250IC9GRU9TTEsrQml0c3RyZWFtVmVyYVNhbnMtUm9tYW4K
L0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lzdHJ5IChBZG9iZSkgL09yZGVyaW5nIChJZGVudGl0eSkg
L1N1cHBsZW1lbnQgMCA+PgovVyAyOTMgMCBSIC9EVyAxMDAwIC9Gb250RGVzY3JpcHRvciAyOTQg
MCBSID4+CmVuZG9iagoyOTMgMCBvYmoKWyAxIFsgNjExIDYzNCAyNzggNTIxIDMxOCA2MzUgNjEy
IDU1MCA2MzQgOTc0IDYxNSA2MzQgMzkyIDQxMSA2MzUgNjEzIDM1MgoyNzggNjM1IDI5NSA2MzUg
Nzg3IDc0OCA2MzUgNjg0IDYzNiA1NzkgNjMyIDY4NSA4NjMgNTU3IDMxOCA1OTIgODE4IDQ2MCA3
MzIKMzE4IDY5NSA3ODcgMjk1IDc3MCA3NTIgNjk4IDYxMSA2MDMgMzkwIDU3NSA2MzYgNjM2IDM5
MCAzNjEgNTkyIDY4NiA2MzYgNjM2CjM5MCAzOTAgMzM3IDMzNyA1OTIgNTE4IDUxOCA2MzYgMjc4
IDI3NSA2MzYgNjM2IDYzNiA1MjUgNzc1IDk4OSA2MzYgNjM1IDY4NAo4MzggODM4IF0gXQplbmRv
YmoKMjk0IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0ZFT1NMSytC
aXRzdHJlYW1WZXJhU2Fucy1Sb21hbiAvRmxhZ3MKMzIgL0ZvbnRCQm94IFstNTIgLTIwOCA5NTYg
NzYwXSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDkyOCAvRGVzY2VudCAtMjM2IC9DYXBIZWlnaHQK
ODI1IC9TdGVtViAwIC9YSGVpZ2h0IDYxOSAvQXZnV2lkdGggNTA3IC9NYXhXaWR0aCAxMzA4IC9G
b250RmlsZTIgMjk1IDAgUgo+PgplbmRvYmoKMjk1IDAgb2JqCjw8IC9MZW5ndGggMjk2IDAgUiAv
TGVuZ3RoMSAxNDQ3MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1e3tclHW+//f7
zAXF4wUB6bK9fAARTQKViFXXCwLKIAw4M4B4g2EuMAoMzgwiWeIlRdMy81ImmWuuxxdbrtvtoNXu
aa281tkszx5za496zG23Lbezuz9D5vH3/nyf53FAO9Uf5ww+w/N8L5/L+3P9PhTjjLF+bCUzMFZi
zxj/StXfXBjZhKu8tr7Ve/WBgTNx/1+MJSyr8zjd3hKLm7E75mPsgToMDFrWLxfP2/A8oq4htMzb
f9TbeO5ijN9f73c5rxz6i4+xO7/AfEeDc1kTm82mM3bXejzLjc4Gz7k3jr+K5wOM3fMHxo2D+BPM
xIymmcbTjCnT1d+SnW2WvP0kaYDZYOhnlCTjSsZ+MYTJhaAiPtN9oSCbxuTrkjlOiePPRDXwS5gg
3egjMa+yw+g17YOWUYzFxiTGpCTGJHqNrCdouLvnsrIjatC1rwPm0Yzf6GbM+LnpLK0zJMYnxiTH
JJqNX4W/PBX+0nS2s/usaQzRPYJVbnMcS8ADloxMHZlsjjLH4zYz5oHsB7KHJQwzurv45CkP7Sgr
P3x4+tw5S99yuaR94fnS7t2lJXxh9fPhdnNceLc7cxznS5eRjG+BVitoqjJmEq345Le68DFWX99j
jvscfP03LhqOGZezTKyNB9fUJHA1JwxLwL9h8XFR5tQkDGbhIXN89gNZtAL/RmaPhEzjE4YZNlod
jrmP5ubz8WO3T33bblv+8O/mOmvqva6amlUzZ/BxmT+f9vOiYs6XNL3vnVtpnHpwVFwsv/deR07y
SHnQvUXW9R3z5vOhQ0b86oE7775vjK1wdOrIwSNmWdY8W1HGBw8mLZbcuGicCy3i2AjCBmpkARkS
K2ZI9gOZEILHadLdD9Qgv2FvV9ekisqHTrWtXNl26qHKivBxh23rljKHo2zLVpvD8Jq08JsvDngy
xvO9e3k/3m/v3rHjlWGngqFQ8NTJ5mCwWePaDFwGs+HgSqBoTLIJAjCNlSCEWRVCCm4vKy8v2761
vIzzsvKtVzes53z9hqtft2/Y0G74QzB04gQRP3GsOfhsR4fyhfKXjt2c7+7gsTyuowNWaLpxyXAF
3BI1KwjbE8NhgDke6iaTulL2A4kwhOGK1Vpa8rILn5dLSq3WYpt9gbJtO396O48qm11qzHrh3oR4
3hR47/2mAE+IS+scMXToc8/xQTxm97N8SCxYsBdvXDLOMVaTt8UCUV01HVzidrBryuSHt80p411d
eRWVzb9xefgRaX/Y+VxJadXCn0nLr+95wTtu/LJlqu9G3QPp7wVpzVcT4GxkDc2HcZuqu3M8lmSS
O4/Or65a84uqhfzwhAnNT9jshydMXPo4fh2eUlnxYGtFmWHDQ5Mmct66/CI5+Z4Sq+rk0u691iKu
3hurD3rHj0NUwGJN8JM2SHEXSyYUCalsuKyAL1VOHRkLbyGXjYIByUuijG09Lw2o8/6Lz+Oqcdf6
Fin/vWs3376t5+Ijq/9FstnX75q3cKC0cO6vazz8rjuzDt47LIF3dPBoPvT5PXzLk28/NXduxZxn
CU0Ru+D8LbFLyv6w2IUqeuhylg3H/9q0m8WDfAwlDbIQghd2yYL/Z8bwFr5cWTtyROjNN8/Ont3e
btqt/GZzeM+G1NRnSkvOSNWb+RRNMkMhJCM65Le32iDBUCgnjxzzrM1x+PDEBfPXxSYMu8fwytD+
UZy7vb8Kv6Thy41GisQjQHgfInGwiEQNRj0uyPIUjDFD4K2Ii9R4pBvDZW4TMSfizxbePLFyzvLT
K9vaVp5ePqdy4uHDUoYIuJMi+CSba/zYvXuVa8o1BOb4DM8BMAPfB8H3PmgxkGVADy0Ws4cB2axs
LRuAYRZSUmYiZSjyuqgsTR7pV/9ZVp4zzb9zwTy48tSFVe0vur185YrrXOI2x1PV8+bb3dUL5/33
smVSZmbm8poJkzhvrH9ldFF4Vad37HjOa6r3vlldPXTFzHw+LCG9MzUudsUKwhaySNcgIGELyyBD
xKvpHfbJuh+ySNcOuVNSeYbyweFDhyoq3jTH7Rw1uta1uSfD8MFm6+vlZUQlkqNZLFIbsrM57hsU
N+Q9pdw4F1oPZvdjoR5BWqgmAOVEeEMkM4ukCBj0pJiQlWnYa3Ns2z7bbp+9fZvD1tW2UrleU1Y+
u7TUan917tyJcyofen8FPu8/VDlnYpc0+Zi/gfMG/7HjDY2NDX9SLjy6afDA4S+nxcdXLfz1PNc4
QIGMZeSG3c+OG1/Ticq2Q/HyrahsA5FFMoXdoTpViRMnvXUXi6eu/XG26Wz3VuWvrQ92zpr1G2jb
DkvuNV29WW0EbFBJVJsEVJuUPjqR0vg3UsAJ3zIWhDy1C/fPmfuTif/84MX6RXzLVuWPi5e2tj3Y
sjTwQtXC3Lxnll9yezZt/HtdY4Np3zvZd989LafZPS5z+J1pixtf/di/hN9xR8ZvZyQl5+W2NUyd
LN9xX3X1z98NBGKFnwVvXDSdg3RqzocTxUoIOygUK0EKWc35KUglhLEh9ZOVazhfs/KT369q47xt
1e/5hDdf5/z1N5Vjytuvv/nm66Yi/vw+5bJy+fl9+57nd/O79z3/szMfKc8pz535iJ85w2u486Mz
5AMnGDNlAsf+wDGRKhy+kk/wIdKOt5Wr4UVvm85eH2680D3GeOE6ihHiEJ6xD54hKmKKKOu3BB8F
u44tKcCDiO/eoSf9uE9gHggfNEd39o0+/kWv0ATXIZCyDlJKLBpC80SeyZMNiYZk6Q3lSylFWX5Z
mnBmfbhq/VnToPCdhoPdY3ibsgra7UBnUwhUUb1TECAUl+JHE1ENVCRrajboh2+Q3uopChx/N9OZ
msIh5toq3+KW1sW+yj8++mhS8ry71q7r7OxcevLYpPriwsKlRbMSE3NPj73rTh5sfmu+zd50z6Ob
wJVycgeiE7LCNyErTwaoRw5LKX8OH5QWXw0fO2yO6/HxS+G/hV+QksOfqHYwboSGA8gOSLradcJw
KHyXdCw8QbrWMwUtmzKjM3wJ/s8mA5FJ2nowEDzAZtU5HuTN5xRZYueU+Urlx1K86Wz4rDQmnNlz
TVoeXmu4R7O6eTh2/5OwOqfGUMh4gt/HH+Zt/L53lLZTShus39PPcK17jGl4DzOy7gvaXuMi7DUJ
7SDniZPS73qqEG1nO2n+PL4OMoV68GyUjfMffqgoND5ZKUONrGYxkBxQp6rxmp1NsmdKW0sshQ9t
rS+6997MRGXSUb6QLzxad3zyFP7MiBHrHEZrzzZDPVEpZ8ycBSokeWas+AdXMCSXd312+dxnl7uU
8+f++vU5Y3XPDsMiuq7vMezoWUSe+46hU6JeWHSk1OcKrf2d0ohODSLABA6/vHHJNBrrkFthPSQI
yvZZiAxKe1TLXzpVUXH0rTkVp554Urmi/NfmJzlgar7qW8z5Yt9Vw8ae+cr5bdu3b+MpoLb7xlB+
FGgALaBhSI69+uG+VTblBeVf+TSSiuLPAW4JLAnqwRUTYpMN5J7JJKERrkluGUOBRN1fsuGxaVMn
T3nv3K8L82e2/P4kP87ZihV8Wm74UWVLkYVzS9EW6Y2EmQUrlDretn38uPAG01m+aPF/PLZggVQS
/jIvd83qvOngG1SuaflmJPiCR+98E8uTU8lERjXdJGrp57a0M5VH/+2TpCFDh6hJh/9ETUO1vm9J
P92/VT75SkLh4x+d4U5KPyIfXe86DJSAgsjm8BmqRCdOnoQ74WwCfG7cMB0CPtFqP5IpqxkxMUUI
BZOkJPKtf+NZTzzO+eNPKKeU6fw5/svTJ/np00qp4jRlXG/ZtJFn8LRNG/e/8pqySlnx6mtc5RiJ
H7gCnVDgEPDlT0+eDCeBf7hDcnePodgjv6P8nIpMonfJqbIKWQoZRnTJOliwoSnVGwytVm60b+B8
Qzvnq0NB7+LmlkeUF4/iw+1rly011ZxdODadd+xWzin/gd4vI736w4IRI/gH/8ZreS2+k+A9N3qQ
Sa5A+344v4koh5TGc3w333UufPUUZHxG8vZ8jexwTPMl42MCK9ENigaefCaF+tEEGJScim9VHitG
D1tU/JjyY368ezUVkNXdyklTRvjfeKGlfW2hZT86+POfNi0JH4Dmh5SvpTnIZlGwTSI1VvGJh/iB
q1cVDG7+pmczoQP7GZPBWVQRLXslnzDMDTdJpeFDALNTKegMZ2MlUohxrpCRZSfGmLJSUHHiExVe
qOzknpO8sGdfpzFY0FVAyURiK1Gz24G6zMYifugkSG11LPmmWeu64Jsxklq8OeayqPPX2rQLRVbr
rGOLfYMnzams/8/Va2CLS9yA89H+A8rl4mIrn7K+tKSkdP0GK9qS4V0jYuN4+1oeW56eAbOt++Ly
po3vHlfaRckcPFh6asGCvXuqFiyo2rN3wQJocgy4+FVc0CejL07OkvzKnK++Msdd+3Sz2bgZa9z8
D1KbtIZyIWV1t3R3+LK0Zh9mkL9FNjSTx1P+Tp6sJj1lfjeyl8PwwvU9MDr5v/ELgdcwNhpQxyTq
SkZuUxNTE9GhUA8TBYjEyRlRwfP24oRWuld5g4/ZWlhQULhVOXtSMl55+CE+LWc5urL1G7rDf5RO
hD/Jm75pY950yatM+XF2oGlCNt9fXf3LDbNtsYnu2qfQknGyMd5qGKkGk8SJ8SgXiQcM/xq++CFX
wmggyrtX4WWCgT2K091G0ceMxTsMkVn0Lj0bpkmBP2ajQc3W5NTlpdOFONcbcP4XfZzWdEobcTqz
2554wm7jNrvyszUzC/nKtk8/XdlWULhyi332I+v+cW3NOs7tticLeWHBmtWFFkvh6jUFhdI7cPH2
9UXF1qL29uKiiuFz56x6yVfLea3vpVVz5g5PrnE//jGdjD9+3F2TzKc2T8vJmdYcnD6N82nTSV/y
++XmoVSvKD+SFgnJEJ8awmxpefu0nOnT1u15yjKr0PK0eehnFy5cuXLx0uU/X7p44dNLF9FFc7ZP
eIigEEunTgrBqGTqQEBm354dsyhfz9qxZ63K1Dz0i4uXPr1w8dKfL1+6eOXKBYSKxK6C0FFjMpBF
/FE9pfcoVz/ER1GMyQq4sBvTpZdgF/gYuZHUrzN8DRXtmwbMTYLNWo3V1FVw6kLoH7zN6FYW885z
yhHlyDn+shI4x0fz0cbq8B/Cb/EupUAqlIYpSzgiW2IHDZ8bGkDdJGgkZ8VmGkzim6+iQsafoW/D
5y/yqcpbL4rv23eJupcivjmL7DKdFVXwhZu1cB2ifbPwHe29B9Ukqr4xQ9ADa+c7CvxYvI2QNnZY
SzkvtXZ0kJd3dK975JF13dcfgS+se8RUunOX8p5y+uldnO96mt/PM3ft3COCuf3d45wff5e38tbj
7zLpxnmlXLynGkh2pnpPWTJLpE71jdVs+yszxvlGpuAAhzdXm35XVd2B9007zaPoDRZ6Cu7XsEdq
5n4AT90WYeAG9vswJ9EZBT2rIZMIUpnJMpgViStZytmzJ8ILTSk9lwzv9WQeUPbw6qO0czNw2KHF
EOt95qTkJt6UUYYzwJHo0CvCXS8+eJb2iXy2QeQ23r+4yFp03Ld40MS5c+ovrFm9fsMFpWf9hgP/
zH+ECcMkJLWfLqjivGrBT5HWpNau5LjY9nblq4qM9PUb/vzZxk0aWqjXeCVG/cxFoxtapYgskEjv
B4VrA7dEWEY9E8JkolmBlFGfGO4M7xlz35j7up/cwnfsUL6qqnbVzq2uXvyC100n/RdsJbPRAHUq
Tw7uF4UXV3/6GiaMGSKfGp9wB58/r2PX/HlDY6mTmoN0eB6+rNYYjnSaxROXGBaFi6RXeh6WXgl7
jNUHes5vPWCg1VSvKQ9BzhQgnhhDNaMXSgn0wjEZRTxmSMKwRAhsPKq8Jg1tfuyxPcpP33733bd5
1Za1q5uWPLxio/KX9Y8+up7HLiqzn+Vb9ofb7Pemcf7+ad7AG94/PWLEjN8tHDd2507lA+XMzp08
bii45zEWtR8oiS5VhBwiE9GXd5pP5BMu0dd7ygZFeUf5jYIT1lDjl3Shzx7STQHPOoByENLT6Zsy
JYRP0dGlCijehWoHXq3g3TzLUJYxTH3CPps/9bTyx6oaj8/ucTW+6XHxeQt+dvC1baUls+1PORZW
BYIed+VlFDw+o8CQIjtrnvik9UHO42JGHh1/x1181qzNjyBB7f/JxCXBKZNhgleGxwyh5Pmwoxw+
GnlDgLPVrS9BKV/2fkmK9wFoPDLEixjtRagU7POWdFJXl5TR6y1o+Bd9X5G6Or/5B3DRz4GoQYni
3MClwvC7H/Jz/OMz4WNAMsH4OfWNnJ1jC03njfupWiHzxfMsbjp//ZqxX7dikgxXlS3K1tf4B/v5
B7esjc0Sa8+ZpG7FaDZcfU3J2K9kvMYbaJ24/l/arLuqBv/k7/SHhls/eCtRFrUfPQEnvtoH+6Ia
FBy7opfeqLlRE7VfUNJn6Xex8T3mNV660W0ayo5IE9hbxjHML23EySCOLTFexuVlSzB3MOoUO2L8
QtwfMSSzbEMhO4I1R4xX2HLpA5ZBe2mPNP/GDvxuNxexoKmHnaA1plY2xJTAdhj34n4QxpazyeYr
7ISxmZ0Ar/PGN/C8kZUbDrJ3TOfZSxjbbdrMThANaT5+j8ZlxL4dLAhZe4wfshOG4eyQ8RmMJbAL
uFbh+Zh0ibmJlulhMX4A4xtpHa590kvsKi6G+UnGFHaQLsy3SxNunJcywTeBuXFtxrXbmMnmmDNZ
MOpzlofnDtKLdDC/ws7RBdzi2ShmQ559FT9XeSqv4uv4CcksZUh26UHpNQM3jDCMM6w27DL8yTjS
OAWVcLvxt8Y/mSRTommqqcQ0z7TCtMv0C9O/mz4zJ5l95qXmveYj5r9H/VNUdpQlamFUc9TRqLNR
F6P+0W9SP2u/l/t91O8f/aP6x/d/oP/s/vX99/d/p/+H/a9GT4leHv1k9AfRfx0wfcDDA54ccGDA
G8LCxSyHajI+5Dm3fobxQTfHJ2JSXcNZLJuo3UuouVXavaHXuLHXvQkZxq2tMeMMWazdR6FfflG7
78cG9avX7gewO/qv0e4H9o9lTZCQG5FRWaj/Lu2es5HRg7V7vG+JrtTuDb3Gjb3uTeyOaJe2xszS
o7O0+yhWHf137b4f+9FdQe1+ABv7o59q9wOHjoxenutvag34autC8ijXaHn82LGZck2rTH8FCwU8
zoY02dLoSpdz6utlG60KyjZP0BNY6nGn31wjl3sCTtnubAzeHKIRGrjP5m9wNto89R5n0COPSx83
9gfxGxj9bQwHRt+kr7L0BWWnHAo43Z4GZ2Cx7PfeKvfA6IHRpZ5Agy8Y9PkbZayv8wQ80K824GwM
edxpsjfg8dBGV50zUOtJk0N+2dnYKjd5AkFs8NeEnL5GX2Mt+LgAFK0M1Xlkr78RSDhdLn9DE5bT
glAdqNf7XJ5GKDoqaQatSBoNYm7ZGQz6XT4n+Mluv6u5wdMYcoZIHq+v3hOURxFFsUG2+72hFmfA
kzRaSBLwNAX87maXR5Bx+2ASX01zyCNkIA43N6TJvkZXfbObJGnxher8zSEI0+DTGBEHYeQgKdgc
hKKkTprc4BFaNzXX1PuCdWlyhEca8czwB+SgB7bHah9E1dS/hTXpCLLADAw16ASjljp/w+2ykhm8
zYFGMAQi2Oj2y0F/mhxsrlnkcYVoRMW4vt7fQgq5/I1uHwEWnEgGdUAZZ41/qUfooPquEOGmIzT6
QzAEDESCkV2EaKoPqHNysM4JtWo8Gm4QxNco01BEU38jPCMgN/gDwkNIpj6Ky6HWJo/XCUbpulh9
5xucrcShwe/2eX3kbM76ENwPNyDrdLuF9gJnYt7kDEDq5npnQKjv9gR9tY0CcvzxvKkOdwHhpU4X
iARphy5RUL6Fk+p1bhU0Z738rQS0PbocEWoQr7G+Vfb1cXVgEPDQX9mFxegmKANKso0eIh74nUcV
vsUfcAflpJvhmkTCk7g0ISdRdkjSQIN1irSoqfEgnohuM+xAtlvq9wl2tNOzLIS4kZ1NTQgy/J0Z
QeAX9hDA9AU+VOcMyXXOIND3NN7EX5AEu4iPu+XmRrcmckRYkVuSxH9S8D2WDfrrKbqF6Sg2nDKs
VwuCQS2OMeNa7Kz1yIhawCUclhb+cNfSTStYIXEhL3vqvSp2BfnyjBKrQ7aXzHBU5NjyZYtdLrWV
lFvy8vPkpBw7npPS5AqLo6CkzCFjhS3H6qiUS2bIOdZKeZbFmpcm588pteXb7XKJTbYUlxZZ8jFm
seYWleVZrDPl6dhnLXHIRZZiiwNEHSViq0bKko99M+TifFtuASjnTLcUWRyVafIMi8NKNGeAaI5c
mmNzWHLLinJscmmZrbTEng8aeSBrtVhn2MAlvzgfSoBQbklppc0ys8CRhk0ODKbJDltOXn5xjm1W
GklY4ijIt8liSTqkBA05v5w22wtyiork6RaH3WHLzymmtVgqz7SWFBNGZda8HIelxCpPz4cqOdOL
aBCyAYXcohxLcZqcl1OcM5PU0ZnQMk2dCBy0YWa+Nd+WU5Qm20vzcy10AxwttvxcSIuVwB5IYBSU
ckus9vzZZRjAOp0FDFKQL/SAAjn4lyskE+pboS7RcZTYAIgmSoXFnp8m59gsdrLIDFsJxCV7Ygfp
WAY8sdRi1eQlG9EYzfX1Dqyi3RqKefk5RSAIJ7Hevlb4V/4yl6cJERfUg1xNkiKhqlkURQqRqSYD
ePXMRoSvOiZuEZ6IL1Hq1Cx3Mx+IpgIZXyRhSiNIk6hKahJ2L/UgEwYp8yNr+CmptPhQVKnEBPwN
fq3+BZ31YIZdN1fJbo+zHtu05IhQ75sW9MLYFPCBcEvAF0JKkZ3NKJcB34NaSQYHodWtGhCXW+UP
eIJNqFi+pZ761nQwC1BdI3mRnb3+QIOmusiRrtBEvW0IybWEFOpeCFRr0+tCoaaJGRktLS3pNXrf
lY5UyHKZH01iKwswH6tldSzEZDTdLryKlNl4NJlj8edUmdVghYz/FMqH+SCuAPMwJ2tgaRi1sEas
T8ddDqvHj4yWXacVFE8e7PFgz1J8u7Hydjoy/uxDK5xYb8d3I3bcvkpfo6+4D5z8kILW27C/HpdT
8JLZOPAZB+n/9/QbiD9R/FANae3t8vfW0gc5ZaEvoekELh6hSYAtxrifefF9O4XeeBMPukoFcg3A
PIgfH/Y2Yq9Kv07MeTT71QpOjbAf2YFoeTHiwY/O0QUPcGKsFmM0HwI1krJR2L8JowHwUDn4QTWE
OR9m6aoVK2X4gupROs0QaBIHr9hH/kMUXWJdA3xPpa5ToNWq7PX47cJO8gXaPwp/QJtxk0aS8FDa
6xb0SHc/1vtAT9VPxgyNNANXokKyhjCvSu/FHfkLSTMK46qMEQ7kh2SFEGvBPkKJOEYwoZEmjPvB
pVnIqeJE0rhBW40SHzBqBg2SX+eh63A7B6JOOLggWbOgoqLaglHa7Re0ZMz6oBON9dZIpx+JZNJN
tWCzwJDo69ahe8IlYusmUK8RtIPgRfPfpgeNq6hnQJ4Ansg6atyrtH14Js6qD+tSfbfWuh1VaVU/
UzWUgXLE6yIatQg8GsDn+zno0eCFhgHgS9Yhe5OtVI7kKaSJX+gdFEgswgoX5vU1Oh/yY9LXD8/Q
vZY0J08km6geFsQxX49Qh+BGuNVgHWXBiB0i1tJxJX63Z4RG7CTaFBGEQgQxPV4iqPXOA733kYYU
36q1aoQcvf1NRYRGiP7/bFPSlXRQ7d8gfqvPlLV0nP5ni9OaVmFXL/ioGqXfhtZ37aecTxVJ1YEk
IOwppvXMRvJT3FGcqrlOlZYyLeVa3fYRf1Zjj/yN4l3FuhlU6CmiFe2lLFsLDCJeXot1pFGdNkY7
9FxKGqqS0HoV3Vsxopnv1ilicVWDiKeRpjLk+aES9OVzKx4RTXX8gyImyObEgTTobWWKBsqtqk8S
2rLAvBG4UX7RcZaxSh2hlapXqlGgZmbChS6qIh7cqQj1Rr5F+JlbcEr6ltqYhJ2qjXV09R0ycrfe
OyShL+gdl2qtKQLH3rWG/IpimjRQ5SVPIJz1uFuKWV8v7XSeHrZMWJu0otVN+FErGUU/VRxCmLJN
BF9dbn3k9sqgWoWyvSwimGQiGamukef09f+IlKp235bHyS7N2E3+3Bvlb0M20rcQxhE79kWSNPsu
Dfr6HeXaeoEfdWyRqNPrBnWCauxRL0IS0o7e9Vjd40K/5ITXEHe11qreFcmwOsX/i6x1a9RGtFI7
ZvJjtT56+/hdAcuHvDNYCbMyB+7suJuBuwp0mDYxZ8GYjN7Ohply9Nh5GM3DSBJW0AzNJ4nIrMC9
gxVgXZmgpdKwYR3RrsRaok3duVU8zcJ6K2hR5svHH92IRz6oEdUS3BPtYowW4TfxpHW0IxcjZXim
+5kYm67xs2IX6UDri3E5NEkdGI9w7SsVUVb5kWTFeLKBfoEmcw5oWwQ9kp/4zxB0rWIX7SPkSNIc
XKX4toGrBRTKsIueaLQMv0uxzo5dqhyEH0lrxVoraNjE75mYJwlUS6hY5WJVKXjTipmQyyGkIE6k
Ha0kqRyYzwEitJ+4zhKjqmSECVmZZIlQoVMS8VblIPzLNXrkA6R/EX4IW8LRLjjkY7QYYypdlaoM
qUgTkltFowzPeVhJOJCGRIPmyCqEZ9HNlSpuqi+QTXOwolhITvtJE0Ik4g29NdGp9bXOt3mH7m1E
i+xGSBUJLnYgmw9bkVzqCO0nvyI/zIUGEY9T/Z7w1teqKJB9rMKys2Fn1SIqPVmgENGCaFUIS0Ts
oVqAJCS/II46ZhHrE0+SWZeHvJm8TLdDBBWKP/Ix4kReQE/EgWKEfIysRHN6fKo8dDuWib06VdrX
1/vJyyiO9HX6vu/KHSpGOm+iHdGdvJWwVCUkK6tofD/dSLbPR42jatmk1bggqKgdsH4eVOt+pNdR
61DvXpQQ0WtmpKLouXomqoxafXuvi4wSsnQaovoVOQPRWr0+3352Jk3VNxW0rncnrHcjajepnpWo
PqryU4dEPbvaE1Lvp3Ypaq9BXbl6yqbTgHpS1U8xdDqk2tz3/BeEjNQHkBQqL73+R2jR2YveZVDn
QNwIYVUa4qai+V219tYTI51U6VwSAJ0WcR8SUjXi2QkpiCrN+tiDeNbPMOr7AdIhYqvvs4Guy/fh
T51iEB6knrF8AmHqL9PBizQjSdXzmo6vioBXzFEvoUtJOEa8j3rtiWJv776U+ibq2FWfUt8M0Bjx
qQVPeu8VgjQT8T9eZAAh+klHP6HW78j7rnStK/z/9cFNcgplbmRzdHJlYW0KZW5kb2JqCjI5NiAw
IG9iago4NDI1CmVuZG9iagoyOTcgMCBvYmoKKEFsdGVybmF0ZSBFbmNvZGluZyBmb3IgT0F1dGgg
MiBUb2tlbiBSZXNwb25zZXMpCmVuZG9iagoyOTggMCBvYmoKKE1hYyBPUyBYIDEwLjcuMyBRdWFy
dHogUERGQ29udGV4dCkKZW5kb2JqCjI5OSAwIG9iagooRDoyMDEyMDIyOTIzNTMxMlowMCcwMCcp
CmVuZG9iagoxIDAgb2JqCjw8IC9UaXRsZSAyOTcgMCBSIC9Qcm9kdWNlciAyOTggMCBSIC9DcmVh
dGlvbkRhdGUgMjk5IDAgUiAvTW9kRGF0ZSAyOTkgMCBSCj4+CmVuZG9iagp4cmVmCjAgMzAwCjAw
MDAwMDAwMDAgNjU1MzUgZiAKMDAwMDE5MTA3MiAwMDAwMCBuIAowMDAwMTMyODgzIDAwMDAwIG4g
CjAwMDAwMTUwNjggMDAwMDAgbiAKMDAwMDExOTkzMCAwMDAwMCBuIAowMDAwMDAwMDIyIDAwMDAw
IG4gCjAwMDAwMTUwNDcgMDAwMDAgbiAKMDAwMDAxNTE4NyAwMDAwMCBuIAowMDAwMDE4MzU0IDAw
MDAwIG4gCjAwMDAxNDI1NzkgMDAwMDAgbiAKMDAwMDE2NDQxOSAwMDAwMCBuIAowMDAwMTUyNjA4
IDAwMDAwIG4gCjAwMDAxODExMDIgMDAwMDAgbiAKMDAwMDAxNTM2OSAwMDAwMCBuIAowMDAwMTMy
NzM4IDAwMDAwIG4gCjAwMDAxMzI1OTMgMDAwMDAgbiAKMDAwMDEzMjQ1MCAwMDAwMCBuIAowMDAw
MTMyMzA3IDAwMDAwIG4gCjAwMDAxMzIxNjQgMDAwMDAgbiAKMDAwMDEzMjAyMCAwMDAwMCBuIAow
MDAwMTMxODgwIDAwMDAwIG4gCjAwMDAxMzE3MzggMDAwMDAgbiAKMDAwMDEzMTU5NyAwMDAwMCBu
IAowMDAwMTMxNDU4IDAwMDAwIG4gCjAwMDAxMzEzMTYgMDAwMDAgbiAKMDAwMDEzMTE3OCAwMDAw
MCBuIAowMDAwMDE1NDczIDAwMDAwIG4gCjAwMDAwMTU1MjEgMDAwMDAgbiAKMDAwMDAxNTU3MCAw
MDAwMCBuIAowMDAwMDE1NjE4IDAwMDAwIG4gCjAwMDAwMTgzMzMgMDAwMDAgbiAKMDAwMDAzNjgx
NCAwMDAwMCBuIAowMDAwMDE4MzkwIDAwMDAwIG4gCjAwMDAwMzY3OTIgMDAwMDAgbiAKMDAwMDAz
NjkzNiAwMDAwMCBuIAowMDAwMTU4Njg3IDAwMDAwIG4gCjAwMDAxNzE3MzAgMDAwMDAgbiAKMDAw
MDAzNzEzMCAwMDAwMCBuIAowMDAwMTMxMDM2IDAwMDAwIG4gCjAwMDAxMzA4OTQgMDAwMDAgbiAK
MDAwMDEzMDc1MiAwMDAwMCBuIAowMDAwMTMwNjA3IDAwMDAwIG4gCjAwMDAxMzA0NjQgMDAwMDAg
biAKMDAwMDEzMDMyMCAwMDAwMCBuIAowMDAwMTMwMTc5IDAwMDAwIG4gCjAwMDAxMzAwMzUgMDAw
MDAgbiAKMDAwMDEyOTg5MCAwMDAwMCBuIAowMDAwMTI5NzQ4IDAwMDAwIG4gCjAwMDAxMjk2MDMg
MDAwMDAgbiAKMDAwMDEyOTQ1OSAwMDAwMCBuIAowMDAwMTI5MzE0IDAwMDAwIG4gCjAwMDAxMjkx
NzAgMDAwMDAgbiAKMDAwMDEyOTAyNiAwMDAwMCBuIAowMDAwMTI4ODgyIDAwMDAwIG4gCjAwMDAx
Mjg3MzggMDAwMDAgbiAKMDAwMDEyODU5NCAwMDAwMCBuIAowMDAwMTI4NDUwIDAwMDAwIG4gCjAw
MDAxMjgzMDggMDAwMDAgbiAKMDAwMDEyODE2MyAwMDAwMCBuIAowMDAwMTI4MDE4IDAwMDAwIG4g
CjAwMDAxMjc4NzMgMDAwMDAgbiAKMDAwMDEyNzcyOCAwMDAwMCBuIAowMDAwMDUzNTA2IDAwMDAw
IG4gCjAwMDAwMzczMTggMDAwMDAgbiAKMDAwMDA1MzQ4NCAwMDAwMCBuIAowMDAwMDUzNjI4IDAw
MDAwIG4gCjAwMDAwNTM3OTggMDAwMDAgbiAKMDAwMDEyNzU4NCAwMDAwMCBuIAowMDAwMTI3NDQw
IDAwMDAwIG4gCjAwMDAxMjcyOTkgMDAwMDAgbiAKMDAwMDEyNzE1NSAwMDAwMCBuIAowMDAwMTI3
MDEzIDAwMDAwIG4gCjAwMDAxMjY4NjcgMDAwMDAgbiAKMDAwMDEyNjcyMiAwMDAwMCBuIAowMDAw
MTI2NTc3IDAwMDAwIG4gCjAwMDAxMjY0MzUgMDAwMDAgbiAKMDAwMDA2MzI2NSAwMDAwMCBuIAow
MDAwMDUzODgxIDAwMDAwIG4gCjAwMDAwNjMyNDQgMDAwMDAgbiAKMDAwMDA2MzM4NyAwMDAwMCBu
IAowMDAwMDYzNTQ2IDAwMDAwIG4gCjAwMDAxMjYyOTEgMDAwMDAgbiAKMDAwMDEyNjE0NiAwMDAw
MCBuIAowMDAwMTI2MDAzIDAwMDAwIG4gCjAwMDAwODA3MzYgMDAwMDAgbiAKMDAwMDA2MzU4NyAw
MDAwMCBuIAowMDAwMDgwNzE0IDAwMDAwIG4gCjAwMDAwODA4NTggMDAwMDAgbiAKMDAwMDA4MTAz
MCAwMDAwMCBuIAowMDAwMTI1ODU4IDAwMDAwIG4gCjAwMDAxMjU3MTQgMDAwMDAgbiAKMDAwMDEy
NTU3MCAwMDAwMCBuIAowMDAwMTI1NDI4IDAwMDAwIG4gCjAwMDAxMjUyODMgMDAwMDAgbiAKMDAw
MDEyNTEzOCAwMDAwMCBuIAowMDAwMTI0OTkzIDAwMDAwIG4gCjAwMDAxMjQ4NTAgMDAwMDAgbiAK
MDAwMDEyNDY0NSAwMDAwMCBuIAowMDAwMTI0NDI4IDAwMDAwIG4gCjAwMDAxMjQyMTAgMDAwMDAg
biAKMDAwMDEyNDAzMSAwMDAwMCBuIAowMDAwMTIzODQxIDAwMDAwIG4gCjAwMDAxMjM2NDYgMDAw
MDAgbiAKMDAwMDEyMzQzNyAwMDAwMCBuIAowMDAwMTIzMjMwIDAwMDAwIG4gCjAwMDAxMjMwNDAg
MDAwMDAgbiAKMDAwMDEyMjg0MyAwMDAwMCBuIAowMDAwMTIyNjQzIDAwMDAwIG4gCjAwMDAwOTM4
NzEgMDAwMDAgbiAKMDAwMDA4MTE5MSAwMDAwMCBuIAowMDAwMDkzODQ4IDAwMDAwIG4gCjAwMDAw
OTM5OTcgMDAwMDAgbiAKMDAwMDA5NDE1NyAwMDAwMCBuIAowMDAwMTIyNDk3IDAwMDAwIG4gCjAw
MDAxMjIzNTEgMDAwMDAgbiAKMDAwMDEyMjIwNSAwMDAwMCBuIAowMDAwMTIyMDU4IDAwMDAwIG4g
CjAwMDAxMjE5MTIgMDAwMDAgbiAKMDAwMDEyMTc2NyAwMDAwMCBuIAowMDAwMTIxNjIxIDAwMDAw
IG4gCjAwMDAxMDY0MzMgMDAwMDAgbiAKMDAwMDA5NDIzNCAwMDAwMCBuIAowMDAwMTA2NDEwIDAw
MDAwIG4gCjAwMDAxMDY1NTkgMDAwMDAgbiAKMDAwMDEwNjcxOSAwMDAwMCBuIAowMDAwMTIxNDc2
IDAwMDAwIG4gCjAwMDAxMjEzMzAgMDAwMDAgbiAKMDAwMDExOTUzNSAwMDAwMCBuIAowMDAwMTA2
NzU2IDAwMDAwIG4gCjAwMDAxMTk1MTIgMDAwMDAgbiAKMDAwMDExOTY2MSAwMDAwMCBuIAowMDAw
MTE5ODQ1IDAwMDAwIG4gCjAwMDAxMjExODQgMDAwMDAgbiAKMDAwMDEyMTA0MSAwMDAwMCBuIAow
MDAwMTIwODk4IDAwMDAwIG4gCjAwMDAxMjA3NTEgMDAwMDAgbiAKMDAwMDEyMDYwMyAwMDAwMCBu
IAowMDAwMTIwNDU3IDAwMDAwIG4gCjAwMDAxMjAzMTEgMDAwMDAgbiAKMDAwMDEyMDEzMiAwMDAw
MCBuIAowMDAwMTIwMDY1IDAwMDAwIG4gCjAwMDAxMjAyNDggMDAwMDAgbiAKMDAwMDEyMjc2MSAw
MDAwMCBuIAowMDAwMTIyOTYwIDAwMDAwIG4gCjAwMDAxMjMxNTcgMDAwMDAgbiAKMDAwMDEyMzM0
OCAwMDAwMCBuIAowMDAwMTIzNTU1IDAwMDAwIG4gCjAwMDAxMjM3NjEgMDAwMDAgbiAKMDAwMDEy
Mzk1OCAwMDAwMCBuIAowMDAwMTI0MTQ5IDAwMDAwIG4gCjAwMDAxMjQzMjcgMDAwMDAgbiAKMDAw
MDEyNDU0NCAwMDAwMCBuIAowMDAwMTI0NzYyIDAwMDAwIG4gCjAwMDAxNDIzNzkgMDAwMDAgbiAK
MDAwMDEzMjk0MiAwMDAwMCBuIAowMDAwMTQyMjUwIDAwMDAwIG4gCjAwMDAxMzMxNjUgMDAwMDAg
biAKMDAwMDEzMzE0MiAwMDAwMCBuIAowMDAwMTMzMzA3IDAwMDAwIG4gCjAwMDAxMzMyODQgMDAw
MDAgbiAKMDAwMDE0MjIxMSAwMDAwMCBuIAowMDAwMTMzNDc2IDAwMDAwIG4gCjAwMDAxMzM0NTMg
MDAwMDAgbiAKMDAwMDE0MjE3MiAwMDAwMCBuIAowMDAwMTMzNjQzIDAwMDAwIG4gCjAwMDAxMzM2
MjAgMDAwMDAgbiAKMDAwMDE0MjEzMyAwMDAwMCBuIAowMDAwMTMzODA3IDAwMDAwIG4gCjAwMDAx
MzM3ODQgMDAwMDAgbiAKMDAwMDE0MjA5NCAwMDAwMCBuIAowMDAwMTMzOTcyIDAwMDAwIG4gCjAw
MDAxMzM5NDkgMDAwMDAgbiAKMDAwMDE0MjA1NSAwMDAwMCBuIAowMDAwMTM0MjAzIDAwMDAwIG4g
CjAwMDAxMzQxODAgMDAwMDAgbiAKMDAwMDE0MjAxNiAwMDAwMCBuIAowMDAwMTM0NDY5IDAwMDAw
IG4gCjAwMDAxMzQ0NDYgMDAwMDAgbiAKMDAwMDE0MTk3NyAwMDAwMCBuIAowMDAwMTM0NzIwIDAw
MDAwIG4gCjAwMDAxMzQ2OTcgMDAwMDAgbiAKMDAwMDE0MTkzOCAwMDAwMCBuIAowMDAwMTM0OTY2
IDAwMDAwIG4gCjAwMDAxMzQ5NDMgMDAwMDAgbiAKMDAwMDE0MTg5OSAwMDAwMCBuIAowMDAwMTM1
MTc3IDAwMDAwIG4gCjAwMDAxMzUxNTQgMDAwMDAgbiAKMDAwMDE0MTg2MCAwMDAwMCBuIAowMDAw
MTM1MzczIDAwMDAwIG4gCjAwMDAxMzUzNTAgMDAwMDAgbiAKMDAwMDE0MTgyMSAwMDAwMCBuIAow
MDAwMTM1NjE5IDAwMDAwIG4gCjAwMDAxMzU1OTYgMDAwMDAgbiAKMDAwMDE0MTc4MiAwMDAwMCBu
IAowMDAwMTM1ODI5IDAwMDAwIG4gCjAwMDAxMzU4MDYgMDAwMDAgbiAKMDAwMDE0MTc0MyAwMDAw
MCBuIAowMDAwMTM2MTEwIDAwMDAwIG4gCjAwMDAxMzYwODcgMDAwMDAgbiAKMDAwMDE0MTcwNCAw
MDAwMCBuIAowMDAwMTM2MzczIDAwMDAwIG4gCjAwMDAxMzYzNTAgMDAwMDAgbiAKMDAwMDE0MTY2
NSAwMDAwMCBuIAowMDAwMTM2NjU3IDAwMDAwIG4gCjAwMDAxMzY2MzQgMDAwMDAgbiAKMDAwMDE0
MTYyNiAwMDAwMCBuIAowMDAwMTM2OTA3IDAwMDAwIG4gCjAwMDAxMzY4ODQgMDAwMDAgbiAKMDAw
MDE0MTU4NyAwMDAwMCBuIAowMDAwMTM3MTczIDAwMDAwIG4gCjAwMDAxMzcxNTAgMDAwMDAgbiAK
MDAwMDE0MTU0OCAwMDAwMCBuIAowMDAwMTM3NTE5IDAwMDAwIG4gCjAwMDAxMzc0OTYgMDAwMDAg
biAKMDAwMDE0MTUwOSAwMDAwMCBuIAowMDAwMTM3Nzk1IDAwMDAwIG4gCjAwMDAxMzc3NzIgMDAw
MDAgbiAKMDAwMDE0MTQ3MCAwMDAwMCBuIAowMDAwMTM4MDU2IDAwMDAwIG4gCjAwMDAxMzgwMzMg
MDAwMDAgbiAKMDAwMDE0MTQzMSAwMDAwMCBuIAowMDAwMTM4MzI5IDAwMDAwIG4gCjAwMDAxMzgz
MDYgMDAwMDAgbiAKMDAwMDE0MTM5MiAwMDAwMCBuIAowMDAwMTM4NTM4IDAwMDAwIG4gCjAwMDAx
Mzg1MTUgMDAwMDAgbiAKMDAwMDE0MTM1MyAwMDAwMCBuIAowMDAwMTM4NzY0IDAwMDAwIG4gCjAw
MDAxMzg3NDEgMDAwMDAgbiAKMDAwMDE0MTMxNCAwMDAwMCBuIAowMDAwMTM5MDI2IDAwMDAwIG4g
CjAwMDAxMzkwMDMgMDAwMDAgbiAKMDAwMDE0MTI3NSAwMDAwMCBuIAowMDAwMTM5MjQ4IDAwMDAw
IG4gCjAwMDAxMzkyMjUgMDAwMDAgbiAKMDAwMDE0MTIzNiAwMDAwMCBuIAowMDAwMTM5NjAwIDAw
MDAwIG4gCjAwMDAxMzk1NzcgMDAwMDAgbiAKMDAwMDE0MTE5NyAwMDAwMCBuIAowMDAwMTM5ODc3
IDAwMDAwIG4gCjAwMDAxMzk4NTQgMDAwMDAgbiAKMDAwMDE0MTE1OCAwMDAwMCBuIAowMDAwMTQw
MTU0IDAwMDAwIG4gCjAwMDAxNDAxMzEgMDAwMDAgbiAKMDAwMDE0MTExOSAwMDAwMCBuIAowMDAw
MTQwMzY2IDAwMDAwIG4gCjAwMDAxNDAzNDMgMDAwMDAgbiAKMDAwMDE0MTA4MCAwMDAwMCBuIAow
MDAwMTQwNjI4IDAwMDAwIG4gCjAwMDAxNDA2MDUgMDAwMDAgbiAKMDAwMDE0MTA0MSAwMDAwMCBu
IAowMDAwMTQwODUwIDAwMDAwIG4gCjAwMDAxNDA4MjcgMDAwMDAgbiAKMDAwMDE0MTAwMiAwMDAw
MCBuIAowMDAwMTQwOTc5IDAwMDAwIG4gCjAwMDAxNDMwNDQgMDAwMDAgbiAKMDAwMDE0MjczNyAw
MDAwMCBuIAowMDAwMTQzMDIzIDAwMDAwIG4gCjAwMDAxNDMyNjEgMDAwMDAgbiAKMDAwMDE0MzU3
MSAwMDAwMCBuIAowMDAwMTQzODIzIDAwMDAwIG4gCjAwMDAxNTI1ODYgMDAwMDAgbiAKMDAwMDE1
MzA2NyAwMDAwMCBuIAowMDAwMTUyNzYwIDAwMDAwIG4gCjAwMDAxNTMwNDYgMDAwMDAgbiAKMDAw
MDE1MzI3NyAwMDAwMCBuIAowMDAwMTUzNTI0IDAwMDAwIG4gCjAwMDAxNTM3NTIgMDAwMDAgbiAK
MDAwMDE1ODY2NSAwMDAwMCBuIAowMDAwMTU5MTQxIDAwMDAwIG4gCjAwMDAxNTg4MzQgMDAwMDAg
biAKMDAwMDE1OTEyMCAwMDAwMCBuIAowMDAwMTU5MzQ2IDAwMDAwIG4gCjAwMDAxNTkzNzUgMDAw
MDAgbiAKMDAwMDE1OTYxMyAwMDAwMCBuIAowMDAwMTY0Mzk3IDAwMDAwIG4gCjAwMDAxNjQ4Nzcg
MDAwMDAgbiAKMDAwMDE2NDU3MCAwMDAwMCBuIAowMDAwMTY0ODU2IDAwMDAwIG4gCjAwMDAxNjUw
ODYgMDAwMDAgbiAKMDAwMDE2NTI4OSAwMDAwMCBuIAowMDAwMTY1NTQzIDAwMDAwIG4gCjAwMDAx
NzE3MDggMDAwMDAgbiAKMDAwMDE3MjE4OCAwMDAwMCBuIAowMDAwMTcxODgxIDAwMDAwIG4gCjAw
MDAxNzIxNjcgMDAwMDAgbiAKMDAwMDE3MjM5NyAwMDAwMCBuIAowMDAwMTcyNDI3IDAwMDAwIG4g
CjAwMDAxNzI2NjggMDAwMDAgbiAKMDAwMDE4MTA4MCAwMDAwMCBuIAowMDAwMTgxNTY5IDAwMDAw
IG4gCjAwMDAxODEyNjIgMDAwMDAgbiAKMDAwMDE4MTU0OCAwMDAwMCBuIAowMDAwMTgxNzg3IDAw
MDAwIG4gCjAwMDAxODIxMTggMDAwMDAgbiAKMDAwMDE4MjM3MCAwMDAwMCBuIAowMDAwMTkwODg4
IDAwMDAwIG4gCjAwMDAxOTA5MTAgMDAwMDAgbiAKMDAwMDE5MDk3NiAwMDAwMCBuIAowMDAwMTkx
MDI5IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMzAwIC9Sb290IDE0MCAwIFIgL0luZm8gMSAw
IFIgL0lEIFsgPDk5Nzk5MTVjZmM2NGJhMGYyZGU4Mzg3NTQ2YzJhYmZmPgo8OTk3OTkxNWNmYzY0
YmEwZjJkZTgzODc1NDZjMmFiZmY+IF0gPj4Kc3RhcnR4cmVmCjE5MTE2NQolJUVPRgo=

--_004_4008FD898DCA414EA92D97EB377BEAA5mitreorg_--

From guang.g.yang@oracle.com  Tue Mar 27 17:32:24 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9A021F85B1 for ; Tue, 27 Mar 2012 17:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.9
X-Spam-Level: 
X-Spam-Status: No, score=-9.9 tagged_above=-999 required=5 tests=[AWL=-0.698,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy1IZAU1F924 for ; Tue, 27 Mar 2012 17:32:23 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3856621F85AD for ; Tue, 27 Mar 2012 17:32:23 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2S0WLWD026535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Mar 2012 00:32:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2S0WKoY025488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2012 00:32:21 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2S0WKHi008429; Tue, 27 Mar 2012 19:32:20 -0500
Received: from [192.168.1.100] (/111.161.36.99) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Mar 2012 17:32:20 -0700
References: <704876DE7EC20A49B6D0A5892068B0130B093AC1FD@DFW1MBX10.mex07a.mlsrvr.com>
In-Reply-To: <704876DE7EC20A49B6D0A5892068B0130B093AC1FD@DFW1MBX10.mex07a.mlsrvr.com>
Mime-Version: 1.0 (iPad Mail 8J2)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-2-252741370
Message-Id: 
X-Mailer: iPad Mail (8J2)
From: Guang Yang 
Date: Wed, 28 Mar 2012 08:32:19 +0800
To: Jay Thorne 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F725C16.006B,ss=1,re=-2.300,fgs=0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 00:32:24 -0000

--Apple-Mail-2-252741370
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=GB2312

Thank you. Actually I am looking for a standard spec defines how to put the a=
ccess token in soap request. I know several vendors in the industry have the=
ir solution of it but none of them is following a public standardization. So=
 could you please do me a favor on letting me know how your product does for=
 soap? Appreciate for your help.

To the community, according recent emails back and force looks like we agree=
 that it makes sense to have oauth enabled for soap, but nobody is giving a s=
uggestion how to do it except using saml. I will appreciate to hear more sug=
gestions before choosing a private way of my organization.

Thanks a lot,
Grant.
Oracle Communications, SDP

On Mar 28, 2012, at 4:38 AM, Jay Thorne  wrote:

> http://www.layer7tech.com/
>=20
> =20
>=20
> http://www.layer7tech.com/products/oauth-toolkit
>=20
> =20
>=20
> Yes, we can work with OAuth2 in SOAP context. Let me know if you want to h=
ear more about it.
>=20
> =20
>=20
> =20
>=20
> --
>=20
> Jay Thorne, Director of Development, Tactical Group
>=20
> Layer 7 Technologies t: 778 329 9974 c:604 836 7257
>=20
> =20
>=20
> From: Chris Dryden=20
> Sent: Tuesday, March 27, 2012 1:04 PM
> To: Jay Thorne
> Subject: FW: [OAUTH-WG] Using Oauth2 token to SOAP web services
>=20
> =20
>=20
> Jay, this message was posted to the OAuth working group today. I have seen=
 someone else asking for the same thing -- OAuth tokens in a SOAP context. T=
his seems like our area of expertise, doesn't it?
>=20
> =20
>=20
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of G=
rant Yang
> Sent: Wednesday, March 14, 2012 10:41 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Using Oauth2 token to SOAP web services
>=20
> =20
>=20
> Hi all,
>=20
> =20
>=20
> We were discussing the possibility to use Oauth2 token on SOAP in our prod=
uct.
>=20
> =20
>=20
> The preferred way in mentioned in RFC is of course to put it to HTTP Autho=
rization header, but in this case it will beyond the scope of SOAP stack and=
 I am not sure it shall be the correct way to go. It is also recognized that=
 there is some implementation (such as salesforce) is using some SOAP header=
 (=A1=B0sessionId=A1=B1) to put this token, but it looks like a private impl=
ementation and I did not find any specification supporting it.
>=20
> =20
>=20
> Could any experts here illustrate any organization or forum is working on u=
sing Oauth2 token for SOAP request? As there are quite some legacy SOAP base=
d web services, hopefully it is a question makes sense for you as well.
>=20
> =20
>=20
> Thoughts?
>=20
> =20
>=20
> Grant Yang
>=20
> Architect, SDP of ORACLE Communications
>=20
> =20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-2-252741370
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Thank you. Actually I am looking for a s=
tandard spec defines how to put the access token in soap request. I know sev=
eral vendors in the industry have their solution of it but none of them is f=
ollowing a public standardization. So could you please do me a favor on lett=
ing me know how your product does for soap? Appreciate for your help.
<=
div>
To the community, according recent emails back and force l=
ooks like we agree that it makes sense to have oauth enabled for soap, but n=
obody is giving a suggestion how to do it except using saml. I will apprecia=
te to hear more suggestions before choosing a private way of my organization=
.

Thanks a lot,
Grant.
Oracle C=
ommunications, SDP

On Mar 28, 2012, at 4:38 AM, Jay Thorne <=
;jthorne@layer7tech.com> wr=
ote:

http://www.layer7tech.com/
 
http://www.layer7tech.com/products/oauth-=
toolkit
 
Yes, we can work with OAuth2 in SOAP context. Let me kn=
ow if you want to hear more about it. 
=
 
<=
p class=3D"MsoNormal">&n=
bsp;
--
Jay Thorne, Director of Developm=
ent, Tactical Group
Layer 7 Technologies <=
b>t: 778 329 9974 c:604 836 7257 
 
<=
span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-ser=
if"">From: Chris Dryden 
Sent: Tuesday,=
 March 27, 2012 1:04 PM
To: Jay Thorne
Subject: FW: [OAU=
TH-WG] Using Oauth2 token to SOAP web services
&nb=
sp;
Jay, this message was posted to the OAuth working group today. I have=
 seen someone else asking for the same thing -- OAuth tokens in a SOAP conte=
xt. This seems like our area of expertise, doesn't it? 
=
 
From: oa=
uth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=
 On Behalf Of Grant Yang
Sent: Wednesday, March 14, 2012 10=
:41 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Using Oaut=
h2 token to SOAP web services
 
Hi all, 
 =

We were discussing the possibility to use O=
auth2 token on SOAP in our product. 
 
The preferred way in mentioned in R=
FC is of course to put it to HTTP Authorization header, but in this case it w=
ill beyond the scope of SOAP stack and I am not sure it shall be the correct=
 way to go. It is also recognized that there is some implementation (such as=
 salesforce) is using some SOAP header (=E2=80=9CsessionId=E2=80=9D) to put t=
his token, but it looks like a private implementation and I did not find any=
 specification supporting it. 
&nb=
sp;
Could any experts here illustrate any or=
ganization or forum is working on using Oauth2 token for SOAP request? As th=
ere are quite some legacy SOAP based web services, hopefully it is a questio=
n makes sense for you as well.
&nb=
sp;
Thoughts?
 
Grant Yang
=

Architect, SDP of ORACLE Communications
 
_____________________________________________=
__
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=

--Apple-Mail-2-252741370--

From werners@bloudraak.com  Tue Mar 27 20:33:34 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F398621E801A for ; Tue, 27 Mar 2012 20:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mbEO7IbA6Bj for ; Tue, 27 Mar 2012 20:33:33 -0700 (PDT)
Received: from psmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id D233121E80FE for ; Tue, 27 Mar 2012 20:33:18 -0700 (PDT)
Received: from bloudraak.com ([66.209.67.179]) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKT3KGfoX32OuGkBNV62vlDv6XnqR0sNPa@postini.com; Tue, 27 Mar 2012 20:33:18 PDT
Received: from [172.16.1.102] (c-98-207-173-190.hsd1.ca.comcast.net [98.207.173.190]) by bloudraak.com (Postfix) with ESMTPSA id 23C03257D92; Tue, 27 Mar 2012 20:28:06 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Werner Strydom 
In-Reply-To: <4008FD89-8DCA-414E-A92D-97EB377BEAA5@mitre.org>
Date: Tue, 27 Mar 2012 20:28:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <792D4CD7-4F56-4F4D-8450-D02A875583A1@bloudraak.com>
References:  <4008FD89-8DCA-414E-A92D-97EB377BEAA5@mitre.org>
To: "Richer, Justin P." 
X-Mailer: Apple Mail (2.1257)
Cc: "" 
Subject: Re: [OAUTH-WG] HTTP responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 03:33:34 -0000

Justin,

I had a quick look.

You may want to include "text/xml" as a valid xml media type since it is =
widely used. Additional things to consider includes using XML Schema =
(XSD) to describe the XML documents. It may also be useful to =
investigate with one should use XML namespaces or custom media types to =
differentiate OAuth 2.0 responses from other xml documents.

For example, I'm writing a REST service which returns HTTP status 400 =
when invalid data was passed. The resulting document is in "text/xml" =
format yet conforms to a very different schema than the proposed OAuth =
xml documents. How do we make this really simple for clients to know =
what is coming down the line?

This makes one wonder why the standard proposes we should return 400 =
when in reality is should return 403 (Forbidden) when you are not =
authorized.=20

Thanks,
Werner=

From martin.thomson@gmail.com  Tue Mar 27 20:56:23 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC12021E801A for ; Tue, 27 Mar 2012 20:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.673
X-Spam-Level: 
X-Spam-Status: No, score=-4.673 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1ByMrhDfmnl for ; Tue, 27 Mar 2012 20:56:23 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02FCE21F85CD for ; Tue, 27 Mar 2012 20:56:22 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so548044bku.31 for ; Tue, 27 Mar 2012 20:56:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3zUN/bry8idUbWDRAk/5GHqE1W8z0fLk+H/I/7xCVr8=; b=uO+LsOetu3/ioee5elpbn6ky1yBt8wAWV9T+DC+OcWO5CEI9qZ/oXFd4TuCaLDk2Gi m3CXCnHC7mCLKnJ81RplNl1Vs4A+fWkb9mCItcsC6V9p3GfJjqC/5CBQWU36GHk+6tLX o1Tn2ai8v6/ofr+mvLaY3AoNiCW2UpDSeudEOk4dXMkQQ7LVaQsBWQ3vbQXAHTcKh4Y2 ne1+qcMUMDq7s5rWvt5vJbphdm4Q9XPvtCfaDdtr7IJsun0F01cG6WerAlKcPGnnH+hh /IgoLomguktI3+qdBh/6a1jaubvd1h16fx3VKBSmHCmB10ZG4UVxSA4gf0MNWgVTASvY 11MQ==
MIME-Version: 1.0
Received: by 10.204.131.84 with SMTP id w20mr11133255bks.65.1332906982134; Tue, 27 Mar 2012 20:56:22 -0700 (PDT)
Received: by 10.205.38.73 with HTTP; Tue, 27 Mar 2012 20:56:22 -0700 (PDT)
In-Reply-To: <792D4CD7-4F56-4F4D-8450-D02A875583A1@bloudraak.com>
References:  <4008FD89-8DCA-414E-A92D-97EB377BEAA5@mitre.org> <792D4CD7-4F56-4F4D-8450-D02A875583A1@bloudraak.com>
Date: Wed, 28 Mar 2012 05:56:22 +0200
Message-ID: 
From: Martin Thomson 
To: Werner Strydom 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" 
Subject: Re: [OAUTH-WG] HTTP responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 03:56:23 -0000

Accepted wisdom says that you create a MIME media type in these sorts
of scenarios.

On 28 March 2012 05:28, Werner Strydom  wrote:
> Justin,
>
> I had a quick look.
>
> You may want to include "text/xml" as a valid xml media type since it is =
widely used. Additional things to consider includes using XML Schema (XSD) =
to describe the XML documents. It may also be useful to investigate with on=
e should use XML namespaces or custom media types to differentiate OAuth 2.=
0 responses from other xml documents.
>
> For example, I'm writing a REST service which returns HTTP status 400 whe=
n invalid data was passed. The resulting document is in "text/xml" format y=
et conforms to a very different schema than the proposed OAuth xml document=
s. How do we make this really simple for clients to know what is coming dow=
n the line?
>
> This makes one wonder why the standard proposes we should return 400 when=
 in reality is should return 403 (Forbidden) when you are not authorized.
>
> Thanks,
> Werner
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From torsten@lodderstedt.net  Tue Mar 27 23:26:41 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722DF21F8734 for ; Tue, 27 Mar 2012 23:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4ZeWADQvgpQ for ; Tue, 27 Mar 2012 23:26:40 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB1C21F8733 for ; Tue, 27 Mar 2012 23:26:39 -0700 (PDT)
Received: from [130.129.68.209] (helo=dhcp-44d1.meeting.ietf.org) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1SCmL7-0004uQ-Dl; Wed, 28 Mar 2012 08:26:37 +0200
References: <704876DE7EC20A49B6D0A5892068B0130B093AC1FD@DFW1MBX10.mex07a.mlsrvr.com> 
User-Agent: K-9 Mail for Android
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----79IIXAOTZQK50AK9I13HC68PMF3NYS"
From: Torsten Lodderstedt 
Date: Wed, 28 Mar 2012 08:26:35 +0200
To: Guang Yang ,Jay Thorne 
Message-ID: 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Using Oauth2 token to SOAP web services
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 06:26:41 -0000

------79IIXAOTZQK50AK9I13HC68PMF3NYS
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi Grant,

did you consider to use the binary security token feature of WS-Security? 

http://schemas.xmlsoap.org/specs/ws-security/ws-security.htm#ws-security__toc6201554

We use it for some services.

regards,
Torsten.



Guang Yang  schrieb:

Thank you. Actually I am looking for a standard spec defines how to put the access token in soap request. I know several vendors in the industry have their solution of it but none of them is following a public standardization. So could you please do me a favor on letting me know how your product does for soap? Appreciate for your help.


To the community, according recent emails back and force looks like we agree that it makes sense to have oauth enabled for soap, but nobody is giving a suggestion how to do it except using saml. I will appreciate to hear more suggestions before choosing a private way of my organization.


Thanks a lot,

Grant.

Oracle Communications, SDP


On Mar 28, 2012, at 4:38 AM, Jay Thorne  wrote:

http://www.layer7tech.com/

 

http://www.layer7tech.com/products/oauth-toolkit

 

Yes, we can work with OAuth2 in SOAP context. Let me know if you want to hear more about it. 

 

 

--

Jay Thorne, Director of Development, Tactical Group

Layer 7 Technologies t: 778 329 9974 c:604 836 7257 

 

From: Chris Dryden 
Sent: Tuesday, March 27, 2012 1:04 PM
To: Jay Thorne
Subject: FW: [OAUTH-WG] Using Oauth2 token to SOAP web services

 

Jay, this message was posted to the OAuth working group today. I have seen someone else asking for the same thing -- OAuth tokens in a SOAP context. This seems like our area of expertise, doesn't it? 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Grant Yang
Sent: Wednesday, March 14, 2012 10:41 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Using Oauth2 token to SOAP web services

 

Hi all, 

 

We were discussing the possibility to use Oauth2 token on SOAP in our product. 

 

The preferred way in mentioned in RFC is of course to put it to HTTP Authorization header, but in this case it will beyond the scope of SOAP stack and I am not sure it shall be the correct way to go. It is also recognized that there is some implementation (such as salesforce) is using some SOAP header (“sessionIdâ€) to put this token, but it looks like a private implementation and I did not find any specification supporting it. 

 

Could any experts here illustrate any organization or forum is working on using Oauth2 token for SOAP request? As there are quite some legacy SOAP based web services, hopefully it is a question makes sense for you as well.

 

Thoughts?

 

Grant Yang

Architect, SDP of ORACLE Communications

 

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


------79IIXAOTZQK50AK9I13HC68PMF3NYS
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

Hi Grant,



did you consider to use the binary security token feature of WS-Security? 



 http://schemas.xmlsoap.org/specs/ws-security/ws-security.htm#ws-security__toc6201554



We use it for some services.



regards,

Torsten.





Guang Yang <guang.g.yang@oracle.com> schrieb:


Thank you. Actually I am looking for a standard spec defines how to put the access token in soap request. I know several vendors in the industry have their solution of it but none of them is following a public standardization. So could you please do me a favor on letting me know how your product does for soap? Appreciate for your help.

To the community, according recent emails back and force looks like we agree that it makes sense to have oauth enabled for soap, but nobody is giving a suggestion how to do it except using saml. I will appreciate to hear more suggestions before choosing a private way of my organization.

Thanks a lot,
Grant.
Oracle Communications, SDP

On Mar 28, 2012, at 4:38 AM, Jay Thorne <jthorne@layer7tech.com> wrote:

http://www.layer7tech.com/
 
http://www.layer7tech.com/products/oauth-toolkit
 
Yes, we can work with OAuth2 in SOAP context. Let me know if you want to hear more about it. 
 
 
--
Jay Thorne, Director of Development, Tactical Group
Layer 7 Technologies t: 778 329 9974 c:604 836 7257 
 
From: Chris Dryden 
Sent: Tuesday, March 27, 2012 1:04 PM
To: Jay Thorne
Subject: FW: [OAUTH-WG] Using Oauth2 token to SOAP 
 web
services
 
Jay, this message was posted to the OAuth working group today. I have seen someone else asking for the same thing -- OAuth tokens in a SOAP context. This seems like our area of expertise, doesn't it? 
 
From: oauth-bounces@ietf.org [
 mailto:oauth-bounces@ietf.org] On Behalf Of Grant Yang
Sent: Wednesday, March 14, 2012 10:41 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Using Oauth2 token to SOAP web services
 
Hi all, 
 
We were discussing the possibility to use Oauth2 token on SOAP in our product. 
 
The preferred way in mentioned in RFC is of course to put it to HTTP Authorization header, but in this case it will beyond the scope of SOAP stack and I am not sure it shall be the correct way to go. It is also recognized that there is some implementation (such as salesforce) is using
  some
SOAP header (“sessionIdâ€) to put this token, but it looks like a private implementation and I did not find any specification supporting it. 
 
Could any experts here illustrate any organization or forum is working on using Oauth2 token for SOAP request? As there are quite some legacy SOAP based web services, hopefully it is a question makes sense for you as well.
 
Thoughts?
 
Grant Yang
Architect, SDP of ORACLE Communications
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

------79IIXAOTZQK50AK9I13HC68PMF3NYS--


From derek@ihtfp.com  Thu Mar 29 08:27:13 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9846A21E8209; Thu, 29 Mar 2012 08:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.988
X-Spam-Level: 
X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nmo4hIrIT4Hc; Thu, 29 Mar 2012 08:27:13 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id D7EEA21E8204; Thu, 29 Mar 2012 08:27:12 -0700 (PDT)
Received: from mocana.ihtfp.org (dhcp-5279.meeting.ietf.org [130.129.82.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id C1638260268; Thu, 29 Mar 2012 11:27:11 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q2TFR6tE012061; Thu, 29 Mar 2012 11:27:06 -0400
From: Derek Atkins 
To: saag@ietf.org, oauth@ietf.org
Date: Thu, 29 Mar 2012 11:27:03 -0400
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [OAUTH-WG] OAUTH Report for IETF-83
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 15:27:13 -0000

Hi,

OAUTH met earlier this afternoon in Afternoon Session I at 13h00 for a
two hour session.  After introducing ourselves and welcoming me to the
working group we thanked Barry and Blaine for their service.

Torsten spoke about draft-ietf-oauth-v2-threatmodel.  This document has
completed WG Last Call.  Torsten has applied changes based on the Last
Call Comments and has published a new revision.  Barry promised to
finish his PROTO Shepard review next week so we can send this document
to the IESG.  He promises to take Mike Thomas' issues from the list into
account and make sure that everyone is happy.

[ I'd like to extend a personal thank you to Barry for continuing his role
  as document shephard for this draft.  -- derek ]

Next, Mike Jones spoke about the Assertions, SAML2 Bearer, and
URN-Sub-NS drafts.  Except for one outstanding issue Mike believes these
documents are ready for WGLC.  Consensus in the room was to take these
three docs to WGLC, which the chairs will do by the end of next week.

The MAC Token draft has languished while time was spent working on the
core document.  Eran was not here, nor was he online, to talk about the
status of the MAC Token draft.  There were only a few people in the room
interested in reviewing the draft, which was not a clear consensus of
interest, even though this document does solve a problem that the bearer
tokens cannot.  The chairs will take it to the list to evaluate if there
is enough interest to continue with this document.

In a related note, this document (as well as the v2-bearer document) is
not available off the tools page even though it has not expired.  I have
taken the action item to get that sorted out.

Finally, we spent the majority of our time talking about rechartering
based on the proposed charter sent to the list by Hannes a week or two
ago.  Consensus of the room was that there was enough interest to
recharter based roughly on the proposed charter.  There was also
consensus to include Simple Web Discovery (in addition to, and separate
from, Dynamic Client Registration), although we will need to work with
the ADs to make sure it gets handled in the appropriate WG and Area.
Moreover, it's important to make sure the appropriate applications area
participants get involved in the SWD work.

Hannes and I will revise the proposed charter and send it out to the WG
for additional comments and feedback.  Our goal is to send it to the
IESG for approval on their April 26th telechat.  This would hopefully
result in approval on the May 10th chat, after public comment.

We finished the meeting at 14h30.

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From eran@hueniverse.com  Thu Mar 29 08:46:42 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6E921E80AC for ; Thu, 29 Mar 2012 08:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TDiEJ4XU18W for ; Thu, 29 Mar 2012 08:46:41 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 4940A21F8918 for ; Thu, 29 Mar 2012 08:46:41 -0700 (PDT)
Received: (qmail 26998 invoked from network); 29 Mar 2012 15:46:39 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Mar 2012 15:46:39 -0000
Received: from P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.47]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id rTmY1i00411lQaG01Tmffu; Thu, 29 Mar 2012 08:46:39 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 29 Mar 2012 08:45:05 -0700
From: Eran Hammer 
To: Derek Atkins , "saag@ietf.org" , "oauth@ietf.org" 
Date: Thu, 29 Mar 2012 08:44:57 -0700
Thread-Topic: [OAUTH-WG] OAUTH Report for IETF-83
Thread-Index: Ac0NwHndRoLYNioVSTmLLmGEsPbr+wAAE8Wg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 15:46:42 -0000

Hi Derek,

Thanks for the notes. Is an audio recording available?

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Derek Atkins
> Sent: Thursday, March 29, 2012 8:27 AM
> To: saag@ietf.org; oauth@ietf.org
> Subject: [OAUTH-WG] OAUTH Report for IETF-83
>=20
> Hi,
>=20
> OAUTH met earlier this afternoon in Afternoon Session I at 13h00 for a tw=
o
> hour session.  After introducing ourselves and welcoming me to the workin=
g
> group we thanked Barry and Blaine for their service.
>=20
> Torsten spoke about draft-ietf-oauth-v2-threatmodel.  This document has
> completed WG Last Call.  Torsten has applied changes based on the Last Ca=
ll
> Comments and has published a new revision.  Barry promised to finish his
> PROTO Shepard review next week so we can send this document to the
> IESG.  He promises to take Mike Thomas' issues from the list into account=
 and
> make sure that everyone is happy.
>=20
> [ I'd like to extend a personal thank you to Barry for continuing his rol=
e
>   as document shephard for this draft.  -- derek ]
>=20
> Next, Mike Jones spoke about the Assertions, SAML2 Bearer, and URN-Sub-
> NS drafts.  Except for one outstanding issue Mike believes these document=
s
> are ready for WGLC.  Consensus in the room was to take these three docs t=
o
> WGLC, which the chairs will do by the end of next week.
>=20
> The MAC Token draft has languished while time was spent working on the
> core document.  Eran was not here, nor was he online, to talk about the
> status of the MAC Token draft.  There were only a few people in the room
> interested in reviewing the draft, which was not a clear consensus of
> interest, even though this document does solve a problem that the bearer
> tokens cannot.  The chairs will take it to the list to evaluate if there =
is enough
> interest to continue with this document.

As I've updated the list and chairs on multiple occasions, the draft is pra=
ctically ready. There was some late arriving feedback which I did not get a=
round to process. However, the main issue is lack of WG interest in this wo=
rk. I am still planning to finish it by making very minor tweaks to the cur=
rent draft, but would be very happy to make it an individual submission.

The MAC draft has largely been my personal project to date.

> In a related note, this document (as well as the v2-bearer document) is n=
ot
> available off the tools page even though it has not expired.  I have take=
n the
> action item to get that sorted out.
>=20
> Finally, we spent the majority of our time talking about rechartering bas=
ed on
> the proposed charter sent to the list by Hannes a week or two ago.
> Consensus of the room was that there was enough interest to recharter
> based roughly on the proposed charter.  There was also consensus to inclu=
de
> Simple Web Discovery (in addition to, and separate from, Dynamic Client
> Registration), although we will need to work with the ADs to make sure it
> gets handled in the appropriate WG and Area.
> Moreover, it's important to make sure the appropriate applications area
> participants get involved in the SWD work.

There is something very awkward about discussing SWD both in the context of=
 this working group, and in the context of future OAuth discovery work. The=
 idea of picking a discovery mechanism before the WG had a single discussio=
n about what is included in discovery and what are the use cases and requir=
ement is absurd.

There has not been consensus on the list for including SWD in the WG charte=
r.

The only justification I have heard so far for this WG to be the SWD venue =
is that it's easy because the author and a few other people interested are =
already here. That's not a valid reason.

Any further work on SWD also requires the IETF to view it in light of RFC 6=
415 (host-meta) which is a proposed standard approved in October 2011. The =
IETF is not in the 'flavor of the month' business. Proper process requires =
discussion about the merits of redoing the host-meta work from scratch in a=
 non-compatible way just because a handful of people 'like it better' with =
little technical justification.

Either way, this discussion does not belong here.

EH


From wmills@yahoo-inc.com  Thu Mar 29 16:26:34 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58C021F861F for ; Thu, 29 Mar 2012 16:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.259
X-Spam-Level: 
X-Spam-Status: No, score=-17.259 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id not6efP27vcZ for ; Thu, 29 Mar 2012 16:26:33 -0700 (PDT)
Received: from nm8-vm2.bullet.mail.ne1.yahoo.com (nm8-vm2.bullet.mail.ne1.yahoo.com [98.138.90.156]) by ietfa.amsl.com (Postfix) with SMTP id 715C121F8687 for ; Thu, 29 Mar 2012 16:26:33 -0700 (PDT)
Received: from [98.138.90.54] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2012 23:26:28 -0000
Received: from [98.138.89.161] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2012 23:26:28 -0000
Received: from [127.0.0.1] by omp1017.mail.ne1.yahoo.com with NNFMP; 29 Mar 2012 23:26:28 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 725114.77312.bm@omp1017.mail.ne1.yahoo.com
Received: (qmail 52424 invoked by uid 60001); 29 Mar 2012 23:26:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1333063588; bh=1sQp9B1S0sOZQS7jTkyUTw3PaXV1FLmaELJ3mLjdjf8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=g55yCFk/uQUZIud12jmd9wJbti+PDLHyRfS6sq5mTvangvbazbwYxcY9LIhGftoqsfdvepgUoI6SRZGJT6b+X2fIgX7t0FiLY9pr3hanADqDdgTL05dt0Aw+rUc++QC+itPJHqlynFmTV6FMcZA/5Re1Md51zpuvvcwGAK/FLs4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=OmheZNuaHFIvRZbUaYQQbA9JlogIiQCaqJ1WnO/xc6zSDHi8LMy3ax17ZtgyP58EWJbnjAvM6tm5XR2oPrHqxQqIddCNfAkDXKekM9c6XwZWY1KMTohebuM6ab6KgESo73spZtzA7oMULBGW9kUGQzbv3D8mN4WIt1Nfod/kqBw=;
X-YMail-OSG: wVjB2DEVM1m0t.EYyIautkR9Q3DhzhZUJp5xngZh5lKkSDR KpJFv9zxprlri48XOFac2KY8fSCgSX0InQA3zRDnTt1_WWPX3o5u9E6pyMuM ULbNE1I0ZPf4tdEvJ871j9Wb0L9AewuHGNisxxpg1ZWsMDeVLV0rtLWXd4Yb Aq.2.eNzkF.07rrLmus8mNI4EfdpS_Zd4C3ZEqMCngHJDMolcHfx1C8r9psA k1WdzUQg0D2rG_y4tuGsQTpH8q6PR7FeCRYTLnTebPLC16ivj1zdiQ5.gVqi uXULb3RtKV6bgqv6evSUPno1EHkB7_MMIt3ThKGuOof7WMsLuCGfnkKgYydF la.XCXZptUjzpI4LhP_i.LNQJcW5chwuU_uZTJFodmFGJWnuMIpfjHW2.fbb vCInHM8jnSfx02WwCQXOkhl8fNI0uNqv8t_hYwo.sKPa5cOSK2Zo-
Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Thu, 29 Mar 2012 16:26:28 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.117.340979
References:  <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Message-ID: <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com>
Date: Thu, 29 Mar 2012 16:26:28 -0700 (PDT)
From: William Mills 
To: Eran Hammer , Derek Atkins , "saag@ietf.org" , "oauth@ietf.org" 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1238014912-2004229102-1333063588=:49896"
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 23:26:34 -0000

---1238014912-2004229102-1333063588=:49896
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On the SWD stuff there was general discussion about "is this the right plac=
e?", and there "were issues raised".=A0 The question was also asked "well, =
where is the right place?" which got crickets.=A0 It is exactly coming back=
 to the list for discussion to sort out the right place.=0A=0A=0A=0A=0A>___=
_____________________________=0A> From: Eran Hammer =
=0A>To: Derek Atkins ; "saag@ietf.org" ; "o=
auth@ietf.org"  =0A>Sent: Thursday, March 29, 2012 8:44 AM=
=0A>Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83=0A> =0A>Hi Derek,=0A>=
=0A>Thanks for the notes. Is an audio recording available?=0A>=0A>> -----Or=
iginal Message-----=0A>> From: oauth-bounces@ietf.org [mailto:oauth-bounces=
@ietf.org] On Behalf=0A>> Of Derek Atkins=0A>> Sent: Thursday, March 29, 20=
12 8:27 AM=0A>> To: saag@ietf.org; oauth@ietf.org=0A>> Subject: [OAUTH-WG] =
OAUTH Report for IETF-83=0A>> =0A>> Hi,=0A>> =0A>> OAUTH met earlier this a=
fternoon in Afternoon Session I at 13h00 for a two=0A>> hour session.=A0 Af=
ter introducing ourselves and welcoming me to the working=0A>> group we tha=
nked Barry and Blaine for their service.=0A>> =0A>> Torsten spoke about dra=
ft-ietf-oauth-v2-threatmodel.=A0 This document has=0A>> completed WG Last C=
all.=A0 Torsten has applied changes based on the Last Call=0A>> Comments an=
d has published a new revision.=A0 Barry promised to finish his=0A>> PROTO =
Shepard review next week so we can send this document to the=0A>> IESG.=A0 =
He promises to take Mike Thomas' issues from the list into account and=0A>>=
 make sure that everyone is happy.=0A>> =0A>> [ I'd like to extend a person=
al thank you to Barry for continuing his role=0A>>=A0  as document shephard=
 for this draft.=A0 -- derek ]=0A>> =0A>> Next, Mike Jones spoke about the =
Assertions, SAML2 Bearer, and URN-Sub-=0A>> NS drafts.=A0 Except for one ou=
tstanding issue Mike believes these documents=0A>> are ready for WGLC.=A0 C=
onsensus in the room was to take these three docs to=0A>> WGLC, which the c=
hairs will do by the end of next week.=0A>> =0A>> The MAC Token draft has l=
anguished while time was spent working on the=0A>> core document.=A0 Eran w=
as not here, nor was he online, to talk about the=0A>> status of the MAC To=
ken draft.=A0 There were only a few people in the room=0A>> interested in r=
eviewing the draft, which was not a clear consensus of=0A>> interest, even =
though this document does solve a problem that the bearer=0A>> tokens canno=
t.=A0 The chairs will take it to the list to evaluate if there is enough=0A=
>> interest to continue with this document.=0A>=0A>As I've updated the list=
 and chairs on multiple occasions, the draft is practically ready. There wa=
s some late arriving feedback which I did not get around to process. Howeve=
r, the main issue is lack of WG interest in this work. I am still planning =
to finish it by making very minor tweaks to the current draft, but would be=
 very happy to make it an individual submission.=0A>=0A>The MAC draft has l=
argely been my personal project to date.=0A>=0A>> In a related note, this d=
ocument (as well as the v2-bearer document) is not=0A>> available off the t=
ools page even though it has not expired.=A0 I have taken the=0A>> action i=
tem to get that sorted out.=0A>> =0A>> Finally, we spent the majority of ou=
r time talking about rechartering based on=0A>> the proposed charter sent t=
o the list by Hannes a week or two ago.=0A>> Consensus of the room was that=
 there was enough interest to recharter=0A>> based roughly on the proposed =
charter.=A0 There was also consensus to include=0A>> Simple Web Discovery (=
in addition to, and separate from, Dynamic Client=0A>> Registration), altho=
ugh we will need to work with the ADs to make sure it=0A>> gets handled in =
the appropriate WG and Area.=0A>> Moreover, it's important to make sure the=
 appropriate applications area=0A>> participants get involved in the SWD wo=
rk.=0A>=0A>There is something very awkward about discussing SWD both in the=
 context of this working group, and in the context of future OAuth discover=
y work. The idea of picking a discovery mechanism before the WG had a singl=
e discussion about what is included in discovery and what are the use cases=
 and requirement is absurd.=0A>=0A>There has not been consensus on the list=
 for including SWD in the WG charter.=0A>=0A>The only justification I have =
heard so far for this WG to be the SWD venue is that it's easy because the =
author and a few other people interested are already here. That's not a val=
id reason.=0A>=0A>Any further work on SWD also requires the IETF to view it=
 in light of RFC 6415 (host-meta) which is a proposed standard approved in =
October 2011. The IETF is not in the 'flavor of the month' business. Proper=
 process requires discussion about the merits of redoing the host-meta work=
 from scratch in a non-compatible way just because a handful of people 'lik=
e it better' with little technical justification.=0A>=0A>Either way, this d=
iscussion does not belong here.=0A>=0A>EH=0A>=0A>__________________________=
_____________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://ww=
w.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A>
---1238014912-2004229102-1333063588=:49896
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


On the SWD stuff there was general discussion about "is this the right pl=
ace?", and there "were issues raised".  The question was also asked "w=
ell, where is the right place?" which got crickets.  It is exactly com=
ing back to the list for discussion to sort out the right place.
=


  
 
 
  
  From: Eran Ham=
mer <eran@hueniverse.com>
 T=
o:
 Derek Atkins <derek@ihtfp.com>; "saag@ietf.org" <saag@ietf.org>=
;; "oauth@ietf.org" <oauth@ietf.org> 
 Sent: Thursday, March 29, 2012 8:44 AM
 Subject: Re: [OAUTH-WG] OAUTH Report=
 for IETF-83
  
 
=0AHi Derek,

Thanks for the note=
s. Is an audio recording available?

> -----Original Message-----<=
br>> From: oauth-bounces@ietf.org [mailto:oauth-bo=
unces@ietf.org] On Behalf
> Of Derek Atkins
> Sent: Thursda=
y, March 29, 2012 8:27 AM
> To: saag@ietf.org; oauth@ietf.org
> Subject=
: [OAUTH-WG] OAUTH Report for IETF-83
> 
> Hi,
> 
>=
 OAUTH met earlier this afternoon in Afternoon Session I at 13h00 for a two=

> hour session.  After introducing ourselves and welcoming me t=
o the working
> group we thanked Barry and Blaine for their service.<=
br>> 
> Torsten spoke about
 draft-ietf-oauth-v2-threatmodel.  This document has
> completed=
 WG Last Call.  Torsten has applied changes based on the Last Call
=
> Comments and has published a new revision.  Barry promised to fin=
ish his
> PROTO Shepard review next week so we can send this document=
 to the
> IESG.  He promises to take Mike Thomas' issues from th=
e list into account and
> make sure that everyone is happy.
> <=
br>> [ I'd like to extend a personal thank you to Barry for continuing h=
is role
>   as document shephard for this draft.  -- derek =
]
> 
> Next, Mike Jones spoke about the Assertions, SAML2 Beare=
r, and URN-Sub-
> NS drafts.  Except for one outstanding issue M=
ike believes these documents
> are ready for WGLC.  Consensus in=
 the room was to take these three docs to
> WGLC, which the chairs wi=
ll do by the end of next week.
> 
> The MAC Token draft
 has languished while time was spent working on the
> core document.&=
nbsp; Eran was not here, nor was he online, to talk about the
> statu=
s of the MAC Token draft.  There were only a few people in the room> interested in reviewing the draft, which was not a clear consensus of=

> interest, even though this document does solve a problem that the =
bearer
> tokens cannot.  The chairs will take it to the list to =
evaluate if there is enough
> interest to continue with this document=
.

As I've updated the list and chairs on multiple occasions, the dra=
ft is practically ready. There was some late arriving feedback which I did =
not get around to process. However, the main issue is lack of WG interest i=
n this work. I am still planning to finish it by making very minor tweaks t=
o the current draft, but would be very happy to make it an individual submi=
ssion.

The MAC draft has largely been my personal project to
 date.

> In a related note, this document (as well as the v2-bear=
er document) is not
> available off the tools page even though it has=
 not expired.  I have taken the
> action item to get that sorted=
 out.
> 
> Finally, we spent the majority of our time talking a=
bout rechartering based on
> the proposed charter sent to the list by=
 Hannes a week or two ago.
> Consensus of the room was that there was=
 enough interest to recharter
> based roughly on the proposed charter=
.  There was also consensus to include
> Simple Web Discovery (i=
n addition to, and separate from, Dynamic Client
> Registration), alt=
hough we will need to work with the ADs to make sure it
> gets handle=
d in the appropriate WG and Area.
> Moreover, it's important to make =
sure the appropriate applications area
> participants get involved in=
 the SWD work.

There is something very awkward about
 discussing SWD both in the context of this working group, and in the conte=
xt of future OAuth discovery work. The idea of picking a discovery mechanis=
m before the WG had a single discussion about what is included in discovery=
 and what are the use cases and requirement is absurd.

There has not=
 been consensus on the list for including SWD in the WG charter.

The=
 only justification I have heard so far for this WG to be the SWD venue is =
that it's easy because the author and a few other people interested are alr=
eady here. That's not a valid reason.

Any further work on SWD also r=
equires the IETF to view it in light of RFC 6415 (host-meta) which is a pro=
posed standard approved in October 2011. The IETF is not in the 'flavor of =
the month' business. Proper process requires discussion about the merits of=
 redoing the host-meta work from scratch in a non-compatible way just becau=
se a handful of people 'like it better' with little technical
 justification.

Either way, this discussion does not belong here.
EH

_______________________________________________
OAuth mai=
ling list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<=
br>

 
 
 
   

---1238014912-2004229102-1333063588=:49896--

From eran@hueniverse.com  Thu Mar 29 19:25:38 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564E921E8043; Thu, 29 Mar 2012 19:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.529
X-Spam-Level: 
X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EavrV-yvo+3K; Thu, 29 Mar 2012 19:25:33 -0700 (PDT)
Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 03A5521E801C; Thu, 29 Mar 2012 19:25:32 -0700 (PDT)
Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id reRY1i00110TkE001eRYvo; Thu, 29 Mar 2012 19:25:32 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 29 Mar 2012 19:25:32 -0700
From: Eran Hammer 
To: William Mills , Derek Atkins , "saag@ietf.org" , "oauth@ietf.org" 
Date: Thu, 29 Mar 2012 19:25:23 -0700
Thread-Topic: [OAUTH-WG] OAUTH Report for IETF-83
Thread-Index: Ac0OA2EAhhPYKnyhR0i6KLfy2HrQpQAFc/Og
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com>
In-Reply-To: <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 02:25:38 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The narrative so far:

The IETF has adopted host-meta as a general-purpose discovery mechanism in =
RFC 6415.
The OpenID Connect group, which utilizes OAuth but is out of scope for this=
 WG, adopted SWD as its discovery mechanism.
The proposed charter references 'OAuth Dynamic Client Registration Protocol=
', which in turn references RFC 6415 as its discovery mechanism.

Am I missing a WG item or proposed draft which relies on SWD at this time? =
If I am, are these documents included in the proposed charter or are reques=
ted to be included (e.g. not SWT itself but other documents with dependenci=
es on it)? In such documents, is SWD a required component which cannot be s=
ubstituted with something else such as RFC 6415?

Here is how this process should work:


1.       The WG agrees on including a discovery related item in its charter=
. The dynamic client registration is a reasonable such item.

2.       The charter references an existing proposal as foundation.

3.       The WG begins discussing the proposed draft (which can happen at a=
ny time on the list as long as the chairs allow it).

4.       The WG discusses any required enabling technologies, their suitabi=
lity, maturity, industry support, etc. In the case of dynamic registration,=
 I expect the WG to discuss SWD (because it is the technology selected by t=
he OpenID subset of this WG), host-meta (because it is an IETF proposed sta=
ndard RFC), as well as other solutions (Link headers, other well-known URIs=
, etc.). The publication status of the proposed technologies is another fac=
tor.

5.       If an enabling technology is decided to be the most suitable, and =
is not available in normative reference form, the WG will discuss the best =
way to accomplish that. This includes identifying the right community, stan=
dards body, working group, etc. that is best to take on the work. If no sui=
table venue is found, the WG may decide to take on the work with very limit=
ed scope only to enable its own use cases.

I am not opposed to having this discussion, but why are *we* having it *now=
*, other than the OpenID Connect group, which has nothing to do with this W=
G, is stuck with the problem of finding a venue for this work, and are dump=
ing it on our laps?

I do not recall this WG ever decided (or even *proposed*) to use SWD for an=
y of its chartered items. When we have this discussion, I expect it to incl=
ude a detailed examination of host-meta and other solutions *as equal* alte=
rnatives. The OpenID Connect group preference is a valid input as it covers=
 some potential market share with OAuth deployment, but it is *far* from an=
y significant deployment worthy of bypassing this evaluation.

Am I missing something here?

EH





From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Thursday, March 29, 2012 4:26 PM
To: Eran Hammer; Derek Atkins; saag@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83

On the SWD stuff there was general discussion about "is this the right plac=
e?", and there "were issues raised".  The question was also asked "well, wh=
ere is the right place?" which got crickets.  It is exactly coming back to =
the list for discussion to sort out the right place.

________________________________
From: Eran Hammer >
To: Derek Atkins >; "saag@ietf.org<=
mailto:saag@ietf.org>" >; "oauth@ietf.o=
rg" >
Sent: Thursday, March 29, 2012 8:44 AM
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83

Hi Derek,

Thanks for the notes. Is an audio recording available?

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth=
-bounces@ietf.org] On Behalf
> Of Derek Atkins
> Sent: Thursday, March 29, 2012 8:27 AM
> To: saag@ietf.org; oauth@ietf.org
> Subject: [OAUTH-WG] OAUTH Report for IETF-83
>
> Hi,
>
> OAUTH met earlier this afternoon in Afternoon Session I at 13h00 for a tw=
o
> hour session.  After introducing ourselves and welcoming me to the workin=
g
> group we thanked Barry and Blaine for their service.
>
> Torsten spoke about draft-ietf-oauth-v2-threatmodel.  This document has
> completed WG Last Call.  Torsten has applied changes based on the Last Ca=
ll
> Comments and has published a new revision.  Barry promised to finish his
> PROTO Shepard review next week so we can send this document to the
> IESG.  He promises to take Mike Thomas' issues from the list into account=
 and
> make sure that everyone is happy.
>
> [ I'd like to extend a personal thank you to Barry for continuing his rol=
e
>  as document shephard for this draft.  -- derek ]
>
> Next, Mike Jones spoke about the Assertions, SAML2 Bearer, and URN-Sub-
> NS drafts.  Except for one outstanding issue Mike believes these document=
s
> are ready for WGLC.  Consensus in the room was to take these three docs t=
o
> WGLC, which the chairs will do by the end of next week.
>
> The MAC Token draft has languished while time was spent working on the
> core document.  Eran was not here, nor was he online, to talk about the
> status of the MAC Token draft.  There were only a few people in the room
> interested in reviewing the draft, which was not a clear consensus of
> interest, even though this document does solve a problem that the bearer
> tokens cannot.  The chairs will take it to the list to evaluate if there =
is enough
> interest to continue with this document.

As I've updated the list and chairs on multiple occasions, the draft is pra=
ctically ready. There was some late arriving feedback which I did not get a=
round to process. However, the main issue is lack of WG interest in this wo=
rk. I am still planning to finish it by making very minor tweaks to the cur=
rent draft, but would be very happy to make it an individual submission.

The MAC draft has largely been my personal project to date.

> In a related note, this document (as well as the v2-bearer document) is n=
ot
> available off the tools page even though it has not expired.  I have take=
n the
> action item to get that sorted out.
>
> Finally, we spent the majority of our time talking about rechartering bas=
ed on
> the proposed charter sent to the list by Hannes a week or two ago.
> Consensus of the room was that there was enough interest to recharter
> based roughly on the proposed charter.  There was also consensus to inclu=
de
> Simple Web Discovery (in addition to, and separate from, Dynamic Client
> Registration), although we will need to work with the ADs to make sure it
> gets handled in the appropriate WG and Area.
> Moreover, it's important to make sure the appropriate applications area
> participants get involved in the SWD work.

There is something very awkward about discussing SWD both in the context of=
 this working group, and in the context of future OAuth discovery work. The=
 idea of picking a discovery mechanism before the WG had a single discussio=
n about what is included in discovery and what are the use cases and requir=
ement is absurd.

There has not been consensus on the list for including SWD in the WG charte=
r.

The only justification I have heard so far for this WG to be the SWD venue =
is that it's easy because the author and a few other people interested are =
already here. That's not a valid reason.

Any further work on SWD also requires the IETF to view it in light of RFC 6=
415 (host-meta) which is a proposed standard approved in October 2011. The =
IETF is not in the 'flavor of the month' business. Proper process requires =
discussion about the merits of redoing the host-meta work from scratch in a=
 non-compatible way just because a handful of people 'like it better' with =
little technical justification.

Either way, this discussion does not belong here.

EH

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


--_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The narra=
tive so far:
 
The IETF has adopted host-meta a=
s a general-purpose discovery mechanism in RFC 6415.
<=
p class=3DMsoNormal>The OpenID Connect group, which utilizes OAuth b=
ut is out of scope for this WG, adopted SWD as its discovery mechanism.
The proposed charter referenc=
es ‘OAuth Dynamic Client Registration Protocol’, which in turn =
references RFC 6415 as its discovery mechanism.
 
Am I missing a WG item or proposed draft which relies on SWD at this tim=
e? If I am, are these documents included in the proposed charter or are req=
uested to be included (e.g. not SWT itself but other documents with depende=
ncies on it)? In such documents, is SWD a required component which cannot b=
e substituted with something else such as RFC 6415?
 
=
Here is how this process should work:
 
=
1.       The WG agrees on including a discovery re=
lated item in its charter. The dynamic client registration is a reasonable =
such item.
2. =
;      The charter references an existing proposal as foundation=
.
3.  &n=
bsp;    The WG begins discussing the proposed draft (which can happen at a=
ny time on the list as long as the chairs allow it).
<=
p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 l=
fo1'>4.       <=
/span>The WG discusse=
s any required enabling technologies, their suitability, maturity, industry=
 support, etc. In the case of dynamic registration, I expect the WG to disc=
uss SWD (because it is the technology selected by the OpenID subset of this=
 WG), host-meta (because it is an IETF proposed standard RFC), as well as o=
ther solutions (Link headers, other well-known URIs, etc.). The publication=
 status of the proposed technologies is another factor.
5.      =
; If an enabli=
ng technology is decided to be the most suitable, and is not available in n=
ormative reference form, the WG will discuss the best way to accomplish tha=
t. This includes identifying the right community, standards body, working g=
roup, etc. that is best to take on the work. If no suitable venue is found,=
 the WG may decide to take on the work with very limited scope only to enab=
le its own use cases.
 
I am not opposed to hav=
ing this discussion, but why are *we* having it *now*, other =
than the OpenID Connect group, which has nothing to do with this WG, is stu=
ck with the problem of finding a venue for this work, and are dumping it on=
 our laps?
 
I do not recall this WG ever decid=
ed (or even *proposed*) to use SWD for any of its chartered items. W=
hen we have this discussion, I expect it to include a detailed examination =
of host-meta and other solutions *as equal* alternatives. The OpenID=
 Connect group preference is a valid input as it covers some potential mark=
et share with OAuth deployment, but it is *far* from any significant=
 deployment worthy of bypassing this evaluation.
 
Am I missing something here?
=
 
EH
 
 
 
 =

 
<=
div>
From: William Mills [mailto:wmills@yahoo-in=
c.com] 
Sent: Thursday, March 29, 2012 4:26 PM
To: Eran=
 Hammer; Derek Atkins; saag@ietf.org; oauth@ietf.org
Subject: Re:=
 [OAUTH-WG] OAUTH Report for IETF-83
 
On the SWD stuff there was general discussion about "=
;is this the right place?", and there "were issues raised".&=
nbsp; The question was also asked "well, where is the right place?&quo=
t; which got crickets.  It is exactly coming back to the list for disc=
ussion to sort out the right place.
 
<=
div>
From: Eran =
Hammer <eran@hueniverse.com&g=
t;
To: Derek Atkins <derek@=
ihtfp.com>; "saag@ietf.org=
" <saag@ietf.org>; "oauth@ietf.org" <oauth@ietf.org> 
Sent: Thursday, March=
 29, 2012 8:44 AM
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-8=
3

Hi Derek,

Thanks for the notes. Is an audio recording=
 available?

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf> Of Derek Atkins
> Sent: Thursday, March 29, 2012 8:27 AM
>=
; To: saag@ietf.org; oauth@ietf.org
> Subject: [OAUTH-WG] OAUTH Repor=
t for IETF-83
> 
> Hi,
> 
> OAUTH met earlier this =
afternoon in Afternoon Session I at 13h00 for a two
> hour session.&n=
bsp; After introducing ourselves and welcoming me to the working
> gr=
oup we thanked Barry and Blaine for their service.
> 
> Torsten=
 spoke about draft-ietf-oauth-v2-threatmodel.  This document has
&g=
t; completed WG Last Call.  Torsten has applied changes based on the L=
ast Call
> Comments and has published a new revision.  Barry pro=
mised to finish his
> PROTO Shepard review next week so we can send t=
his document to the
> IESG.  He promises to take Mike Thomas' is=
sues from the list into account and
> make sure that everyone is happ=
y.
> 
> [ I'd like to extend a personal thank you to Barry for =
continuing his role
>  as document shephard for this draft. =
; -- derek ]
> 
> Next, Mike Jones spoke about the Assertions, =
SAML2 Bearer, and URN-Sub-
> NS drafts.  Except for one outstand=
ing issue Mike believes these documents
> are ready for WGLC.  C=
onsensus in the room was to take these three docs to
> WGLC, which th=
e chairs will do by the end of next week.
> 
> The MAC Token dr=
aft has languished while time was spent working on the
> core documen=
t.  Eran was not here, nor was he online, to talk about the
> st=
atus of the MAC Token draft.  There were only a few people in the room=

> interested in reviewing the draft, which was not a clear consensus=
 of
> interest, even though this document does solve a problem that t=
he bearer
> tokens cannot.  The chairs will take it to the list =
to evaluate if there is enough
> interest to continue with this docum=
ent.

As I've updated the list and chairs on multiple occasions, the =
draft is practically ready. There was some late arriving feedback which I d=
id not get around to process. However, the main issue is lack of WG interes=
t in this work. I am still planning to finish it by making very minor tweak=
s to the current draft, but would be very happy to make it an individual su=
bmission.

The MAC draft has largely been my personal project to date=
.

> In a related note, this document (as well as the v2-bearer do=
cument) is not
> available off the tools page even though it has not =
expired.  I have taken the
> action item to get that sorted out.=

> 
> Finally, we spent the majority of our time talking about =
rechartering based on
> the proposed charter sent to the list by Hann=
es a week or two ago.
> Consensus of the room was that there was enou=
gh interest to recharter
> based roughly on the proposed charter.&nbs=
p; There was also consensus to include
> Simple Web Discovery (in add=
ition to, and separate from, Dynamic Client
> Registration), although=
 we will need to work with the ADs to make sure it
> gets handled in =
the appropriate WG and Area.
> Moreover, it's important to make sure =
the appropriate applications area
> participants get involved in the =
SWD work.

There is something very awkward about discussing SWD both =
in the context of this working group, and in the context of future OAuth di=
scovery work. The idea of picking a discovery mechanism before the WG had a=
 single discussion about what is included in discovery and what are the use=
 cases and requirement is absurd.

There has not been consensus on th=
e list for including SWD in the WG charter.

The only justification I=
 have heard so far for this WG to be the SWD venue is that it's easy becaus=
e the author and a few other people interested are already here. That's not=
 a valid reason.

Any further work on SWD also requires the IETF to v=
iew it in light of RFC 6415 (host-meta) which is a proposed standard approv=
ed in October 2011. The IETF is not in the 'flavor of the month' business. =
Proper process requires discussion about the merits of redoing the host-met=
a work from scratch in a non-compatible way just because a handful of peopl=
e 'like it better' with little technical justification.

Either way, =
this discussion does not belong here.

EH

____________________=
___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut=
h

=

--_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4P3PW5EX1MB01E_--

From wmills@yahoo-inc.com  Thu Mar 29 23:14:19 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF7021F8794 for ; Thu, 29 Mar 2012 23:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.267
X-Spam-Level: 
X-Spam-Status: No, score=-17.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWfHy+HtfHWk for ; Thu, 29 Mar 2012 23:14:18 -0700 (PDT)
Received: from nm22.bullet.mail.sp2.yahoo.com (nm22.bullet.mail.sp2.yahoo.com [98.139.91.92]) by ietfa.amsl.com (Postfix) with SMTP id 8AE9921F87B9 for ; Thu, 29 Mar 2012 23:14:18 -0700 (PDT)
Received: from [98.139.91.68] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 30 Mar 2012 06:14:15 -0000
Received: from [98.139.91.28] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 30 Mar 2012 06:13:15 -0000
Received: from [127.0.0.1] by omp1028.mail.sp2.yahoo.com with NNFMP; 30 Mar 2012 06:13:15 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 763396.48641.bm@omp1028.mail.sp2.yahoo.com
Received: (qmail 4543 invoked by uid 60001); 30 Mar 2012 06:13:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1333087995; bh=I17ufNYyJYdq1T+oDSryGu8u10Bn22VdrBbiE3mIoa4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WUJLa5nzo+lox2/bwPIL+Mj6zRrVHD+TO5PV8EJJzopjdJxh5WNTSeJtzFvJcUU5Q4fNLTl+Dfnrfp/mmV+yWhGBTzEHZseWacKphkify+fJfyidGpUL+FDtbsmZ/yP0bjDIfWmsUESxI8Z0nNX2V4P++BvpM/AtQ0r2hT0yN2o=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=O70zux3VyurA6iW72BscfgjlRV4up9xicv/LJ94hUPbMLtvjzfv4pFW6rhjopnfCyGDigFWnFIZQBisvZ4YEJK8/GCM+g9na6VQUHmBtpXXTk2ACGa/f857S0/uozbCGMe1jq2nWfPkypI5BBr25ZTDhVtFZ6NEZ6Pd9QYCULMc=;
X-YMail-OSG: QQiUBCUVM1kyxiqEHx6ZjRxLqRN.Vo7bC1QnW8viHloKhKk QIG2L5sWCLxrodQdHxqOXn_ZZXZ2imWBbJojP10q2GVcy4rML_0PQSeMBL6s 46sdtbvIufu5BkvYrygNyEUZrP8haHz3L86TeznewJJPxj0s4rGTG2BJBz7y XkkpfXajX4x53T82OJhXkc9WogvWkrrpL.oMsdRdhuPzXELh44Ay4cfLaS8z jf9tsT.Y4E1Rjke0DFoyiqhYdVvSKO8_FYZA5NTwtZBXhrR4a5vxzI.cz2wV SH2kdGsHvzlCMtWG2269MkoCmcnGO2BPOZ.ulu.a5EiPBFRtnaxkuvFGVDfc 38CijxOzBcnmMsfD_Gl9hRoBsKEn32dXXxt.pia_RlIDaIOXRgQ39gCriISY 03sVu0SHXSEM1F2khyWUw35UA_hKns.TdZHlhiVKLO_FkfPDpQnk-
Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Thu, 29 Mar 2012 23:13:14 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.117.340979
References:  <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Message-ID: <1333087994.88149.YahooMailNeo@web31811.mail.mud.yahoo.com>
Date: Thu, 29 Mar 2012 23:13:14 -0700 (PDT)
From: William Mills 
To: Eran Hammer , Derek Atkins , "saag@ietf.org" , "oauth@ietf.org" 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="764183289-808086310-1333087994=:88149"
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 06:14:20 -0000

--764183289-808086310-1333087994=:88149
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thanks for the process lecture....=C2=A0 except we already had extensive di=
scussion of same in the WG meeting...=0A=0APartially this issue was raised =
because my draft does a discovery thing and I want this sorted out to figur=
e out what hooks I need to put in so I can get done.=C2=A0 I want to be con=
sistent with whatever will be the chosen standardized usage. I really DO NO=
T care how we solve the problem as long as it's solved.=0A=0AI think your p=
oint that host-meta and LINK/REL solve the same problem is a fair one, it c=
ame up in the room.=C2=A0 Another comment in the room was that for JS based=
 stuff JSON is far easier to deal with than XML, and I think that's probabl=
y also really true, so there are some competing isues.=C2=A0 =0A=0A=0A-bill=
=0A=0A=0A=0A=0A>________________________________=0A> From: Eran Hammer =0A>To: William Mills ; Derek Atkins=
 ; "saag@ietf.org" ; "oauth@ietf.org"  =0A>Sent: Thursday, March 29, 2012 7:25 PM=0A>Subject: RE: [OAU=
TH-WG] OAUTH Report for IETF-83=0A> =0A>=0A>The narrative so far:=0A>=C2=A0=
=0A>The IETF has adopted host-meta as a general-purpose discovery mechanism=
 in RFC 6415.=0A>The OpenID Connect group, which utilizes OAuth but is out =
of scope for this WG, adopted SWD as its discovery mechanism.=0A>The propos=
ed charter references =E2=80=98OAuth Dynamic Client Registration Protocol=
=E2=80=99, which in turn references RFC 6415 as its discovery mechanism.=0A=
>=C2=A0=0A>Am I missing a WG item or proposed draft which relies on SWD at =
this time? If I am, are these documents included in the proposed charter or=
 are requested to be included (e.g. not SWT itself but other documents with=
 dependencies on it)? In such documents, is SWD a required component which =
cannot be substituted with something else such as RFC 6415?=0A>=C2=A0=0A>He=
re is how this process should work:=0A>=C2=A0=0A>1.=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 The WG agrees on including a discovery related item in its cha=
rter. The dynamic client registration is a reasonable such item.=0A>2.=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The charter references an existing propos=
al as foundation.=0A>3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The WG begins d=
iscussing the proposed draft (which can happen at any time on the list as l=
ong as the chairs allow it).=0A>4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The =
WG discusses any required enabling technologies, their suitability, maturit=
y, industry support, etc. In the case of dynamic registration, I expect the=
 WG to discuss SWD (because it is the technology selected by the OpenID sub=
set of this WG), host-meta (because it is an IETF proposed standard RFC), a=
s well as other solutions (Link headers, other well-known URIs, etc.). The =
publication status of the proposed technologies is another factor.=0A>5.=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If an enabling technology is decided to b=
e the most suitable, and is not available in normative reference form, the =
WG will discuss the best way to accomplish that. This includes identifying =
the right community, standards body, working group, etc. that is best to ta=
ke on the work. If no suitable venue is found, the WG may decide to take on=
 the work with very limited scope only to enable its own use cases.=0A>=C2=
=A0=0A>I am not opposed to having this discussion, but why are *we* having =
it *now*, other than the OpenID Connect group, which has nothing to do with=
 this WG, is stuck with the problem of finding a venue for this work, and a=
re dumping it on our laps?=0A>=C2=A0=0A>I do not recall this WG ever decide=
d (or even *proposed*) to use SWD for any of its chartered items. When we h=
ave this discussion, I expect it to include a detailed examination of host-=
meta and other solutions *as equal* alternatives. The OpenID Connect group =
preference is a valid input as it covers some potential market share with O=
Auth deployment, but it is *far* from any significant deployment worthy of =
bypassing this evaluation.=0A>=C2=A0=0A>Am I missing something here?=0A>=C2=
=A0=0A>EH=0A>=C2=A0=0A>=C2=A0=0A>=C2=A0=0A>=C2=A0=0A>=C2=A0=0A>From:William=
 Mills [mailto:wmills@yahoo-inc.com] =0A>Sent: Thursday, March 29, 2012 4:2=
6 PM=0A>To: Eran Hammer; Derek Atkins; saag@ietf.org; oauth@ietf.org=0A>Sub=
ject: Re: [OAUTH-WG] OAUTH Report for IETF-83=0A>=C2=A0=0A>On the SWD stuff=
 there was general discussion about "is this the right place?", and there "=
were issues raised".=C2=A0 The question was also asked "well, where is the =
right place?" which got crickets.=C2=A0 It is exactly coming back to the li=
st for discussion to sort out the right place.=0A>=C2=A0=0A>>=0A>>_________=
_______________________=0A>>=0A>>From:Eran Hammer =0A>=
>To: Derek Atkins ; "saag@ietf.org" ; "oaut=
h@ietf.org"  =0A>>Sent: Thursday, March 29, 2012 8:44 AM=0A=
>>Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83=0A>>=0A>>Hi Derek,=0A>>=
=0A>>Thanks for the notes. Is an audio recording available?=0A>>=0A>>> ----=
-Original Message-----=0A>>> From: oauth-bounces@ietf.org [mailto:oauth-bou=
nces@ietf.org] On Behalf=0A>>> Of Derek Atkins=0A>>> Sent: Thursday, March =
29, 2012 8:27 AM=0A>>> To: saag@ietf.org; oauth@ietf.org=0A>>> Subject: [OA=
UTH-WG] OAUTH Report for IETF-83=0A>>> =0A>>> Hi,=0A>>> =0A>>> OAUTH met ea=
rlier this afternoon in Afternoon Session I at 13h00 for a two=0A>>> hour s=
ession.=C2=A0 After introducing ourselves and welcoming me to the working=
=0A>>> group we thanked Barry and Blaine for their service.=0A>>> =0A>>> To=
rsten spoke about draft-ietf-oauth-v2-threatmodel.=C2=A0 This document has=
=0A>>> completed WG Last Call.=C2=A0 Torsten has applied changes based on t=
he Last Call=0A>>> Comments and has published a new revision.=C2=A0 Barry p=
romised to finish his=0A>>> PROTO Shepard review next week so we can send t=
his document to the=0A>>> IESG.=C2=A0 He promises to take Mike Thomas' issu=
es from the list into account and=0A>>> make sure that everyone is happy.=
=0A>>> =0A>>> [ I'd like to extend a personal thank you to Barry for contin=
uing his role=0A>>>=C2=A0 as document shephard for this draft.=C2=A0 -- der=
ek ]=0A>>> =0A>>> Next, Mike Jones spoke about the Assertions, SAML2 Bearer=
, and URN-Sub-=0A>>> NS drafts.=C2=A0 Except for one outstanding issue Mike=
 believes these documents=0A>>> are ready for WGLC.=C2=A0 Consensus in the =
room was to take these three docs to=0A>>> WGLC, which the chairs will do b=
y the end of next week.=0A>>> =0A>>> The MAC Token draft has languished whi=
le time was spent working on the=0A>>> core document.=C2=A0 Eran was not he=
re, nor was he online, to talk about the=0A>>> status of the MAC Token draf=
t.=C2=A0 There were only a few people in the room=0A>>> interested in revie=
wing the draft, which was not a clear consensus of=0A>>> interest, even tho=
ugh this document does solve a problem that the bearer=0A>>> tokens cannot.=
=C2=A0 The chairs will take it to the list to evaluate if there is enough=
=0A>>> interest to continue with this document.=0A>>=0A>>As I've updated th=
e list and chairs on multiple occasions, the draft is practically ready. Th=
ere was some late arriving feedback which I did not get around to process. =
However, the main issue is lack of WG interest in this work. I am still pla=
nning to finish it by making very minor tweaks to the current draft, but wo=
uld be very happy to make it an individual submission.=0A>>=0A>>The MAC dra=
ft has largely been my personal project to date.=0A>>=0A>>> In a related no=
te, this document (as well as the v2-bearer document) is not=0A>>> availabl=
e off the tools page even though it has not expired.=C2=A0 I have taken the=
=0A>>> action item to get that sorted out.=0A>>> =0A>>> Finally, we spent t=
he majority of our time talking about rechartering based on=0A>>> the propo=
sed charter sent to the list by Hannes a week or two ago.=0A>>> Consensus o=
f the room was that there was enough interest to recharter=0A>>> based roug=
hly on the proposed charter.=C2=A0 There was also consensus to include=0A>>=
> Simple Web Discovery (in addition to, and separate from, Dynamic Client=
=0A>>> Registration), although we will need to work with the ADs to make su=
re it=0A>>> gets handled in the appropriate WG and Area.=0A>>> Moreover, it=
's important to make sure the appropriate applications area=0A>>> participa=
nts get involved in the SWD work.=0A>>=0A>>There is something very awkward =
about discussing SWD both in the context of this working group, and in the =
context of future OAuth discovery work. The idea of picking a discovery mec=
hanism before the WG had a single discussion about what is included in disc=
overy and what are the use cases and requirement is absurd.=0A>>=0A>>There =
has not been consensus on the list for including SWD in the WG charter.=0A>=
>=0A>>The only justification I have heard so far for this WG to be the SWD =
venue is that it's easy because the author and a few other people intereste=
d are already here. That's not a valid reason.=0A>>=0A>>Any further work on=
 SWD also requires the IETF to view it in light of RFC 6415 (host-meta) whi=
ch is a proposed standard approved in October 2011. The IETF is not in the =
'flavor of the month' business. Proper process requires discussion about th=
e merits of redoing the host-meta work from scratch in a non-compatible way=
 just because a handful of people 'like it better' with little technical ju=
stification.=0A>>=0A>>Either way, this discussion does not belong here.=0A>=
>=0A>>EH=0A>>=0A>>_______________________________________________=0A>>OAuth=
 mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/=
oauth=0A>>=0A>>=0A>=0A>
--764183289-808086310-1333087994=:88149
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Thanks for the process lecture....  except we already had extensive =
discussion of same in the WG meeting...

<=
/div>
Partially this issue was raised because my draft does a dis=
covery thing and I want this sorted out to figure out what hooks I need to =
put in so I can get done.  I want to be consistent with whatever will =
be the chosen standardized usage. I really DO NOT care how we solve the pro=
blem as long as it's solved.

<=
span>I think your point that host-meta and LINK/REL solve the same problem =
is a fair one, it came up in the room.  Another comment in the room wa=
s that for JS based stuff JSON is far easier to deal with than XML, and I t=
hink that's probably also really true, so there are some competing
 isues.  

-bill=


  
 
 
  
  From:<=
/b> Eran Hammer <eran@hueniverse.com>
 To: William Mills <wmills@yahoo-inc.com>; Derek=
 Atkins <derek@ihtfp.com>; "saag@ietf.org" <saag@ietf.org>; "oa=
uth@ietf.org" <oauth@ietf.org> 
 Sent: Thursday, March 29, 2012 7:25 PM
 Subject: RE: [OAUTH-WG] OAUTH Report for=
 IETF-83

  
 
=0A
The narrative so far:
  
The IETF has adopted host-meta as a general-purpos=
e discovery mechanism in RFC 6415.
The OpenID Connect group, which utilizes OAuth but is out =
of scope for this WG, adopted SWD as its discovery mechanism.
<=
div class=3D"yiv117739012MsoNormal">The proposed charter references=
 =E2=80=98OAuth Dynamic
 Client Registration Protocol=E2=80=99, which in turn references RFC 6415 a=
s its discovery mechanism.
  
A=
m I missing a WG item or proposed draft which relies on SWD at this time? I=
f I am, are these documents included in the proposed charter or are request=
ed to be included (e.g. not SWT itself but other documents with dependencie=
s on it)? In such documents, is SWD a required component which cannot be su=
bstituted with something else such as RFC 6415?
  
Here is how this process should work:
  
1.       =
The WG agrees on including a=
 discovery related item in its charter. The dynamic client registration is =
a reasonable such item.
2.       The charter references an existing proposal =
as foundation.
3.       The WG begins discussing the proposed draft =
(which can happen at any time on the list as long as the chairs allow it).<=
/span>
=
4.       The WG discusses any required enabling techn=
ologies, their suitability, maturity, industry support, etc. In the case of=
 dynamic registration, I expect the WG to discuss SWD (because it is the te=
chnology selected by the OpenID subset of this WG), host-meta (because it i=
s an IETF proposed standard RFC), as well as other solutions (Link headers,=
 other well-known URIs, etc.). The publication status of the proposed techn=
ologies is another factor.
5.       If an enabling technology is decided to be the most suitable, and is not=
 available in normative reference form, the WG will discuss the best way to=
 accomplish that. This includes identifying the right community, standards =
body, working group, etc. that is best to take on the work. If no suitable =
venue is found, the WG may decide to take on the work with very limited sco=
pe only to enable its own use cases.
  
I am not opposed to having this discussion, but why are *we=
* having it *now*, other than the OpenID Connect group, which has no=
thing to do with this WG, is stuck with the problem of finding a venue for
 this work, and are dumping it on our laps?
  
I do not recall this WG ever decided (or even *proposed<=
/b>*) to use SWD for any of its chartered items. When we have this discussi=
on, I expect it to include a detailed examination of host-meta and other so=
lutions *as equal* alternatives. The OpenID Connect group preference=
 is a valid input as it covers some potential market share with OAuth deplo=
yment, but it is *far* from any significant deployment worthy of byp=
assing this evaluation.
  
Am I missing something here?
  
EH
  
  
<=
div class=3D"yiv117739012MsoNormal">  
  
  
From: William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Thursday, March 29, 2012 4:26 PM
To: Eran Hammer; Derek Atkins;=
 saag@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAUTH Repo=
rt for IETF-83
  
On the SWD stuff there was general discussion about "i=
s this the
 right place?", and there "were issues raised".  The question was also=
 asked "well, where is the right place?" which got crickets.  It is ex=
actly coming back to the list for discussion to sort out the right place.
  
From:=
 Eran Hammer <eran@hueniverse.com=
>
To: Derek Atkins <derek=
@ihtfp.com>; "saag@ietf.org" <saag@ietf.org>; "oa=
uth@ietf.org" <oauth@ietf.org> Sent: Thursday, March 29, 2012 8:44 AM
Subject: Re: [OAU=
TH-WG] OAUTH Report for IETF-83

Hi Derek,

Thanks for the notes. Is an audio recording av=
ailable?

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf> Of Derek Atkins
> Sent: Thursday, March 29, 2012 8:27 AM
>=
; To: saag@ietf.org; oauth@ietf.org
> Subject: [OAUTH-WG] OAUTH Report for IETF-83=

> 
> Hi,
>
 
> OAUTH met earlier this afternoon in Afternoon Session I at 13h00 =
for a two
> hour session.  After introducing ourselves and welco=
ming me to the working
> group we thanked Barry and Blaine for their =
service.
> 
> Torsten spoke about draft-ietf-oauth-v2-threatmod=
el.  This document has
> completed WG Last Call.  Torsten h=
as applied changes based on the Last Call
> Comments and has publishe=
d a new revision.  Barry promised to finish his
> PROTO Shepard =
review next week so we can send this document to the
> IESG.  He=
 promises to take Mike Thomas' issues from the list into account and
>=
; make sure that everyone is happy.
> 
> [ I'd like to extend a=
 personal thank you to Barry for continuing his role
>  as docum=
ent shephard for this draft.  -- derek ]
> 
> Next, Mike J=
ones spoke about the Assertions, SAML2 Bearer, and URN-Sub-
>
 NS drafts.  Except for one outstanding issue Mike believes these docu=
ments
> are ready for WGLC.  Consensus in the room was to take t=
hese three docs to
> WGLC, which the chairs will do by the end of nex=
t week.
> 
> The MAC Token draft has languished while time was =
spent working on the
> core document.  Eran was not here, nor wa=
s he online, to talk about the
> status of the MAC Token draft. =
 There were only a few people in the room
> interested in reviewing t=
he draft, which was not a clear consensus of
> interest, even though =
this document does solve a problem that the bearer
> tokens cannot.&n=
bsp; The chairs will take it to the list to evaluate if there is enough
=
> interest to continue with this document.

As I've updated the li=
st and chairs on multiple occasions, the draft is practically ready. There =
was some late arriving feedback which I did not get around to
 process. However, the main issue is lack of WG interest in this work. I am=
 still planning to finish it by making very minor tweaks to the current dra=
ft, but would be very happy to make it an individual submission.

The=
 MAC draft has largely been my personal project to date.

> In a r=
elated note, this document (as well as the v2-bearer document) is not
&g=
t; available off the tools page even though it has not expired.  I hav=
e taken the
> action item to get that sorted out.
> 
> Fi=
nally, we spent the majority of our time talking about rechartering based o=
n
> the proposed charter sent to the list by Hannes a week or two ago=
.
> Consensus of the room was that there was enough interest to recha=
rter
> based roughly on the proposed charter.  There was also co=
nsensus to include
> Simple Web Discovery (in addition to, and separa=
te from, Dynamic Client
> Registration), although we will need
 to work with the ADs to make sure it
> gets handled in the appropria=
te WG and Area.
> Moreover, it's important to make sure the appropria=
te applications area
> participants get involved in the SWD work.
=

There is something very awkward about discussing SWD both in the contex=
t of this working group, and in the context of future OAuth discovery work.=
 The idea of picking a discovery mechanism before the WG had a single discu=
ssion about what is included in discovery and what are the use cases and re=
quirement is absurd.

There has not been consensus on the list for in=
cluding SWD in the WG charter.

The only justification I have heard s=
o far for this WG to be the SWD venue is that it's easy because the author =
and a few other people interested are already here. That's not a valid reas=
on.

Any further work on SWD also requires the IETF to view it in lig=
ht of RFC 6415 (host-meta) which is a proposed standard approved in
 October 2011. The IETF is not in the 'flavor of the month' business. Prope=
r process requires discussion about the merits of redoing the host-meta wor=
k from scratch in a non-compatible way just because a handful of people 'li=
ke it better' with little technical justification.

Either way, this =
discussion does not belong here.

EH

_________________________=
______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf=
o/oauth

=



 
 
 
   

--764183289-808086310-1333087994=:88149--

From derek@ihtfp.com  Thu Mar 29 23:14:46 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B653A21F87C1; Thu, 29 Mar 2012 23:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.183
X-Spam-Level: 
X-Spam-Status: No, score=-101.183 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaLaUsyG--RO; Thu, 29 Mar 2012 23:14:43 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDB121F866B; Thu, 29 Mar 2012 23:14:43 -0700 (PDT)
Received: from [130.129.65.222] (dhcp-41de.meeting.ietf.org [130.129.65.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail2.ihtfp.org (Postfix) with ESMTPSA id F41FA26023A; Fri, 30 Mar 2012 02:14:40 -0400 (EDT)
To: "=?utf-8?B?RXJhbiBIYW1tZXI=?=" , "=?utf-8?B?V2lsbGlhbSBNaWxscw==?=" , "=?utf-8?B?c2FhZ0BpZXRmLm9yZw==?=" , "=?utf-8?B?b2F1dGhAaWV0Zi5vcmc=?=" 
From: "=?utf-8?B?RGVyZWsgQXRraW5z?=" 
Date: Fri, 30 Mar 2012 08:14:46 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_2_1333088086778"
Message-Id: <20120330061443.1FDB121F866B@ietfa.amsl.com>
Subject: Re: [OAUTH-WG] =?utf-8?q?OAUTH_Report_for_IETF-83?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 06:14:46 -0000

------=_Part_2_1333088086778
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

WWVzLCB5b3UgYXJlIG1pc3NpbmcgdGhlIG1lZXRpbmcgd2UgaGFkIHllc3RlcmRheSB3aGVyZSBp
dCB3YXMgZGlzY3Vzc2VkIHRvIGJlIGFkZGVkIHRvIHRoZSBjaGFydGVyLgoKLWRlcmVrLCBXRyBD
aGFpcgoKU2VudCBmcm9tIG15IEhUQyBvbiB0aGUgTm93IE5ldHdvcmsgZnJvbSBTcHJpbnQhCgot
LS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tCkZyb206ICJFcmFuIEhhbW1lciIgPGVyYW5AaHVlbml2
ZXJzZS5jb20+CkRhdGU6IEZyaSwgTWFyIDMwLCAyMDEyIDQ6MjUgYW0KU3ViamVjdDogW09BVVRI
LVdHXSBPQVVUSCBSZXBvcnQgZm9yIElFVEYtODMKVG86ICJXaWxsaWFtIE1pbGxzIiA8d21pbGxz
QHlhaG9vLWluYy5jb20+LCAiRGVyZWsgQXRraW5zIiA8ZGVyZWtAaWh0ZnAuY29tPiwgInNhYWdA
aWV0Zi5vcmciIDxzYWFnQGlldGYub3JnPiwgIm9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5v
cmc+Cgo=


------=_Part_2_1333088086778
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250
ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48
c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fW9cOioge2JlaGF2aW9yOnVy
bCgjZGVmYXVsdCNWTUwpO313XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9LnNoYXBl
IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9PC9zdHlsZT48IVtlbmRpZl0tLT48c3R5bGU+
PCEtLS8qIEZvbnQgRGVmaW5pdGlvbnMgKi9AZm9udC1mYWNlCXtmb250LWZhbWlseToiQ2FtYnJp
YSBNYXRoIjsJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9QGZvbnQtZmFjZQl7Zm9udC1m
YW1pbHk6Q2FsaWJyaTsJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fUBmb250LWZhY2UJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fS8qIFN0
eWxlIERlZmluaXRpb25zICovcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h
bAl7bWFyZ2luOjBpbjsJbWFyZ2luLWJvdHRvbTouMDAwMXB0Owlmb250LXNpemU6MTIuMHB0Owlm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO31hOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7CWNvbG9yOmJsdWU7CXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fWE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZAl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Owljb2xvcjpwdXJwbGU7CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7
fXAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsJbWFyZ2luOjBp
bjsJbWFyZ2luLWJvdHRvbTouMDAwMXB0Owlmb250LXNpemU6OC4wcHQ7CWZvbnQtZmFtaWx5OiJU
YWhvbWEiLCJzYW5zLXNlcmlmIjt9cC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy
YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaAl7bXNvLXN0eWxlLXByaW9yaXR5OjM0OwltYXJnaW4t
dG9wOjBpbjsJbWFyZ2luLXJpZ2h0OjBpbjsJbWFyZ2luLWJvdHRvbTowaW47CW1hcmdpbi1sZWZ0
Oi41aW47CW1hcmdpbi1ib3R0b206LjAwMDFwdDsJZm9udC1zaXplOjEyLjBwdDsJZm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9c3Bhbi5FbWFpbFN0eWxlMTcJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsLXJlcGx5Owlmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Owljb2xvcjojMUY0OTdEO31zcGFuLkJhbGxvb25UZXh0Q2hhcgl7bXNvLXN0eWxlLW5hbWU6IkJh
bGxvb24gVGV4dCBDaGFyIjsJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Owltc28tc3R5bGUtbGluazoi
QmFsbG9vbiBUZXh0IjsJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30uTXNvQ2hw
RGVmYXVsdAl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7CWZvbnQtc2l6ZToxMC4wcHQ7fUBw
YWdlIFdvcmRTZWN0aW9uMQl7c2l6ZTo4LjVpbiAxMS4waW47CW1hcmdpbjoxLjBpbiAxLjBpbiAx
LjBpbiAxLjBpbjt9ZGl2LldvcmRTZWN0aW9uMQl7cGFnZTpXb3JkU2VjdGlvbjE7fS8qIExpc3Qg
RGVmaW5pdGlvbnMgKi9AbGlzdCBsMAl7bXNvLWxpc3QtaWQ6MTcyMzc0NTc2MzsJbXNvLWxpc3Qt
dHlwZTpoeWJyaWQ7CW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDQ2MTI3NzQ2IDY3Njk4NzAzIDY3
Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4
NzEzIDY3Njk4NzE1O31AbGlzdCBsMDpsZXZlbDEJe21zby1sZXZlbC10YWItc3RvcDpub25lOwlt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7CXRleHQtaW5kZW50Oi0uMjVpbjt9QGxpc3Qg
bDA6bGV2ZWwyCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsJbXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsJdGV4dC1pbmRl
bnQ6LS4yNWluO31AbGlzdCBsMDpsZXZlbDMJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu
LWxvd2VyOwltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpyaWdodDsJdGV4dC1pbmRlbnQ6LTkuMHB0O31AbGlzdCBsMDpsZXZlbDQJe21zby1sZXZlbC10
YWItc3RvcDpub25lOwltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7CXRleHQtaW5kZW50
Oi0uMjVpbjt9QGxpc3QgbDA6bGV2ZWw1CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s
b3dlcjsJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsJdGV4dC1pbmRlbnQ6LS4yNWluO31AbGlzdCBsMDpsZXZlbDYJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OnJvbWFuLWxvd2VyOwltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpyaWdodDsJdGV4dC1pbmRlbnQ6LTkuMHB0O31AbGlzdCBsMDpsZXZl
bDcJe21zby1sZXZlbC10YWItc3RvcDpub25lOwltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7CXRleHQtaW5kZW50Oi0uMjVpbjt9QGxpc3QgbDA6bGV2ZWw4CXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDphbHBoYS1sb3dlcjsJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7CW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsJdGV4dC1pbmRlbnQ6LS4yNWluO31AbGlzdCBsMDpsZXZlbDkJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOwltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsJdGV4dC1pbmRlbnQ6LTkuMHB0
O31vbAl7bWFyZ2luLWJvdHRvbTowaW47fXVsCXttYXJnaW4tYm90dG9tOjBpbjt9LS0+PC9zdHls
ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD48bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
PjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij48bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i
MSIgLz48L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9
RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT5ZZXMsIHlvdSBhcmUgbWlzc2luZyB0aGUgbWVl
dGluZyB3ZSBoYWQgeWVzdGVyZGF5IHdoZXJlIGl0IHdhcyBkaXNjdXNzZWQgdG8gYmUgYWRkZWQg
dG8gdGhlIGNoYXJ0ZXIuPGJyPjxicj4tZGVyZWssIFdHIENoYWlyPGJyPjxicj5TZW50IGZyb20g
bXkgSFRDIG9uIHRoZSBOb3cgTmV0d29yayBmcm9tIFNwcmludCE8YnI+PGJyPjxkaXYgaWQ9Imh0
Y19oZWFkZXIiIHN0eWxlPSIiPi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS08YnI+RnJvbTogJnF1
b3Q7RXJhbiBIYW1tZXImcXVvdDsgJmx0O2VyYW5AaHVlbml2ZXJzZS5jb20mZ3Q7PGJyPkRhdGU6
IEZyaSwgTWFyIDMwLCAyMDEyIDQ6MjUgYW08YnI+U3ViamVjdDogW09BVVRILVdHXSBPQVVUSCBS
ZXBvcnQgZm9yIElFVEYtODM8YnI+VG86ICZxdW90O1dpbGxpYW0gTWlsbHMmcXVvdDsgJmx0O3dt
aWxsc0B5YWhvby1pbmMuY29tJmd0OywgJnF1b3Q7RGVyZWsgQXRraW5zJnF1b3Q7ICZsdDtkZXJl
a0BpaHRmcC5jb20mZ3Q7LCAmcXVvdDtzYWFnQGlldGYub3JnJnF1b3Q7ICZsdDtzYWFnQGlldGYu
b3JnJmd0OywgJnF1b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoQGlldGYub3JnJmd0
Ozxicj48YnI+PC9kaXY+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIG5hcnJhdGl2ZSBzbyBmYXI6PG86cD48L286cD48
L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj
MUY0OTdEJz5UaGUgSUVURiBoYXMgYWRvcHRlZCBob3N0LW1ldGEgYXMgYSBnZW5lcmFsLXB1cnBv
c2UgZGlzY292ZXJ5IG1lY2hhbmlzbSBpbiBSRkMgNjQxNS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIE9wZW5JRCBDb25u
ZWN0IGdyb3VwLCB3aGljaCB1dGlsaXplcyBPQXV0aCBidXQgaXMgb3V0IG9mIHNjb3BlIGZvciB0
aGlzIFdHLCBhZG9wdGVkIFNXRCBhcyBpdHMgZGlzY292ZXJ5IG1lY2hhbmlzbS48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhl
IHByb3Bvc2VkIGNoYXJ0ZXIgcmVmZXJlbmNlcyAmIzgyMTY7T0F1dGggRHluYW1pYyBDbGllbnQg
UmVnaXN0cmF0aW9uIFByb3RvY29sJiM4MjE3Oywgd2hpY2ggaW4gdHVybiByZWZlcmVuY2VzIFJG
QyA2NDE1IGFzIGl0cyBkaXNjb3ZlcnkgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QW0g
SSBtaXNzaW5nIGEgV0cgaXRlbSBvciBwcm9wb3NlZCBkcmFmdCB3aGljaCByZWxpZXMgb24gU1dE
IGF0IHRoaXMgdGltZT8gSWYgSSBhbSwgYXJlIHRoZXNlIGRvY3VtZW50cyBpbmNsdWRlZCBpbiB0
aGUgcHJvcG9zZWQgY2hhcnRlciBvciBhcmUgcmVxdWVzdGVkIHRvIGJlIGluY2x1ZGVkIChlLmcu
IG5vdCBTV1QgaXRzZWxmIGJ1dCBvdGhlciBkb2N1bWVudHMgd2l0aCBkZXBlbmRlbmNpZXMgb24g
aXQpPyBJbiBzdWNoIGRvY3VtZW50cywgaXMgU1dEIGEgcmVxdWlyZWQgY29tcG9uZW50IHdoaWNo
IGNhbm5vdCBiZSBzdWJzdGl0dXRlZCB3aXRoIHNvbWV0aGluZyBlbHNlIHN1Y2ggYXMgUkZDIDY0
MTU/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y
OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IZXJlIGlzIGhvdyB0aGlzIHByb2Nlc3Mgc2hvdWxkIHdv
cms6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y
OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy
YWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEn
PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9
J21zby1saXN0Oklnbm9yZSc+MS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJv
bWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+
PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9TFRSPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPlRoZSBXRyBhZ3JlZXMgb24gaW5jbHVkaW5nIGEgZGlzY292ZXJ5IHJlbGF0ZWQgaXRlbSBp
biBpdHMgY2hhcnRlci4gVGhlIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBpcyBhIHJlYXNv
bmFibGUgc3VjaCBpdGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy
YWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEn
PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9
J21zby1saXN0Oklnbm9yZSc+Mi48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJv
bWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+
PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9TFRSPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPlRoZSBjaGFydGVyIHJlZmVyZW5jZXMgYW4gZXhpc3RpbmcgcHJvcG9zYWwgYXMgZm91bmRh
dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHls
ZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3Vw
cG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJ
Z25vcmUnPjMuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl
bmRpZl0+PHNwYW4gZGlyPUxUUj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgV0cg
YmVnaW5zIGRpc2N1c3NpbmcgdGhlIHByb3Bvc2VkIGRyYWZ0ICh3aGljaCBjYW4gaGFwcGVuIGF0
IGFueSB0aW1lIG9uIHRoZSBsaXN0IGFzIGxvbmcgYXMgdGhlIGNoYWlycyBhbGxvdyBpdCkuPG86
cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQt
aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0
c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz40
LjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz
cGFuIGRpcj1MVFI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIFdHIGRpc2N1c3Nl
cyBhbnkgcmVxdWlyZWQgZW5hYmxpbmcgdGVjaG5vbG9naWVzLCB0aGVpciBzdWl0YWJpbGl0eSwg
bWF0dXJpdHksIGluZHVzdHJ5IHN1cHBvcnQsIGV0Yy4gSW4gdGhlIGNhc2Ugb2YgZHluYW1pYyBy
ZWdpc3RyYXRpb24sIEkgZXhwZWN0IHRoZSBXRyB0byBkaXNjdXNzIFNXRCAoYmVjYXVzZSBpdCBp
cyB0aGUgdGVjaG5vbG9neSBzZWxlY3RlZCBieSB0aGUgT3BlbklEIHN1YnNldCBvZiB0aGlzIFdH
KSwgaG9zdC1tZXRhIChiZWNhdXNlIGl0IGlzIGFuIElFVEYgcHJvcG9zZWQgc3RhbmRhcmQgUkZD
KSwgYXMgd2VsbCBhcyBvdGhlciBzb2x1dGlvbnMgKExpbmsgaGVhZGVycywgb3RoZXIgd2VsbC1r
bm93biBVUklzLCBldGMuKS4gVGhlIHB1YmxpY2F0aW9uIHN0YXR1cyBvZiB0aGUgcHJvcG9zZWQg
dGVjaG5vbG9naWVzIGlzIGFub3RoZXIgZmFjdG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6
bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3
RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+NS48c3BhbiBzdHlsZT0nZm9udDo3LjBw
dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9TFRSPjwvc3Bhbj48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiO2NvbG9yOiMxRjQ5N0QnPklmIGFuIGVuYWJsaW5nIHRlY2hub2xvZ3kgaXMgZGVjaWRlZCB0
byBiZSB0aGUgbW9zdCBzdWl0YWJsZSwgYW5kIGlzIG5vdCBhdmFpbGFibGUgaW4gbm9ybWF0aXZl
IHJlZmVyZW5jZSBmb3JtLCB0aGUgV0cgd2lsbCBkaXNjdXNzIHRoZSBiZXN0IHdheSB0byBhY2Nv
bXBsaXNoIHRoYXQuIFRoaXMgaW5jbHVkZXMgaWRlbnRpZnlpbmcgdGhlIHJpZ2h0IGNvbW11bml0
eSwgc3RhbmRhcmRzIGJvZHksIHdvcmtpbmcgZ3JvdXAsIGV0Yy4gdGhhdCBpcyBiZXN0IHRvIHRh
a2Ugb24gdGhlIHdvcmsuIElmIG5vIHN1aXRhYmxlIHZlbnVlIGlzIGZvdW5kLCB0aGUgV0cgbWF5
IGRlY2lkZSB0byB0YWtlIG9uIHRoZSB3b3JrIHdpdGggdmVyeSBsaW1pdGVkIHNjb3BlIG9ubHkg
dG8gZW5hYmxlIGl0cyBvd24gdXNlIGNhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBhbSBub3Qg
b3Bwb3NlZCB0byBoYXZpbmcgdGhpcyBkaXNjdXNzaW9uLCBidXQgd2h5IGFyZSAqPGI+d2U8L2I+
KiBoYXZpbmcgaXQgKjxiPm5vdzwvYj4qLCBvdGhlciB0aGFuIHRoZSBPcGVuSUQgQ29ubmVjdCBn
cm91cCwgd2hpY2ggaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGlzIFdHLCBpcyBzdHVjayB3aXRo
IHRoZSBwcm9ibGVtIG9mIGZpbmRpbmcgYSB2ZW51ZSBmb3IgdGhpcyB3b3JrLCBhbmQgYXJlIGR1
bXBpbmcgaXQgb24gb3VyIGxhcHM/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs
InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGRvIG5vdCByZWNhbGwg
dGhpcyBXRyBldmVyIGRlY2lkZWQgKG9yIGV2ZW4gKjxiPnByb3Bvc2VkPC9iPiopIHRvIHVzZSBT
V0QgZm9yIGFueSBvZiBpdHMgY2hhcnRlcmVkIGl0ZW1zLiBXaGVuIHdlIGhhdmUgdGhpcyBkaXNj
dXNzaW9uLCBJIGV4cGVjdCBpdCB0byBpbmNsdWRlIGEgZGV0YWlsZWQgZXhhbWluYXRpb24gb2Yg
aG9zdC1tZXRhIGFuZCBvdGhlciBzb2x1dGlvbnMgKjxiPmFzIGVxdWFsPC9iPiogYWx0ZXJuYXRp
dmVzLiBUaGUgT3BlbklEIENvbm5lY3QgZ3JvdXAgcHJlZmVyZW5jZSBpcyBhIHZhbGlkIGlucHV0
IGFzIGl0IGNvdmVycyBzb21lIHBvdGVudGlhbCBtYXJrZXQgc2hhcmUgd2l0aCBPQXV0aCBkZXBs
b3ltZW50LCBidXQgaXQgaXMgKjxiPmZhcjwvYj4qIGZyb20gYW55IHNpZ25pZmljYW50IGRlcGxv
eW1lbnQgd29ydGh5IG9mIGJ5cGFzc2luZyB0aGlzIGV2YWx1YXRpb24uPG86cD48L286cD48L3Nw
YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0
OTdEJz5BbSBJIG1pc3Npbmcgc29tZXRoaW5nIGhlcmU/PG86cD48L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FSDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0
OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48
ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU
YWhvbWEiLCJzYW5zLXNlcmlmIic+IFdpbGxpYW0gTWlsbHMgW21haWx0bzp3bWlsbHNAeWFob28t
aW5jLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggMjksIDIwMTIgNDoyNiBQ
TTxicj48Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyOyBEZXJlayBBdGtpbnM7IHNhYWdAaWV0Zi5vcmc7
IG9hdXRoQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQVVUSCBS
ZXBvcnQgZm9yIElFVEYtODM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xh
c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O
b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTQu
MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPk9uIHRoZSBTV0Qgc3R1
ZmYgdGhlcmUgd2FzIGdlbmVyYWwgZGlzY3Vzc2lvbiBhYm91dCAmcXVvdDtpcyB0aGlzIHRoZSBy
aWdodCBwbGFjZT8mcXVvdDssIGFuZCB0aGVyZSAmcXVvdDt3ZXJlIGlzc3VlcyByYWlzZWQmcXVv
dDsuJm5ic3A7IFRoZSBxdWVzdGlvbiB3YXMgYWxzbyBhc2tlZCAmcXVvdDt3ZWxsLCB3aGVyZSBp
cyB0aGUgcmlnaHQgcGxhY2U/JnF1b3Q7IHdoaWNoIGdvdCBjcmlja2V0cy4mbmJzcDsgSXQgaXMg
ZXhhY3RseSBjb21pbmcgYmFjayB0byB0aGUgbGlzdCBmb3IgZGlzY3Vzc2lvbiB0byBzb3J0IG91
dCB0aGUgcmlnaHQgcGxhY2UuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGJsb2Nr
cXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7
cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDoz
Ljc1cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNr
Z3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseToi
Q291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRp
dj48ZGl2PjxkaXY+PGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0
LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PGhyIHNp
emU9MSB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPjwvc3Bhbj48L2Rpdj48cCBjbGFzcz1Nc29O
b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9t
Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy
aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiBFcmFuIEhhbW1lciAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+Jmd0Ozxi
cj48Yj5Ubzo8L2I+IERlcmVrIEF0a2lucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRlcmVrQGlodGZw
LmNvbSI+ZGVyZWtAaWh0ZnAuY29tPC9hPiZndDs7ICZxdW90OzxhIGhyZWY9Im1haWx0bzpzYWFn
QGlldGYub3JnIj5zYWFnQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNh
YWdAaWV0Zi5vcmciPnNhYWdAaWV0Zi5vcmc8L2E+Jmd0OzsgJnF1b3Q7PGEgaHJlZj0ibWFpbHRv
Om9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h
aWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OyA8YnI+PGI+U2VudDo8
L2I+IFRodXJzZGF5LCBNYXJjaCAyOSwgMjAxMiA4OjQ0IEFNPGJyPjxiPlN1YmplY3Q6PC9iPiBS
ZTogW09BVVRILVdHXSBPQVVUSCBSZXBvcnQgZm9yIElFVEYtODM8L3NwYW4+PHNwYW4gc3R5bGU9
J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9y
bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz
dHlsZT0nY29sb3I6YmxhY2snPjxicj5IaSBEZXJlayw8YnI+PGJyPlRoYW5rcyBmb3IgdGhlIG5v
dGVzLiBJcyBhbiBhdWRpbyByZWNvcmRpbmcgYXZhaWxhYmxlPzxicj48YnI+Jmd0OyAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhy
ZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3Jn
PC9hPl0gT24gQmVoYWxmPGJyPiZndDsgT2YgRGVyZWsgQXRraW5zPGJyPiZndDsgU2VudDogVGh1
cnNkYXksIE1hcmNoIDI5LCAyMDEyIDg6MjcgQU08YnI+Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRv
OnNhYWdAaWV0Zi5vcmciPnNhYWdAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86b2F1dGhA
aWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4mZ3Q7IFN1YmplY3Q6IFtPQVVUSC1XR10g
T0FVVEggUmVwb3J0IGZvciBJRVRGLTgzPGJyPiZndDsgPGJyPiZndDsgSGksPGJyPiZndDsgPGJy
PiZndDsgT0FVVEggbWV0IGVhcmxpZXIgdGhpcyBhZnRlcm5vb24gaW4gQWZ0ZXJub29uIFNlc3Np
b24gSSBhdCAxM2gwMCBmb3IgYSB0d288YnI+Jmd0OyBob3VyIHNlc3Npb24uJm5ic3A7IEFmdGVy
IGludHJvZHVjaW5nIG91cnNlbHZlcyBhbmQgd2VsY29taW5nIG1lIHRvIHRoZSB3b3JraW5nPGJy
PiZndDsgZ3JvdXAgd2UgdGhhbmtlZCBCYXJyeSBhbmQgQmxhaW5lIGZvciB0aGVpciBzZXJ2aWNl
Ljxicj4mZ3Q7IDxicj4mZ3Q7IFRvcnN0ZW4gc3Bva2UgYWJvdXQgZHJhZnQtaWV0Zi1vYXV0aC12
Mi10aHJlYXRtb2RlbC4mbmJzcDsgVGhpcyBkb2N1bWVudCBoYXM8YnI+Jmd0OyBjb21wbGV0ZWQg
V0cgTGFzdCBDYWxsLiZuYnNwOyBUb3JzdGVuIGhhcyBhcHBsaWVkIGNoYW5nZXMgYmFzZWQgb24g
dGhlIExhc3QgQ2FsbDxicj4mZ3Q7IENvbW1lbnRzIGFuZCBoYXMgcHVibGlzaGVkIGEgbmV3IHJl
dmlzaW9uLiZuYnNwOyBCYXJyeSBwcm9taXNlZCB0byBmaW5pc2ggaGlzPGJyPiZndDsgUFJPVE8g
U2hlcGFyZCByZXZpZXcgbmV4dCB3ZWVrIHNvIHdlIGNhbiBzZW5kIHRoaXMgZG9jdW1lbnQgdG8g
dGhlPGJyPiZndDsgSUVTRy4mbmJzcDsgSGUgcHJvbWlzZXMgdG8gdGFrZSBNaWtlIFRob21hcycg
aXNzdWVzIGZyb20gdGhlIGxpc3QgaW50byBhY2NvdW50IGFuZDxicj4mZ3Q7IG1ha2Ugc3VyZSB0
aGF0IGV2ZXJ5b25lIGlzIGhhcHB5Ljxicj4mZ3Q7IDxicj4mZ3Q7IFsgSSdkIGxpa2UgdG8gZXh0
ZW5kIGEgcGVyc29uYWwgdGhhbmsgeW91IHRvIEJhcnJ5IGZvciBjb250aW51aW5nIGhpcyByb2xl
PGJyPiZndDsmbmJzcDsgYXMgZG9jdW1lbnQgc2hlcGhhcmQgZm9yIHRoaXMgZHJhZnQuJm5ic3A7
IC0tIGRlcmVrIF08YnI+Jmd0OyA8YnI+Jmd0OyBOZXh0LCBNaWtlIEpvbmVzIHNwb2tlIGFib3V0
IHRoZSBBc3NlcnRpb25zLCBTQU1MMiBCZWFyZXIsIGFuZCBVUk4tU3ViLTxicj4mZ3Q7IE5TIGRy
YWZ0cy4mbmJzcDsgRXhjZXB0IGZvciBvbmUgb3V0c3RhbmRpbmcgaXNzdWUgTWlrZSBiZWxpZXZl
cyB0aGVzZSBkb2N1bWVudHM8YnI+Jmd0OyBhcmUgcmVhZHkgZm9yIFdHTEMuJm5ic3A7IENvbnNl
bnN1cyBpbiB0aGUgcm9vbSB3YXMgdG8gdGFrZSB0aGVzZSB0aHJlZSBkb2NzIHRvPGJyPiZndDsg
V0dMQywgd2hpY2ggdGhlIGNoYWlycyB3aWxsIGRvIGJ5IHRoZSBlbmQgb2YgbmV4dCB3ZWVrLjxi
cj4mZ3Q7IDxicj4mZ3Q7IFRoZSBNQUMgVG9rZW4gZHJhZnQgaGFzIGxhbmd1aXNoZWQgd2hpbGUg
dGltZSB3YXMgc3BlbnQgd29ya2luZyBvbiB0aGU8YnI+Jmd0OyBjb3JlIGRvY3VtZW50LiZuYnNw
OyBFcmFuIHdhcyBub3QgaGVyZSwgbm9yIHdhcyBoZSBvbmxpbmUsIHRvIHRhbGsgYWJvdXQgdGhl
PGJyPiZndDsgc3RhdHVzIG9mIHRoZSBNQUMgVG9rZW4gZHJhZnQuJm5ic3A7IFRoZXJlIHdlcmUg
b25seSBhIGZldyBwZW9wbGUgaW4gdGhlIHJvb208YnI+Jmd0OyBpbnRlcmVzdGVkIGluIHJldmll
d2luZyB0aGUgZHJhZnQsIHdoaWNoIHdhcyBub3QgYSBjbGVhciBjb25zZW5zdXMgb2Y8YnI+Jmd0
OyBpbnRlcmVzdCwgZXZlbiB0aG91Z2ggdGhpcyBkb2N1bWVudCBkb2VzIHNvbHZlIGEgcHJvYmxl
bSB0aGF0IHRoZSBiZWFyZXI8YnI+Jmd0OyB0b2tlbnMgY2Fubm90LiZuYnNwOyBUaGUgY2hhaXJz
IHdpbGwgdGFrZSBpdCB0byB0aGUgbGlzdCB0byBldmFsdWF0ZSBpZiB0aGVyZSBpcyBlbm91Z2g8
YnI+Jmd0OyBpbnRlcmVzdCB0byBjb250aW51ZSB3aXRoIHRoaXMgZG9jdW1lbnQuPGJyPjxicj5B
cyBJJ3ZlIHVwZGF0ZWQgdGhlIGxpc3QgYW5kIGNoYWlycyBvbiBtdWx0aXBsZSBvY2Nhc2lvbnMs
IHRoZSBkcmFmdCBpcyBwcmFjdGljYWxseSByZWFkeS4gVGhlcmUgd2FzIHNvbWUgbGF0ZSBhcnJp
dmluZyBmZWVkYmFjayB3aGljaCBJIGRpZCBub3QgZ2V0IGFyb3VuZCB0byBwcm9jZXNzLiBIb3dl
dmVyLCB0aGUgbWFpbiBpc3N1ZSBpcyBsYWNrIG9mIFdHIGludGVyZXN0IGluIHRoaXMgd29yay4g
SSBhbSBzdGlsbCBwbGFubmluZyB0byBmaW5pc2ggaXQgYnkgbWFraW5nIHZlcnkgbWlub3IgdHdl
YWtzIHRvIHRoZSBjdXJyZW50IGRyYWZ0LCBidXQgd291bGQgYmUgdmVyeSBoYXBweSB0byBtYWtl
IGl0IGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbi48YnI+PGJyPlRoZSBNQUMgZHJhZnQgaGFzIGxh
cmdlbHkgYmVlbiBteSBwZXJzb25hbCBwcm9qZWN0IHRvIGRhdGUuPGJyPjxicj4mZ3Q7IEluIGEg
cmVsYXRlZCBub3RlLCB0aGlzIGRvY3VtZW50IChhcyB3ZWxsIGFzIHRoZSB2Mi1iZWFyZXIgZG9j
dW1lbnQpIGlzIG5vdDxicj4mZ3Q7IGF2YWlsYWJsZSBvZmYgdGhlIHRvb2xzIHBhZ2UgZXZlbiB0
aG91Z2ggaXQgaGFzIG5vdCBleHBpcmVkLiZuYnNwOyBJIGhhdmUgdGFrZW4gdGhlPGJyPiZndDsg
YWN0aW9uIGl0ZW0gdG8gZ2V0IHRoYXQgc29ydGVkIG91dC48YnI+Jmd0OyA8YnI+Jmd0OyBGaW5h
bGx5LCB3ZSBzcGVudCB0aGUgbWFqb3JpdHkgb2Ygb3VyIHRpbWUgdGFsa2luZyBhYm91dCByZWNo
YXJ0ZXJpbmcgYmFzZWQgb248YnI+Jmd0OyB0aGUgcHJvcG9zZWQgY2hhcnRlciBzZW50IHRvIHRo
ZSBsaXN0IGJ5IEhhbm5lcyBhIHdlZWsgb3IgdHdvIGFnby48YnI+Jmd0OyBDb25zZW5zdXMgb2Yg
dGhlIHJvb20gd2FzIHRoYXQgdGhlcmUgd2FzIGVub3VnaCBpbnRlcmVzdCB0byByZWNoYXJ0ZXI8
YnI+Jmd0OyBiYXNlZCByb3VnaGx5IG9uIHRoZSBwcm9wb3NlZCBjaGFydGVyLiZuYnNwOyBUaGVy
ZSB3YXMgYWxzbyBjb25zZW5zdXMgdG8gaW5jbHVkZTxicj4mZ3Q7IFNpbXBsZSBXZWIgRGlzY292
ZXJ5IChpbiBhZGRpdGlvbiB0bywgYW5kIHNlcGFyYXRlIGZyb20sIER5bmFtaWMgQ2xpZW50PGJy
PiZndDsgUmVnaXN0cmF0aW9uKSwgYWx0aG91Z2ggd2Ugd2lsbCBuZWVkIHRvIHdvcmsgd2l0aCB0
aGUgQURzIHRvIG1ha2Ugc3VyZSBpdDxicj4mZ3Q7IGdldHMgaGFuZGxlZCBpbiB0aGUgYXBwcm9w
cmlhdGUgV0cgYW5kIEFyZWEuPGJyPiZndDsgTW9yZW92ZXIsIGl0J3MgaW1wb3J0YW50IHRvIG1h
a2Ugc3VyZSB0aGUgYXBwcm9wcmlhdGUgYXBwbGljYXRpb25zIGFyZWE8YnI+Jmd0OyBwYXJ0aWNp
cGFudHMgZ2V0IGludm9sdmVkIGluIHRoZSBTV0Qgd29yay48YnI+PGJyPlRoZXJlIGlzIHNvbWV0
aGluZyB2ZXJ5IGF3a3dhcmQgYWJvdXQgZGlzY3Vzc2luZyBTV0QgYm90aCBpbiB0aGUgY29udGV4
dCBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAsIGFuZCBpbiB0aGUgY29udGV4dCBvZiBmdXR1cmUgT0F1
dGggZGlzY292ZXJ5IHdvcmsuIFRoZSBpZGVhIG9mIHBpY2tpbmcgYSBkaXNjb3ZlcnkgbWVjaGFu
aXNtIGJlZm9yZSB0aGUgV0cgaGFkIGEgc2luZ2xlIGRpc2N1c3Npb24gYWJvdXQgd2hhdCBpcyBp
bmNsdWRlZCBpbiBkaXNjb3ZlcnkgYW5kIHdoYXQgYXJlIHRoZSB1c2UgY2FzZXMgYW5kIHJlcXVp
cmVtZW50IGlzIGFic3VyZC48YnI+PGJyPlRoZXJlIGhhcyBub3QgYmVlbiBjb25zZW5zdXMgb24g
dGhlIGxpc3QgZm9yIGluY2x1ZGluZyBTV0QgaW4gdGhlIFdHIGNoYXJ0ZXIuPGJyPjxicj5UaGUg
b25seSBqdXN0aWZpY2F0aW9uIEkgaGF2ZSBoZWFyZCBzbyBmYXIgZm9yIHRoaXMgV0cgdG8gYmUg
dGhlIFNXRCB2ZW51ZSBpcyB0aGF0IGl0J3MgZWFzeSBiZWNhdXNlIHRoZSBhdXRob3IgYW5kIGEg
ZmV3IG90aGVyIHBlb3BsZSBpbnRlcmVzdGVkIGFyZSBhbHJlYWR5IGhlcmUuIFRoYXQncyBub3Qg
YSB2YWxpZCByZWFzb24uPGJyPjxicj5BbnkgZnVydGhlciB3b3JrIG9uIFNXRCBhbHNvIHJlcXVp
cmVzIHRoZSBJRVRGIHRvIHZpZXcgaXQgaW4gbGlnaHQgb2YgUkZDIDY0MTUgKGhvc3QtbWV0YSkg
d2hpY2ggaXMgYSBwcm9wb3NlZCBzdGFuZGFyZCBhcHByb3ZlZCBpbiBPY3RvYmVyIDIwMTEuIFRo
ZSBJRVRGIGlzIG5vdCBpbiB0aGUgJ2ZsYXZvciBvZiB0aGUgbW9udGgnIGJ1c2luZXNzLiBQcm9w
ZXIgcHJvY2VzcyByZXF1aXJlcyBkaXNjdXNzaW9uIGFib3V0IHRoZSBtZXJpdHMgb2YgcmVkb2lu
ZyB0aGUgaG9zdC1tZXRhIHdvcmsgZnJvbSBzY3JhdGNoIGluIGEgbm9uLWNvbXBhdGlibGUgd2F5
IGp1c3QgYmVjYXVzZSBhIGhhbmRmdWwgb2YgcGVvcGxlICdsaWtlIGl0IGJldHRlcicgd2l0aCBs
aXR0bGUgdGVjaG5pY2FsIGp1c3RpZmljYXRpb24uPGJyPjxicj5FaXRoZXIgd2F5LCB0aGlzIGRp
c2N1c3Npb24gZG9lcyBub3QgYmVsb25nIGhlcmUuPGJyPjxicj5FSDxicj48YnI+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGluZyBs
aXN0PGJyPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+
PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi
IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoPC9hPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2tx
dW90ZT48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg==


------=_Part_2_1333088086778--


From derek@ihtfp.com  Thu Mar 29 23:22:42 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F0E21E8037; Thu, 29 Mar 2012 23:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.915
X-Spam-Level: 
X-Spam-Status: No, score=-100.915 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9qso9q8luq1; Thu, 29 Mar 2012 23:22:42 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id B99F521E802D; Thu, 29 Mar 2012 23:22:41 -0700 (PDT)
Received: from [130.129.65.222] (dhcp-41de.meeting.ietf.org [130.129.65.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail2.ihtfp.org (Postfix) with ESMTPSA id 270AD260268; Fri, 30 Mar 2012 02:22:40 -0400 (EDT)
To: "=?utf-8?B?V2lsbGlhbSBNaWxscw==?=" , "=?utf-8?B?RXJhbiBIYW1tZXI=?=" , "=?utf-8?B?c2FhZ0BpZXRmLm9yZw==?=" , "=?utf-8?B?b2F1dGhAaWV0Zi5vcmc=?=" 
From: "=?utf-8?B?RGVyZWsgQXRraW5z?=" 
Date: Fri, 30 Mar 2012 08:22:45 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3_1333088565926"
Message-Id: <20120330062241.B99F521E802D@ietfa.amsl.com>
Subject: Re: [OAUTH-WG] =?utf-8?q?OAUTH_Report_for_IETF-83?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 06:22:43 -0000

------=_Part_3_1333088565926
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

Q29ycmVjdC4KClNXRCBtYXkgb3IgbWF5IG5vdCBoYXBwZW4gaW4gdGhpcyBncm91cC4gVGhlIGlt
cG9ydGFudCBwYXJ0IGlzIGdldHRpbmcgdGhlIHJpZ2h0IHBlb3BsZSBpbiB0aGUgc2FtZSByb29t
IHRvIHdvcmsgb24gaXQuICBJZiB0aGF0IGlzIGhlcmUsIGdyZWF0LiBJZiB0aGF0IGlzIGluIGl0
cyBvd24gZ3JvdXAsIHRoYXQncyBncmVhdCB0b28uICBJZiBpdCB3b24ndCBoYXBwZW4gaW4gYW5v
dGhlciBncm91cCBhbmQgaWYgcGVvcGxlIGhlcmUgYXJlIHdhbnRpbmcgaXQsIHRoZW4gdGhhdCB3
b3VsZCBpbXBseSB0aGlzIGlzIHRoZSByaWdodCBwbGFjZS4KCldlIGNhbiBkaXNjdXNzIHdoZXRo
ZXIgU1dEIGlzIG5lZWRlZCwgYnV0IHRoZXJlIHdhcyBjZXJ0YWlubHkgaW50ZXJlc3QgaW4gdGhl
IFdHIG1lZXRpbmcgeWVzdGVyZGF5LgoKLWRlcmVrCgpTZW50IGZyb20gbXkgSFRDIG9uIHRoZSBO
b3cgTmV0d29yayBmcm9tIFNwcmludCEKCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJvbTog
IldpbGxpYW0gTWlsbHMiIDx3bWlsbHNAeWFob28taW5jLmNvbT4KRGF0ZTogRnJpLCBNYXIgMzAs
IDIwMTIgMToyNiBhbQpTdWJqZWN0OiBbT0FVVEgtV0ddIE9BVVRIIFJlcG9ydCBmb3IgSUVURi04
MwpUbzogIkVyYW4gSGFtbWVyIiA8ZXJhbkBodWVuaXZlcnNlLmNvbT4sICJEZXJlayBBdGtpbnMi
IDxkZXJla0BpaHRmcC5jb20+LCAic2FhZ0BpZXRmLm9yZyIgPHNhYWdAaWV0Zi5vcmc+LCAib2F1
dGhAaWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4KCg==


------=_Part_3_1333088565926
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

PGh0bWw+PGJvZHk+Q29ycmVjdC48YnI+PGJyPlNXRCBtYXkgb3IgbWF5IG5vdCBoYXBwZW4gaW4g
dGhpcyBncm91cC4gVGhlIGltcG9ydGFudCBwYXJ0IGlzIGdldHRpbmcgdGhlIHJpZ2h0IHBlb3Bs
ZSBpbiB0aGUgc2FtZSByb29tIHRvIHdvcmsgb24gaXQuICZuYnNwO0lmIHRoYXQgaXMgaGVyZSwg
Z3JlYXQuIElmIHRoYXQgaXMgaW4gaXRzIG93biBncm91cCwgdGhhdCYjMzk7cyBncmVhdCB0b28u
ICZuYnNwO0lmIGl0IHdvbiYjMzk7dCBoYXBwZW4gaW4gYW5vdGhlciBncm91cCBhbmQgaWYgcGVv
cGxlIGhlcmUgYXJlIHdhbnRpbmcgaXQsIHRoZW4gdGhhdCB3b3VsZCBpbXBseSB0aGlzIGlzIHRo
ZSByaWdodCBwbGFjZS48YnI+PGJyPldlIGNhbiBkaXNjdXNzIHdoZXRoZXIgU1dEIGlzIG5lZWRl
ZCwgYnV0IHRoZXJlIHdhcyBjZXJ0YWlubHkgaW50ZXJlc3QgaW4gdGhlIFdHIG1lZXRpbmcgeWVz
dGVyZGF5Ljxicj48YnI+LWRlcmVrPGJyPjxicj5TZW50IGZyb20gbXkgSFRDIG9uIHRoZSBOb3cg
TmV0d29yayBmcm9tIFNwcmludCE8YnI+PGJyPjxkaXYgaWQ9Imh0Y19oZWFkZXIiIHN0eWxlPSIi
Pi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS08YnI+RnJvbTogJnF1b3Q7V2lsbGlhbSBNaWxscyZx
dW90OyAmbHQ7d21pbGxzQHlhaG9vLWluYy5jb20mZ3Q7PGJyPkRhdGU6IEZyaSwgTWFyIDMwLCAy
MDEyIDE6MjYgYW08YnI+U3ViamVjdDogW09BVVRILVdHXSBPQVVUSCBSZXBvcnQgZm9yIElFVEYt
ODM8YnI+VG86ICZxdW90O0VyYW4gSGFtbWVyJnF1b3Q7ICZsdDtlcmFuQGh1ZW5pdmVyc2UuY29t
Jmd0OywgJnF1b3Q7RGVyZWsgQXRraW5zJnF1b3Q7ICZsdDtkZXJla0BpaHRmcC5jb20mZ3Q7LCAm
cXVvdDtzYWFnQGlldGYub3JnJnF1b3Q7ICZsdDtzYWFnQGlldGYub3JnJmd0OywgJnF1b3Q7b2F1
dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj48YnI+PC9kaXY+PGRp
diBzdHlsZT0iY29sb3I6IzAwMDsgYmFja2dyb3VuZC1jb2xvcjojZmZmOyBmb250LWZhbWlseTpD
b3VyaWVyIE5ldywgY291cmllciwgbW9uYWNvLCBtb25vc3BhY2UsIHNhbnMtc2VyaWY7Zm9udC1z
aXplOjE0cHQiPjxkaXY+PHNwYW4+T24gdGhlIFNXRCBzdHVmZiB0aGVyZSB3YXMgZ2VuZXJhbCBk
aXNjdXNzaW9uIGFib3V0ICJpcyB0aGlzIHRoZSByaWdodCBwbGFjZT8iLCBhbmQgdGhlcmUgIndl
cmUgaXNzdWVzIHJhaXNlZCIuJm5ic3A7IFRoZSBxdWVzdGlvbiB3YXMgYWxzbyBhc2tlZCAid2Vs
bCwgd2hlcmUgaXMgdGhlIHJpZ2h0IHBsYWNlPyIgd2hpY2ggZ290IGNyaWNrZXRzLiZuYnNwOyBJ
dCBpcyBleGFjdGx5IGNvbWluZyBiYWNrIHRvIHRoZSBsaXN0IGZvciBkaXNjdXNzaW9uIHRvIHNv
cnQgb3V0IHRoZSByaWdodCBwbGFjZS48YnI+PC9zcGFuPjwvZGl2PjxkaXY+PGJyPjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXItbGVmdDogMnB4IHNvbGlkIHJnYigxNiwgMTYsIDI1NSk7IG1hcmdp
bi1sZWZ0OiA1cHg7IG1hcmdpbi10b3A6IDVweDsgcGFkZGluZy1sZWZ0OiA1cHg7Ij4gIDxkaXYg
c3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyIE5ldywgY291cmllciwgbW9uYWNvLCBtb25vc3Bh
Y2UsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRwdDsiPiA8ZGl2IHN0eWxlPSJmb250LWZhbWls
eTogdGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmOyBmb250LXNpemU6IDEy
cHQ7Ij4gPGRpdiBkaXI9Imx0ciI+IDxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIj4gPGhyIHNp
emU9IjEiPiAgPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQ7Ij5Gcm9tOjwvc3Bhbj48
L2I+IEVyYW4gSGFtbWVyICZsdDtlcmFuQGh1ZW5pdmVyc2UuY29tJmd0Ozxicj4gPGI+PHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+VG86PC9zcGFuPjwvYj4KIERlcmVrIEF0a2lucyAm
bHQ7ZGVyZWtAaWh0ZnAuY29tJmd0OzsgInNhYWdAaWV0Zi5vcmciICZsdDtzYWFnQGlldGYub3Jn
Jmd0OzsgIm9hdXRoQGlldGYub3JnIiAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7IDxicj4gPGI+PHNw
YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+U2VudDo8L3NwYW4+PC9iPiBUaHVyc2RheSwg
TWFyY2ggMjksIDIwMTIgODo0NCBBTTxicj4gPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBi
b2xkOyI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW09BVVRILVdHXSBPQVVUSCBSZXBvcnQgZm9y
IElFVEYtODM8YnI+IDwvZm9udD4gPC9kaXY+IDxicj4KSGkgRGVyZWssPGJyPjxicj5UaGFua3Mg
Zm9yIHRoZSBub3Rlcy4gSXMgYW4gYXVkaW8gcmVjb3JkaW5nIGF2YWlsYWJsZT88YnI+PGJyPiZn
dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyBGcm9tOiA8YSB5bWFpbHRvPSJt
YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNA
aWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgeW1haWx0bz0i
bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmPGJyPiZndDsg
T2YgRGVyZWsgQXRraW5zPGJyPiZndDsgU2VudDogVGh1cnNkYXksIE1hcmNoIDI5LCAyMDEyIDg6
MjcgQU08YnI+Jmd0OyBUbzogPGEgeW1haWx0bz0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciIGhyZWY9
Im1haWx0bzpzYWFnQGlldGYub3JnIj5zYWFnQGlldGYub3JnPC9hPjsgPGEgeW1haWx0bz0ibWFp
bHRvOm9hdXRoQGlldGYub3JnIiBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGll
dGYub3JnPC9hPjxicj4mZ3Q7IFN1YmplY3Q6IFtPQVVUSC1XR10gT0FVVEggUmVwb3J0IGZvciBJ
RVRGLTgzPGJyPiZndDsgPGJyPiZndDsgSGksPGJyPiZndDsgPGJyPiZndDsgT0FVVEggbWV0IGVh
cmxpZXIgdGhpcyBhZnRlcm5vb24gaW4gQWZ0ZXJub29uIFNlc3Npb24gSSBhdCAxM2gwMCBmb3Ig
YSB0d288YnI+Jmd0OyBob3VyIHNlc3Npb24uJm5ic3A7IEFmdGVyIGludHJvZHVjaW5nIG91cnNl
bHZlcyBhbmQgd2VsY29taW5nIG1lIHRvIHRoZSB3b3JraW5nPGJyPiZndDsgZ3JvdXAgd2UgdGhh
bmtlZCBCYXJyeSBhbmQgQmxhaW5lIGZvciB0aGVpciBzZXJ2aWNlLjxicj4mZ3Q7IDxicj4mZ3Q7
IFRvcnN0ZW4gc3Bva2UgYWJvdXQKIGRyYWZ0LWlldGYtb2F1dGgtdjItdGhyZWF0bW9kZWwuJm5i
c3A7IFRoaXMgZG9jdW1lbnQgaGFzPGJyPiZndDsgY29tcGxldGVkIFdHIExhc3QgQ2FsbC4mbmJz
cDsgVG9yc3RlbiBoYXMgYXBwbGllZCBjaGFuZ2VzIGJhc2VkIG9uIHRoZSBMYXN0IENhbGw8YnI+
Jmd0OyBDb21tZW50cyBhbmQgaGFzIHB1Ymxpc2hlZCBhIG5ldyByZXZpc2lvbi4mbmJzcDsgQmFy
cnkgcHJvbWlzZWQgdG8gZmluaXNoIGhpczxicj4mZ3Q7IFBST1RPIFNoZXBhcmQgcmV2aWV3IG5l
eHQgd2VlayBzbyB3ZSBjYW4gc2VuZCB0aGlzIGRvY3VtZW50IHRvIHRoZTxicj4mZ3Q7IElFU0cu
Jm5ic3A7IEhlIHByb21pc2VzIHRvIHRha2UgTWlrZSBUaG9tYXMnIGlzc3VlcyBmcm9tIHRoZSBs
aXN0IGludG8gYWNjb3VudCBhbmQ8YnI+Jmd0OyBtYWtlIHN1cmUgdGhhdCBldmVyeW9uZSBpcyBo
YXBweS48YnI+Jmd0OyA8YnI+Jmd0OyBbIEknZCBsaWtlIHRvIGV4dGVuZCBhIHBlcnNvbmFsIHRo
YW5rIHlvdSB0byBCYXJyeSBmb3IgY29udGludWluZyBoaXMgcm9sZTxicj4mZ3Q7Jm5ic3A7ICBh
cyBkb2N1bWVudCBzaGVwaGFyZCBmb3IgdGhpcyBkcmFmdC4mbmJzcDsgLS0gZGVyZWsgXTxicj4m
Z3Q7IDxicj4mZ3Q7IE5leHQsIE1pa2UgSm9uZXMgc3Bva2UgYWJvdXQgdGhlIEFzc2VydGlvbnMs
IFNBTUwyIEJlYXJlciwgYW5kIFVSTi1TdWItPGJyPiZndDsgTlMgZHJhZnRzLiZuYnNwOyBFeGNl
cHQgZm9yIG9uZSBvdXRzdGFuZGluZyBpc3N1ZSBNaWtlIGJlbGlldmVzIHRoZXNlIGRvY3VtZW50
czxicj4mZ3Q7IGFyZSByZWFkeSBmb3IgV0dMQy4mbmJzcDsgQ29uc2Vuc3VzIGluIHRoZSByb29t
IHdhcyB0byB0YWtlIHRoZXNlIHRocmVlIGRvY3MgdG88YnI+Jmd0OyBXR0xDLCB3aGljaCB0aGUg
Y2hhaXJzIHdpbGwgZG8gYnkgdGhlIGVuZCBvZiBuZXh0IHdlZWsuPGJyPiZndDsgPGJyPiZndDsg
VGhlIE1BQyBUb2tlbiBkcmFmdAogaGFzIGxhbmd1aXNoZWQgd2hpbGUgdGltZSB3YXMgc3BlbnQg
d29ya2luZyBvbiB0aGU8YnI+Jmd0OyBjb3JlIGRvY3VtZW50LiZuYnNwOyBFcmFuIHdhcyBub3Qg
aGVyZSwgbm9yIHdhcyBoZSBvbmxpbmUsIHRvIHRhbGsgYWJvdXQgdGhlPGJyPiZndDsgc3RhdHVz
IG9mIHRoZSBNQUMgVG9rZW4gZHJhZnQuJm5ic3A7IFRoZXJlIHdlcmUgb25seSBhIGZldyBwZW9w
bGUgaW4gdGhlIHJvb208YnI+Jmd0OyBpbnRlcmVzdGVkIGluIHJldmlld2luZyB0aGUgZHJhZnQs
IHdoaWNoIHdhcyBub3QgYSBjbGVhciBjb25zZW5zdXMgb2Y8YnI+Jmd0OyBpbnRlcmVzdCwgZXZl
biB0aG91Z2ggdGhpcyBkb2N1bWVudCBkb2VzIHNvbHZlIGEgcHJvYmxlbSB0aGF0IHRoZSBiZWFy
ZXI8YnI+Jmd0OyB0b2tlbnMgY2Fubm90LiZuYnNwOyBUaGUgY2hhaXJzIHdpbGwgdGFrZSBpdCB0
byB0aGUgbGlzdCB0byBldmFsdWF0ZSBpZiB0aGVyZSBpcyBlbm91Z2g8YnI+Jmd0OyBpbnRlcmVz
dCB0byBjb250aW51ZSB3aXRoIHRoaXMgZG9jdW1lbnQuPGJyPjxicj5BcyBJJ3ZlIHVwZGF0ZWQg
dGhlIGxpc3QgYW5kIGNoYWlycyBvbiBtdWx0aXBsZSBvY2Nhc2lvbnMsIHRoZSBkcmFmdCBpcyBw
cmFjdGljYWxseSByZWFkeS4gVGhlcmUgd2FzIHNvbWUgbGF0ZSBhcnJpdmluZyBmZWVkYmFjayB3
aGljaCBJIGRpZCBub3QgZ2V0IGFyb3VuZCB0byBwcm9jZXNzLiBIb3dldmVyLCB0aGUgbWFpbiBp
c3N1ZSBpcyBsYWNrIG9mIFdHIGludGVyZXN0IGluIHRoaXMgd29yay4gSSBhbSBzdGlsbCBwbGFu
bmluZyB0byBmaW5pc2ggaXQgYnkgbWFraW5nIHZlcnkgbWlub3IgdHdlYWtzIHRvIHRoZSBjdXJy
ZW50IGRyYWZ0LCBidXQgd291bGQgYmUgdmVyeSBoYXBweSB0byBtYWtlIGl0IGFuIGluZGl2aWR1
YWwgc3VibWlzc2lvbi48YnI+PGJyPlRoZSBNQUMgZHJhZnQgaGFzIGxhcmdlbHkgYmVlbiBteSBw
ZXJzb25hbCBwcm9qZWN0IHRvCiBkYXRlLjxicj48YnI+Jmd0OyBJbiBhIHJlbGF0ZWQgbm90ZSwg
dGhpcyBkb2N1bWVudCAoYXMgd2VsbCBhcyB0aGUgdjItYmVhcmVyIGRvY3VtZW50KSBpcyBub3Q8
YnI+Jmd0OyBhdmFpbGFibGUgb2ZmIHRoZSB0b29scyBwYWdlIGV2ZW4gdGhvdWdoIGl0IGhhcyBu
b3QgZXhwaXJlZC4mbmJzcDsgSSBoYXZlIHRha2VuIHRoZTxicj4mZ3Q7IGFjdGlvbiBpdGVtIHRv
IGdldCB0aGF0IHNvcnRlZCBvdXQuPGJyPiZndDsgPGJyPiZndDsgRmluYWxseSwgd2Ugc3BlbnQg
dGhlIG1ham9yaXR5IG9mIG91ciB0aW1lIHRhbGtpbmcgYWJvdXQgcmVjaGFydGVyaW5nIGJhc2Vk
IG9uPGJyPiZndDsgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgc2VudCB0byB0aGUgbGlzdCBieSBIYW5u
ZXMgYSB3ZWVrIG9yIHR3byBhZ28uPGJyPiZndDsgQ29uc2Vuc3VzIG9mIHRoZSByb29tIHdhcyB0
aGF0IHRoZXJlIHdhcyBlbm91Z2ggaW50ZXJlc3QgdG8gcmVjaGFydGVyPGJyPiZndDsgYmFzZWQg
cm91Z2hseSBvbiB0aGUgcHJvcG9zZWQgY2hhcnRlci4mbmJzcDsgVGhlcmUgd2FzIGFsc28gY29u
c2Vuc3VzIHRvIGluY2x1ZGU8YnI+Jmd0OyBTaW1wbGUgV2ViIERpc2NvdmVyeSAoaW4gYWRkaXRp
b24gdG8sIGFuZCBzZXBhcmF0ZSBmcm9tLCBEeW5hbWljIENsaWVudDxicj4mZ3Q7IFJlZ2lzdHJh
dGlvbiksIGFsdGhvdWdoIHdlIHdpbGwgbmVlZCB0byB3b3JrIHdpdGggdGhlIEFEcyB0byBtYWtl
IHN1cmUgaXQ8YnI+Jmd0OyBnZXRzIGhhbmRsZWQgaW4gdGhlIGFwcHJvcHJpYXRlIFdHIGFuZCBB
cmVhLjxicj4mZ3Q7IE1vcmVvdmVyLCBpdCdzIGltcG9ydGFudCB0byBtYWtlIHN1cmUgdGhlIGFw
cHJvcHJpYXRlIGFwcGxpY2F0aW9ucyBhcmVhPGJyPiZndDsgcGFydGljaXBhbnRzIGdldCBpbnZv
bHZlZCBpbiB0aGUgU1dEIHdvcmsuPGJyPjxicj5UaGVyZSBpcyBzb21ldGhpbmcgdmVyeSBhd2t3
YXJkIGFib3V0CiBkaXNjdXNzaW5nIFNXRCBib3RoIGluIHRoZSBjb250ZXh0IG9mIHRoaXMgd29y
a2luZyBncm91cCwgYW5kIGluIHRoZSBjb250ZXh0IG9mIGZ1dHVyZSBPQXV0aCBkaXNjb3Zlcnkg
d29yay4gVGhlIGlkZWEgb2YgcGlja2luZyBhIGRpc2NvdmVyeSBtZWNoYW5pc20gYmVmb3JlIHRo
ZSBXRyBoYWQgYSBzaW5nbGUgZGlzY3Vzc2lvbiBhYm91dCB3aGF0IGlzIGluY2x1ZGVkIGluIGRp
c2NvdmVyeSBhbmQgd2hhdCBhcmUgdGhlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnQgaXMgYWJz
dXJkLjxicj48YnI+VGhlcmUgaGFzIG5vdCBiZWVuIGNvbnNlbnN1cyBvbiB0aGUgbGlzdCBmb3Ig
aW5jbHVkaW5nIFNXRCBpbiB0aGUgV0cgY2hhcnRlci48YnI+PGJyPlRoZSBvbmx5IGp1c3RpZmlj
YXRpb24gSSBoYXZlIGhlYXJkIHNvIGZhciBmb3IgdGhpcyBXRyB0byBiZSB0aGUgU1dEIHZlbnVl
IGlzIHRoYXQgaXQncyBlYXN5IGJlY2F1c2UgdGhlIGF1dGhvciBhbmQgYSBmZXcgb3RoZXIgcGVv
cGxlIGludGVyZXN0ZWQgYXJlIGFscmVhZHkgaGVyZS4gVGhhdCdzIG5vdCBhIHZhbGlkIHJlYXNv
bi48YnI+PGJyPkFueSBmdXJ0aGVyIHdvcmsgb24gU1dEIGFsc28gcmVxdWlyZXMgdGhlIElFVEYg
dG8gdmlldyBpdCBpbiBsaWdodCBvZiBSRkMgNjQxNSAoaG9zdC1tZXRhKSB3aGljaCBpcyBhIHBy
b3Bvc2VkIHN0YW5kYXJkIGFwcHJvdmVkIGluIE9jdG9iZXIgMjAxMS4gVGhlIElFVEYgaXMgbm90
IGluIHRoZSAnZmxhdm9yIG9mIHRoZSBtb250aCcgYnVzaW5lc3MuIFByb3BlciBwcm9jZXNzIHJl
cXVpcmVzIGRpc2N1c3Npb24gYWJvdXQgdGhlIG1lcml0cyBvZiByZWRvaW5nIHRoZSBob3N0LW1l
dGEgd29yayBmcm9tIHNjcmF0Y2ggaW4gYSBub24tY29tcGF0aWJsZSB3YXkganVzdCBiZWNhdXNl
IGEgaGFuZGZ1bCBvZiBwZW9wbGUgJ2xpa2UgaXQgYmV0dGVyJyB3aXRoIGxpdHRsZSB0ZWNobmlj
YWwKIGp1c3RpZmljYXRpb24uPGJyPjxicj5FaXRoZXIgd2F5LCB0aGlzIGRpc2N1c3Npb24gZG9l
cyBub3QgYmVsb25nIGhlcmUuPGJyPjxicj5FSDxicj48YnI+X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGluZyBsaXN0PGJyPjxhIHlt
YWlsdG89Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPjxicj48YnI+IDwvZGl2PiA8L2Rpdj4gPC9i
bG9ja3F1b3RlPjwvZGl2PiAgIDwvZGl2PjwvYm9keT48L2h0bWw+


------=_Part_3_1333088565926--


From eran@hueniverse.com  Thu Mar 29 23:39:41 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11EA21F87A2 for ; Thu, 29 Mar 2012 23:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level: 
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bz6nliDcOvy9 for ; Thu, 29 Mar 2012 23:39:39 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id BD15E21F879F for ; Thu, 29 Mar 2012 23:39:39 -0700 (PDT)
Received: (qmail 8096 invoked from network); 30 Mar 2012 06:39:38 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Mar 2012 06:39:38 -0000
Received: from P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.47]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id rife1i00111lQaG01ifeJv; Thu, 29 Mar 2012 23:39:38 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 29 Mar 2012 23:36:13 -0700
From: Eran Hammer 
To: Derek Atkins , William Mills , "oauth@ietf.org" 
Date: Thu, 29 Mar 2012 23:36:03 -0700
Thread-Topic: [OAUTH-WG] OAUTH Report for IETF-83
Thread-Index: Ac0OPGbfEl+RaeXgTTesbF8DHzADMQAAZpzw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5D4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4f3201f5-c1c8-47ea-a2ba-4c0bb6ffecf5@P3PW5EX1HT003.EX1.SECURESERVER.NET>
In-Reply-To: <4f3201f5-c1c8-47ea-a2ba-4c0bb6ffecf5@P3PW5EX1HT003.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5D4P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 06:39:41 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5D4P3PW5EX1MB01E_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmXZlIGFscmVhZHkgYXNrZWQgZm9yIHRoZSBhdWRpbyAvIHRyYW5zY3JpcHQgLyBkZXRhaWxl
ZCBub3RlcyBvZiB0aGUgbWVldGluZy4gQWxsIEkgaGF2ZSBpcyB5b3VyIG5vdGVzIHBvc3RlZCBl
YXJsaWVyLiBVbmxpa2UgbWFueSBpbiB0aGlzIFdHLCBPQXV0aCBoYXMgbm90aGluZyB0byBkbyB3
aXRoIG15IGRheSBqb2IuIE1lZXRpbmdzIGFyZSBub3QgYSByZXF1aXJlZCBwYXJ0IG9mIHRoZSBJ
RVRGIHByb2Nlc3MgYW5kIHNlcnZlIG9ubHkgYXMgaW5wdXQgZm9yIHRoZSBtYWlsaW5nIGxpc3Qu
IFRoZSBpbnB1dCBwcm92aWRlZCBpc27igJl0IHZlcnkgaGVscGZ1bC4NCg0KR2l2ZW4gbXkgYW5h
bHlzaXMgYmVsb3csIHdoYXQgaXMgbWlzc2luZyBpbiBjb21wYXJpc29uIHRvIHdoYXQgd2FzIGRp
c2N1c3NlZD8gV2hhdCBvdGhlciBwcm9jZXNzIGlzIGJlaW5nIGZvbGxvd2VkIHRvIGp1c3RpZnkg
U1dEIGJlY29taW5nIGl0cyBvd24gdG9waWMgYW5kIG5vdCBhIHRlY2huaWNhbCB0b3BpYyB0byBi
ZSBkaXNjdXNzZWQgbGF0ZXI/DQoNCkVIDQoNCg0KRnJvbTogRGVyZWsgQXRraW5zIFttYWlsdG86
ZGVyZWtAaWh0ZnAuY29tXQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDI5LCAyMDEyIDExOjE1IFBN
DQpUbzogRXJhbiBIYW1tZXI7IFdpbGxpYW0gTWlsbHM7IHNhYWdAaWV0Zi5vcmc7IG9hdXRoQGll
dGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQVVUSCBSZXBvcnQgZm9yIElFVEYtODMN
Cg0KWWVzLCB5b3UgYXJlIG1pc3NpbmcgdGhlIG1lZXRpbmcgd2UgaGFkIHllc3RlcmRheSB3aGVy
ZSBpdCB3YXMgZGlzY3Vzc2VkIHRvIGJlIGFkZGVkIHRvIHRoZSBjaGFydGVyLg0KDQotZGVyZWss
IFdHIENoYWlyDQoNClNlbnQgZnJvbSBteSBIVEMgb24gdGhlIE5vdyBOZXR3b3JrIGZyb20gU3By
aW50IQ0KLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQ0KRnJvbTogIkVyYW4gSGFtbWVyIiA8ZXJh
bkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+DQpEYXRlOiBGcmks
IE1hciAzMCwgMjAxMiA0OjI1IGFtDQpTdWJqZWN0OiBbT0FVVEgtV0ddIE9BVVRIIFJlcG9ydCBm
b3IgSUVURi04Mw0KVG86ICJXaWxsaWFtIE1pbGxzIiA8d21pbGxzQHlhaG9vLWluYy5jb208bWFp
bHRvOndtaWxsc0B5YWhvby1pbmMuY29tPj4sICJEZXJlayBBdGtpbnMiIDxkZXJla0BpaHRmcC5j
b208bWFpbHRvOmRlcmVrQGlodGZwLmNvbT4+LCAic2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0Bp
ZXRmLm9yZz4iIDxzYWFnQGlldGYub3JnPG1haWx0bzpzYWFnQGlldGYub3JnPj4sICJvYXV0aEBp
ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h
dXRoQGlldGYub3JnPj4NClRoZSBuYXJyYXRpdmUgc28gZmFyOg0KDQpUaGUgSUVURiBoYXMgYWRv
cHRlZCBob3N0LW1ldGEgYXMgYSBnZW5lcmFsLXB1cnBvc2UgZGlzY292ZXJ5IG1lY2hhbmlzbSBp
biBSRkMgNjQxNS4NClRoZSBPcGVuSUQgQ29ubmVjdCBncm91cCwgd2hpY2ggdXRpbGl6ZXMgT0F1
dGggYnV0IGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBXRywgYWRvcHRlZCBTV0QgYXMgaXRzIGRp
c2NvdmVyeSBtZWNoYW5pc20uDQpUaGUgcHJvcG9zZWQgY2hhcnRlciByZWZlcmVuY2VzIOKAmE9B
dXRoIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBQcm90b2NvbOKAmSwgd2hpY2ggaW4gdHVy
biByZWZlcmVuY2VzIFJGQyA2NDE1IGFzIGl0cyBkaXNjb3ZlcnkgbWVjaGFuaXNtLg0KDQpBbSBJ
IG1pc3NpbmcgYSBXRyBpdGVtIG9yIHByb3Bvc2VkIGRyYWZ0IHdoaWNoIHJlbGllcyBvbiBTV0Qg
YXQgdGhpcyB0aW1lPyBJZiBJIGFtLCBhcmUgdGhlc2UgZG9jdW1lbnRzIGluY2x1ZGVkIGluIHRo
ZSBwcm9wb3NlZCBjaGFydGVyIG9yIGFyZSByZXF1ZXN0ZWQgdG8gYmUgaW5jbHVkZWQgKGUuZy4g
bm90IFNXVCBpdHNlbGYgYnV0IG90aGVyIGRvY3VtZW50cyB3aXRoIGRlcGVuZGVuY2llcyBvbiBp
dCk/IEluIHN1Y2ggZG9jdW1lbnRzLCBpcyBTV0QgYSByZXF1aXJlZCBjb21wb25lbnQgd2hpY2gg
Y2Fubm90IGJlIHN1YnN0aXR1dGVkIHdpdGggc29tZXRoaW5nIGVsc2Ugc3VjaCBhcyBSRkMgNjQx
NT8NCg0KSGVyZSBpcyBob3cgdGhpcyBwcm9jZXNzIHNob3VsZCB3b3JrOg0KDQoNCjEuICAgICAg
IFRoZSBXRyBhZ3JlZXMgb24gaW5jbHVkaW5nIGEgZGlzY292ZXJ5IHJlbGF0ZWQgaXRlbSBpbiBp
dHMgY2hhcnRlci4gVGhlIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBpcyBhIHJlYXNvbmFi
bGUgc3VjaCBpdGVtLg0KDQoyLiAgICAgICBUaGUgY2hhcnRlciByZWZlcmVuY2VzIGFuIGV4aXN0
aW5nIHByb3Bvc2FsIGFzIGZvdW5kYXRpb24uDQoNCjMuICAgICAgIFRoZSBXRyBiZWdpbnMgZGlz
Y3Vzc2luZyB0aGUgcHJvcG9zZWQgZHJhZnQgKHdoaWNoIGNhbiBoYXBwZW4gYXQgYW55IHRpbWUg
b24gdGhlIGxpc3QgYXMgbG9uZyBhcyB0aGUgY2hhaXJzIGFsbG93IGl0KS4NCg0KNC4gICAgICAg
VGhlIFdHIGRpc2N1c3NlcyBhbnkgcmVxdWlyZWQgZW5hYmxpbmcgdGVjaG5vbG9naWVzLCB0aGVp
ciBzdWl0YWJpbGl0eSwgbWF0dXJpdHksIGluZHVzdHJ5IHN1cHBvcnQsIGV0Yy4gSW4gdGhlIGNh
c2Ugb2YgZHluYW1pYyByZWdpc3RyYXRpb24sIEkgZXhwZWN0IHRoZSBXRyB0byBkaXNjdXNzIFNX
RCAoYmVjYXVzZSBpdCBpcyB0aGUgdGVjaG5vbG9neSBzZWxlY3RlZCBieSB0aGUgT3BlbklEIHN1
YnNldCBvZiB0aGlzIFdHKSwgaG9zdC1tZXRhIChiZWNhdXNlIGl0IGlzIGFuIElFVEYgcHJvcG9z
ZWQgc3RhbmRhcmQgUkZDKSwgYXMgd2VsbCBhcyBvdGhlciBzb2x1dGlvbnMgKExpbmsgaGVhZGVy
cywgb3RoZXIgd2VsbC1rbm93biBVUklzLCBldGMuKS4gVGhlIHB1YmxpY2F0aW9uIHN0YXR1cyBv
ZiB0aGUgcHJvcG9zZWQgdGVjaG5vbG9naWVzIGlzIGFub3RoZXIgZmFjdG9yLg0KDQo1LiAgICAg
ICBJZiBhbiBlbmFibGluZyB0ZWNobm9sb2d5IGlzIGRlY2lkZWQgdG8gYmUgdGhlIG1vc3Qgc3Vp
dGFibGUsIGFuZCBpcyBub3QgYXZhaWxhYmxlIGluIG5vcm1hdGl2ZSByZWZlcmVuY2UgZm9ybSwg
dGhlIFdHIHdpbGwgZGlzY3VzcyB0aGUgYmVzdCB3YXkgdG8gYWNjb21wbGlzaCB0aGF0LiBUaGlz
IGluY2x1ZGVzIGlkZW50aWZ5aW5nIHRoZSByaWdodCBjb21tdW5pdHksIHN0YW5kYXJkcyBib2R5
LCB3b3JraW5nIGdyb3VwLCBldGMuIHRoYXQgaXMgYmVzdCB0byB0YWtlIG9uIHRoZSB3b3JrLiBJ
ZiBubyBzdWl0YWJsZSB2ZW51ZSBpcyBmb3VuZCwgdGhlIFdHIG1heSBkZWNpZGUgdG8gdGFrZSBv
biB0aGUgd29yayB3aXRoIHZlcnkgbGltaXRlZCBzY29wZSBvbmx5IHRvIGVuYWJsZSBpdHMgb3du
IHVzZSBjYXNlcy4NCg0KSSBhbSBub3Qgb3Bwb3NlZCB0byBoYXZpbmcgdGhpcyBkaXNjdXNzaW9u
LCBidXQgd2h5IGFyZSAqd2UqIGhhdmluZyBpdCAqbm93Kiwgb3RoZXIgdGhhbiB0aGUgT3BlbklE
IENvbm5lY3QgZ3JvdXAsIHdoaWNoIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhpcyBXRywgaXMg
c3R1Y2sgd2l0aCB0aGUgcHJvYmxlbSBvZiBmaW5kaW5nIGEgdmVudWUgZm9yIHRoaXMgd29yaywg
YW5kIGFyZSBkdW1waW5nIGl0IG9uIG91ciBsYXBzPw0KDQpJIGRvIG5vdCByZWNhbGwgdGhpcyBX
RyBldmVyIGRlY2lkZWQgKG9yIGV2ZW4gKnByb3Bvc2VkKikgdG8gdXNlIFNXRCBmb3IgYW55IG9m
IGl0cyBjaGFydGVyZWQgaXRlbXMuIFdoZW4gd2UgaGF2ZSB0aGlzIGRpc2N1c3Npb24sIEkgZXhw
ZWN0IGl0IHRvIGluY2x1ZGUgYSBkZXRhaWxlZCBleGFtaW5hdGlvbiBvZiBob3N0LW1ldGEgYW5k
IG90aGVyIHNvbHV0aW9ucyAqYXMgZXF1YWwqIGFsdGVybmF0aXZlcy4gVGhlIE9wZW5JRCBDb25u
ZWN0IGdyb3VwIHByZWZlcmVuY2UgaXMgYSB2YWxpZCBpbnB1dCBhcyBpdCBjb3ZlcnMgc29tZSBw
b3RlbnRpYWwgbWFya2V0IHNoYXJlIHdpdGggT0F1dGggZGVwbG95bWVudCwgYnV0IGl0IGlzICpm
YXIqIGZyb20gYW55IHNpZ25pZmljYW50IGRlcGxveW1lbnQgd29ydGh5IG9mIGJ5cGFzc2luZyB0
aGlzIGV2YWx1YXRpb24uDQoNCkFtIEkgbWlzc2luZyBzb21ldGhpbmcgaGVyZT8NCg0KRUgNCg0K
DQoNCg0KDQpGcm9tOiBXaWxsaWFtIE1pbGxzIFttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21d
PG1haWx0bzpbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXT4NClNlbnQ6IFRodXJzZGF5LCBN
YXJjaCAyOSwgMjAxMiA0OjI2IFBNDQpUbzogRXJhbiBIYW1tZXI7IERlcmVrIEF0a2luczsgc2Fh
Z0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz47IG9hdXRoQGlldGYub3JnPG1haWx0bzpv
YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BVVRIIFJlcG9ydCBmb3Ig
SUVURi04Mw0KDQpPbiB0aGUgU1dEIHN0dWZmIHRoZXJlIHdhcyBnZW5lcmFsIGRpc2N1c3Npb24g
YWJvdXQgImlzIHRoaXMgdGhlIHJpZ2h0IHBsYWNlPyIsIGFuZCB0aGVyZSAid2VyZSBpc3N1ZXMg
cmFpc2VkIi4gIFRoZSBxdWVzdGlvbiB3YXMgYWxzbyBhc2tlZCAid2VsbCwgd2hlcmUgaXMgdGhl
IHJpZ2h0IHBsYWNlPyIgd2hpY2ggZ290IGNyaWNrZXRzLiAgSXQgaXMgZXhhY3RseSBjb21pbmcg
YmFjayB0byB0aGUgbGlzdCBmb3IgZGlzY3Vzc2lvbiB0byBzb3J0IG91dCB0aGUgcmlnaHQgcGxh
Y2UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBFcmFuIEhhbW1l
ciA8ZXJhbkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+DQpUbzog
RGVyZWsgQXRraW5zIDxkZXJla0BpaHRmcC5jb208bWFpbHRvOmRlcmVrQGlodGZwLmNvbT4+OyAi
c2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4iIDxzYWFnQGlldGYub3JnPG1haWx0
bzpzYWFnQGlldGYub3JnPj47ICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+
IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClNlbnQ6IFRodXJzZGF5
LCBNYXJjaCAyOSwgMjAxMiA4OjQ0IEFNDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQVVUSCBS
ZXBvcnQgZm9yIElFVEYtODMNCg0KSGkgRGVyZWssDQoNClRoYW5rcyBmb3IgdGhlIG5vdGVzLiBJ
cyBhbiBhdWRpbyByZWNvcmRpbmcgYXZhaWxhYmxlPw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5j
ZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgt
Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZg0KPiBPZiBEZXJlayBBdGtpbnMNCj4gU2VudDog
VGh1cnNkYXksIE1hcmNoIDI5LCAyMDEyIDg6MjcgQU0NCj4gVG86IHNhYWdAaWV0Zi5vcmc8bWFp
bHRvOnNhYWdAaWV0Zi5vcmc+OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+
DQo+IFN1YmplY3Q6IFtPQVVUSC1XR10gT0FVVEggUmVwb3J0IGZvciBJRVRGLTgzDQo+DQo+IEhp
LA0KPg0KPiBPQVVUSCBtZXQgZWFybGllciB0aGlzIGFmdGVybm9vbiBpbiBBZnRlcm5vb24gU2Vz
c2lvbiBJIGF0IDEzaDAwIGZvciBhIHR3bw0KPiBob3VyIHNlc3Npb24uICBBZnRlciBpbnRyb2R1
Y2luZyBvdXJzZWx2ZXMgYW5kIHdlbGNvbWluZyBtZSB0byB0aGUgd29ya2luZw0KPiBncm91cCB3
ZSB0aGFua2VkIEJhcnJ5IGFuZCBCbGFpbmUgZm9yIHRoZWlyIHNlcnZpY2UuDQo+DQo+IFRvcnN0
ZW4gc3Bva2UgYWJvdXQgZHJhZnQtaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbC4gIFRoaXMgZG9j
dW1lbnQgaGFzDQo+IGNvbXBsZXRlZCBXRyBMYXN0IENhbGwuICBUb3JzdGVuIGhhcyBhcHBsaWVk
IGNoYW5nZXMgYmFzZWQgb24gdGhlIExhc3QgQ2FsbA0KPiBDb21tZW50cyBhbmQgaGFzIHB1Ymxp
c2hlZCBhIG5ldyByZXZpc2lvbi4gIEJhcnJ5IHByb21pc2VkIHRvIGZpbmlzaCBoaXMNCj4gUFJP
VE8gU2hlcGFyZCByZXZpZXcgbmV4dCB3ZWVrIHNvIHdlIGNhbiBzZW5kIHRoaXMgZG9jdW1lbnQg
dG8gdGhlDQo+IElFU0cuICBIZSBwcm9taXNlcyB0byB0YWtlIE1pa2UgVGhvbWFzJyBpc3N1ZXMg
ZnJvbSB0aGUgbGlzdCBpbnRvIGFjY291bnQgYW5kDQo+IG1ha2Ugc3VyZSB0aGF0IGV2ZXJ5b25l
IGlzIGhhcHB5Lg0KPg0KPiBbIEknZCBsaWtlIHRvIGV4dGVuZCBhIHBlcnNvbmFsIHRoYW5rIHlv
dSB0byBCYXJyeSBmb3IgY29udGludWluZyBoaXMgcm9sZQ0KPiAgYXMgZG9jdW1lbnQgc2hlcGhh
cmQgZm9yIHRoaXMgZHJhZnQuICAtLSBkZXJlayBdDQo+DQo+IE5leHQsIE1pa2UgSm9uZXMgc3Bv
a2UgYWJvdXQgdGhlIEFzc2VydGlvbnMsIFNBTUwyIEJlYXJlciwgYW5kIFVSTi1TdWItDQo+IE5T
IGRyYWZ0cy4gIEV4Y2VwdCBmb3Igb25lIG91dHN0YW5kaW5nIGlzc3VlIE1pa2UgYmVsaWV2ZXMg
dGhlc2UgZG9jdW1lbnRzDQo+IGFyZSByZWFkeSBmb3IgV0dMQy4gIENvbnNlbnN1cyBpbiB0aGUg
cm9vbSB3YXMgdG8gdGFrZSB0aGVzZSB0aHJlZSBkb2NzIHRvDQo+IFdHTEMsIHdoaWNoIHRoZSBj
aGFpcnMgd2lsbCBkbyBieSB0aGUgZW5kIG9mIG5leHQgd2Vlay4NCj4NCj4gVGhlIE1BQyBUb2tl
biBkcmFmdCBoYXMgbGFuZ3Vpc2hlZCB3aGlsZSB0aW1lIHdhcyBzcGVudCB3b3JraW5nIG9uIHRo
ZQ0KPiBjb3JlIGRvY3VtZW50LiAgRXJhbiB3YXMgbm90IGhlcmUsIG5vciB3YXMgaGUgb25saW5l
LCB0byB0YWxrIGFib3V0IHRoZQ0KPiBzdGF0dXMgb2YgdGhlIE1BQyBUb2tlbiBkcmFmdC4gIFRo
ZXJlIHdlcmUgb25seSBhIGZldyBwZW9wbGUgaW4gdGhlIHJvb20NCj4gaW50ZXJlc3RlZCBpbiBy
ZXZpZXdpbmcgdGhlIGRyYWZ0LCB3aGljaCB3YXMgbm90IGEgY2xlYXIgY29uc2Vuc3VzIG9mDQo+
IGludGVyZXN0LCBldmVuIHRob3VnaCB0aGlzIGRvY3VtZW50IGRvZXMgc29sdmUgYSBwcm9ibGVt
IHRoYXQgdGhlIGJlYXJlcg0KPiB0b2tlbnMgY2Fubm90LiAgVGhlIGNoYWlycyB3aWxsIHRha2Ug
aXQgdG8gdGhlIGxpc3QgdG8gZXZhbHVhdGUgaWYgdGhlcmUgaXMgZW5vdWdoDQo+IGludGVyZXN0
IHRvIGNvbnRpbnVlIHdpdGggdGhpcyBkb2N1bWVudC4NCg0KQXMgSSd2ZSB1cGRhdGVkIHRoZSBs
aXN0IGFuZCBjaGFpcnMgb24gbXVsdGlwbGUgb2NjYXNpb25zLCB0aGUgZHJhZnQgaXMgcHJhY3Rp
Y2FsbHkgcmVhZHkuIFRoZXJlIHdhcyBzb21lIGxhdGUgYXJyaXZpbmcgZmVlZGJhY2sgd2hpY2gg
SSBkaWQgbm90IGdldCBhcm91bmQgdG8gcHJvY2Vzcy4gSG93ZXZlciwgdGhlIG1haW4gaXNzdWUg
aXMgbGFjayBvZiBXRyBpbnRlcmVzdCBpbiB0aGlzIHdvcmsuIEkgYW0gc3RpbGwgcGxhbm5pbmcg
dG8gZmluaXNoIGl0IGJ5IG1ha2luZyB2ZXJ5IG1pbm9yIHR3ZWFrcyB0byB0aGUgY3VycmVudCBk
cmFmdCwgYnV0IHdvdWxkIGJlIHZlcnkgaGFwcHkgdG8gbWFrZSBpdCBhbiBpbmRpdmlkdWFsIHN1
Ym1pc3Npb24uDQoNClRoZSBNQUMgZHJhZnQgaGFzIGxhcmdlbHkgYmVlbiBteSBwZXJzb25hbCBw
cm9qZWN0IHRvIGRhdGUuDQoNCj4gSW4gYSByZWxhdGVkIG5vdGUsIHRoaXMgZG9jdW1lbnQgKGFz
IHdlbGwgYXMgdGhlIHYyLWJlYXJlciBkb2N1bWVudCkgaXMgbm90DQo+IGF2YWlsYWJsZSBvZmYg
dGhlIHRvb2xzIHBhZ2UgZXZlbiB0aG91Z2ggaXQgaGFzIG5vdCBleHBpcmVkLiAgSSBoYXZlIHRh
a2VuIHRoZQ0KPiBhY3Rpb24gaXRlbSB0byBnZXQgdGhhdCBzb3J0ZWQgb3V0Lg0KPg0KPiBGaW5h
bGx5LCB3ZSBzcGVudCB0aGUgbWFqb3JpdHkgb2Ygb3VyIHRpbWUgdGFsa2luZyBhYm91dCByZWNo
YXJ0ZXJpbmcgYmFzZWQgb24NCj4gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgc2VudCB0byB0aGUgbGlz
dCBieSBIYW5uZXMgYSB3ZWVrIG9yIHR3byBhZ28uDQo+IENvbnNlbnN1cyBvZiB0aGUgcm9vbSB3
YXMgdGhhdCB0aGVyZSB3YXMgZW5vdWdoIGludGVyZXN0IHRvIHJlY2hhcnRlcg0KPiBiYXNlZCBy
b3VnaGx5IG9uIHRoZSBwcm9wb3NlZCBjaGFydGVyLiAgVGhlcmUgd2FzIGFsc28gY29uc2Vuc3Vz
IHRvIGluY2x1ZGUNCj4gU2ltcGxlIFdlYiBEaXNjb3ZlcnkgKGluIGFkZGl0aW9uIHRvLCBhbmQg
c2VwYXJhdGUgZnJvbSwgRHluYW1pYyBDbGllbnQNCj4gUmVnaXN0cmF0aW9uKSwgYWx0aG91Z2gg
d2Ugd2lsbCBuZWVkIHRvIHdvcmsgd2l0aCB0aGUgQURzIHRvIG1ha2Ugc3VyZSBpdA0KPiBnZXRz
IGhhbmRsZWQgaW4gdGhlIGFwcHJvcHJpYXRlIFdHIGFuZCBBcmVhLg0KPiBNb3Jlb3ZlciwgaXQn
cyBpbXBvcnRhbnQgdG8gbWFrZSBzdXJlIHRoZSBhcHByb3ByaWF0ZSBhcHBsaWNhdGlvbnMgYXJl
YQ0KPiBwYXJ0aWNpcGFudHMgZ2V0IGludm9sdmVkIGluIHRoZSBTV0Qgd29yay4NCg0KVGhlcmUg
aXMgc29tZXRoaW5nIHZlcnkgYXdrd2FyZCBhYm91dCBkaXNjdXNzaW5nIFNXRCBib3RoIGluIHRo
ZSBjb250ZXh0IG9mIHRoaXMgd29ya2luZyBncm91cCwgYW5kIGluIHRoZSBjb250ZXh0IG9mIGZ1
dHVyZSBPQXV0aCBkaXNjb3Zlcnkgd29yay4gVGhlIGlkZWEgb2YgcGlja2luZyBhIGRpc2NvdmVy
eSBtZWNoYW5pc20gYmVmb3JlIHRoZSBXRyBoYWQgYSBzaW5nbGUgZGlzY3Vzc2lvbiBhYm91dCB3
aGF0IGlzIGluY2x1ZGVkIGluIGRpc2NvdmVyeSBhbmQgd2hhdCBhcmUgdGhlIHVzZSBjYXNlcyBh
bmQgcmVxdWlyZW1lbnQgaXMgYWJzdXJkLg0KDQpUaGVyZSBoYXMgbm90IGJlZW4gY29uc2Vuc3Vz
IG9uIHRoZSBsaXN0IGZvciBpbmNsdWRpbmcgU1dEIGluIHRoZSBXRyBjaGFydGVyLg0KDQpUaGUg
b25seSBqdXN0aWZpY2F0aW9uIEkgaGF2ZSBoZWFyZCBzbyBmYXIgZm9yIHRoaXMgV0cgdG8gYmUg
dGhlIFNXRCB2ZW51ZSBpcyB0aGF0IGl0J3MgZWFzeSBiZWNhdXNlIHRoZSBhdXRob3IgYW5kIGEg
ZmV3IG90aGVyIHBlb3BsZSBpbnRlcmVzdGVkIGFyZSBhbHJlYWR5IGhlcmUuIFRoYXQncyBub3Qg
YSB2YWxpZCByZWFzb24uDQoNCkFueSBmdXJ0aGVyIHdvcmsgb24gU1dEIGFsc28gcmVxdWlyZXMg
dGhlIElFVEYgdG8gdmlldyBpdCBpbiBsaWdodCBvZiBSRkMgNjQxNSAoaG9zdC1tZXRhKSB3aGlj
aCBpcyBhIHByb3Bvc2VkIHN0YW5kYXJkIGFwcHJvdmVkIGluIE9jdG9iZXIgMjAxMS4gVGhlIElF
VEYgaXMgbm90IGluIHRoZSAnZmxhdm9yIG9mIHRoZSBtb250aCcgYnVzaW5lc3MuIFByb3BlciBw
cm9jZXNzIHJlcXVpcmVzIGRpc2N1c3Npb24gYWJvdXQgdGhlIG1lcml0cyBvZiByZWRvaW5nIHRo
ZSBob3N0LW1ldGEgd29yayBmcm9tIHNjcmF0Y2ggaW4gYSBub24tY29tcGF0aWJsZSB3YXkganVz
dCBiZWNhdXNlIGEgaGFuZGZ1bCBvZiBwZW9wbGUgJ2xpa2UgaXQgYmV0dGVyJyB3aXRoIGxpdHRs
ZSB0ZWNobmljYWwganVzdGlmaWNhdGlvbi4NCg0KRWl0aGVyIHdheSwgdGhpcyBkaXNjdXNzaW9u
IGRvZXMgbm90IGJlbG9uZyBoZXJlLg0KDQpFSA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y
ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoDQo=

--_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5D4P3PW5EX1MB01E_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5
bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs
KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo
YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz
dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv
bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg
MTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h
bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7
fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw
Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp
bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250
LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N
c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90
dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7
fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD
aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g
VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT
dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv
bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu
O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp
bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTcyMzc0NTc2MzsNCgltc28tbGlz
dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQ0NjEyNzc0NiA2NzY5ODcw
MyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2
NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt
bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v
bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w
cHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg
bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGww
OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s
b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp
bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg
Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs
YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8
L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMg
bGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5J4oCZdmUgYWxyZWFkeSBhc2tlZCBmb3Ig
dGhlIGF1ZGlvIC8gdHJhbnNjcmlwdCAvIGRldGFpbGVkIG5vdGVzIG9mIHRoZSBtZWV0aW5nLiBB
bGwgSSBoYXZlIGlzIHlvdXIgbm90ZXMgcG9zdGVkIGVhcmxpZXIuIFVubGlrZSBtYW55IGluIHRo
aXMgV0csIE9BdXRoIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggbXkgZGF5IGpvYi4gTWVldGluZ3Mg
YXJlIG5vdCBhIHJlcXVpcmVkIHBhcnQgb2YgdGhlIElFVEYgcHJvY2VzcyBhbmQgc2VydmUgb25s
eSBhcyBpbnB1dCBmb3IgdGhlIG1haWxpbmcgbGlzdC4gVGhlIGlucHV0IHByb3ZpZGVkIGlzbuKA
mXQgdmVyeSBoZWxwZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh
c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+R2l2ZW4gbXkgYW5hbHlzaXMgYmVs
b3csIHdoYXQgaXMgbWlzc2luZyBpbiBjb21wYXJpc29uIHRvIHdoYXQgd2FzIGRpc2N1c3NlZD8g
V2hhdCBvdGhlciBwcm9jZXNzIGlzIGJlaW5nIGZvbGxvd2VkIHRvIGp1c3RpZnkgU1dEIGJlY29t
aW5nIGl0cyBvd24gdG9waWMgYW5kIG5vdCBhIHRlY2huaWNhbCB0b3BpYyB0byBiZSBkaXNjdXNz
ZWQgbGF0ZXI/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0
eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi
LCJzYW5zLXNlcmlmIic+IERlcmVrIEF0a2lucyBbbWFpbHRvOmRlcmVrQGlodGZwLmNvbV0gPGJy
PjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggMjksIDIwMTIgMTE6MTUgUE08YnI+PGI+VG86
PC9iPiBFcmFuIEhhbW1lcjsgV2lsbGlhbSBNaWxsczsgc2FhZ0BpZXRmLm9yZzsgb2F1dGhAaWV0
Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BVVRIIFJlcG9ydCBmb3Ig
SUVURi04MzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt
YWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t
Ym90dG9tOjEyLjBwdCc+WWVzLCB5b3UgYXJlIG1pc3NpbmcgdGhlIG1lZXRpbmcgd2UgaGFkIHll
c3RlcmRheSB3aGVyZSBpdCB3YXMgZGlzY3Vzc2VkIHRvIGJlIGFkZGVkIHRvIHRoZSBjaGFydGVy
Ljxicj48YnI+LWRlcmVrLCBXRyBDaGFpcjxicj48YnI+U2VudCBmcm9tIG15IEhUQyBvbiB0aGUg
Tm93IE5ldHdvcmsgZnJvbSBTcHJpbnQhPG86cD48L286cD48L3A+PGRpdiBpZD0iaHRjX2hlYWRl
ciI+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+LS0tLS0g
UmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtFcmFuIEhhbW1lciZxdW90OyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208
L2E+Jmd0Ozxicj5EYXRlOiBGcmksIE1hciAzMCwgMjAxMiA0OjI1IGFtPGJyPlN1YmplY3Q6IFtP
QVVUSC1XR10gT0FVVEggUmVwb3J0IGZvciBJRVRGLTgzPGJyPlRvOiAmcXVvdDtXaWxsaWFtIE1p
bGxzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb20iPndtaWxs
c0B5YWhvby1pbmMuY29tPC9hPiZndDssICZxdW90O0RlcmVrIEF0a2lucyZxdW90OyAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmRlcmVrQGlodGZwLmNvbSI+ZGVyZWtAaWh0ZnAuY29tPC9hPiZndDssICZx
dW90OzxhIGhyZWY9Im1haWx0bzpzYWFnQGlldGYub3JnIj5zYWFnQGlldGYub3JnPC9hPiZxdW90
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciPnNhYWdAaWV0Zi5vcmc8L2E+Jmd0
OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwv
YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5v
cmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O2NvbG9yOiMxRjQ5N0QnPlRoZSBuYXJyYXRpdmUgc28gZmFyOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+
VGhlIElFVEYgaGFzIGFkb3B0ZWQgaG9zdC1tZXRhIGFzIGEgZ2VuZXJhbC1wdXJwb3NlIGRpc2Nv
dmVyeSBtZWNoYW5pc20gaW4gUkZDIDY0MTUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBPcGVuSUQgQ29ubmVjdCBncm91
cCwgd2hpY2ggdXRpbGl6ZXMgT0F1dGggYnV0IGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBXRywg
YWRvcHRlZCBTV0QgYXMgaXRzIGRpc2NvdmVyeSBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBwcm9wb3Nl
ZCBjaGFydGVyIHJlZmVyZW5jZXMg4oCYT0F1dGggRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9u
IFByb3RvY29s4oCZLCB3aGljaCBpbiB0dXJuIHJlZmVyZW5jZXMgUkZDIDY0MTUgYXMgaXRzIGRp
c2NvdmVyeSBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BbSBJIG1pc3NpbmcgYSBXRyBp
dGVtIG9yIHByb3Bvc2VkIGRyYWZ0IHdoaWNoIHJlbGllcyBvbiBTV0QgYXQgdGhpcyB0aW1lPyBJ
ZiBJIGFtLCBhcmUgdGhlc2UgZG9jdW1lbnRzIGluY2x1ZGVkIGluIHRoZSBwcm9wb3NlZCBjaGFy
dGVyIG9yIGFyZSByZXF1ZXN0ZWQgdG8gYmUgaW5jbHVkZWQgKGUuZy4gbm90IFNXVCBpdHNlbGYg
YnV0IG90aGVyIGRvY3VtZW50cyB3aXRoIGRlcGVuZGVuY2llcyBvbiBpdCk/IEluIHN1Y2ggZG9j
dW1lbnRzLCBpcyBTV0QgYSByZXF1aXJlZCBjb21wb25lbnQgd2hpY2ggY2Fubm90IGJlIHN1YnN0
aXR1dGVkIHdpdGggc29tZXRoaW5nIGVsc2Ugc3VjaCBhcyBSRkMgNjQxNT88bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx
RjQ5N0QnPkhlcmUgaXMgaG93IHRoaXMgcHJvY2VzcyBzaG91bGQgd29yazo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3Rl
eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRM
aXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3Jl
Jz4xLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd
PjxzcGFuIGRpcj1MVFI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIFdHIGFncmVl
cyBvbiBpbmNsdWRpbmcgYSBkaXNjb3ZlcnkgcmVsYXRlZCBpdGVtIGluIGl0cyBjaGFydGVyLiBU
aGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIGlzIGEgcmVhc29uYWJsZSBzdWNoIGl0ZW0u
PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3Rl
eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRM
aXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3Jl
Jz4yLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd
PjxzcGFuIGRpcj1MVFI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIGNoYXJ0ZXIg
cmVmZXJlbmNlcyBhbiBleGlzdGluZyBwcm9wb3NhbCBhcyBmb3VuZGF0aW9uLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDot
LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+My48c3BhbiBz
dHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9
TFRSPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBXRyBiZWdpbnMgZGlzY3Vzc2lu
ZyB0aGUgcHJvcG9zZWQgZHJhZnQgKHdoaWNoIGNhbiBoYXBwZW4gYXQgYW55IHRpbWUgb24gdGhl
IGxpc3QgYXMgbG9uZyBhcyB0aGUgY2hhaXJzIGFsbG93IGl0KS48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21z
by1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y
OiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjQuPHNwYW4gc3R5bGU9J2Zv
bnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPUxUUj48L3Nw
YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgV0cgZGlzY3Vzc2VzIGFueSByZXF1aXJlZCBl
bmFibGluZyB0ZWNobm9sb2dpZXMsIHRoZWlyIHN1aXRhYmlsaXR5LCBtYXR1cml0eSwgaW5kdXN0
cnkgc3VwcG9ydCwgZXRjLiBJbiB0aGUgY2FzZSBvZiBkeW5hbWljIHJlZ2lzdHJhdGlvbiwgSSBl
eHBlY3QgdGhlIFdHIHRvIGRpc2N1c3MgU1dEIChiZWNhdXNlIGl0IGlzIHRoZSB0ZWNobm9sb2d5
IHNlbGVjdGVkIGJ5IHRoZSBPcGVuSUQgc3Vic2V0IG9mIHRoaXMgV0cpLCBob3N0LW1ldGEgKGJl
Y2F1c2UgaXQgaXMgYW4gSUVURiBwcm9wb3NlZCBzdGFuZGFyZCBSRkMpLCBhcyB3ZWxsIGFzIG90
aGVyIHNvbHV0aW9ucyAoTGluayBoZWFkZXJzLCBvdGhlciB3ZWxsLWtub3duIFVSSXMsIGV0Yy4p
LiBUaGUgcHVibGljYXRpb24gc3RhdHVzIG9mIHRoZSBwcm9wb3NlZCB0ZWNobm9sb2dpZXMgaXMg
YW5vdGhlciBmYWN0b3IuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJh
Z3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+
PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0n
bXNvLWxpc3Q6SWdub3JlJz41LjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t
YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48
L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj1MVFI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3
RCc+SWYgYW4gZW5hYmxpbmcgdGVjaG5vbG9neSBpcyBkZWNpZGVkIHRvIGJlIHRoZSBtb3N0IHN1
aXRhYmxlLCBhbmQgaXMgbm90IGF2YWlsYWJsZSBpbiBub3JtYXRpdmUgcmVmZXJlbmNlIGZvcm0s
IHRoZSBXRyB3aWxsIGRpc2N1c3MgdGhlIGJlc3Qgd2F5IHRvIGFjY29tcGxpc2ggdGhhdC4gVGhp
cyBpbmNsdWRlcyBpZGVudGlmeWluZyB0aGUgcmlnaHQgY29tbXVuaXR5LCBzdGFuZGFyZHMgYm9k
eSwgd29ya2luZyBncm91cCwgZXRjLiB0aGF0IGlzIGJlc3QgdG8gdGFrZSBvbiB0aGUgd29yay4g
SWYgbm8gc3VpdGFibGUgdmVudWUgaXMgZm91bmQsIHRoZSBXRyBtYXkgZGVjaWRlIHRvIHRha2Ug
b24gdGhlIHdvcmsgd2l0aCB2ZXJ5IGxpbWl0ZWQgc2NvcGUgb25seSB0byBlbmFibGUgaXRzIG93
biB1c2UgY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGFtIG5vdCBvcHBvc2VkIHRvIGhhdmlu
ZyB0aGlzIGRpc2N1c3Npb24sIGJ1dCB3aHkgYXJlICo8Yj53ZTwvYj4qIGhhdmluZyBpdCAqPGI+
bm93PC9iPiosIG90aGVyIHRoYW4gdGhlIE9wZW5JRCBDb25uZWN0IGdyb3VwLCB3aGljaCBoYXMg
bm90aGluZyB0byBkbyB3aXRoIHRoaXMgV0csIGlzIHN0dWNrIHdpdGggdGhlIHByb2JsZW0gb2Yg
ZmluZGluZyBhIHZlbnVlIGZvciB0aGlzIHdvcmssIGFuZCBhcmUgZHVtcGluZyBpdCBvbiBvdXIg
bGFwcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s
b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgZG8gbm90IHJlY2FsbCB0aGlzIFdHIGV2ZXIgZGVj
aWRlZCAob3IgZXZlbiAqPGI+cHJvcG9zZWQ8L2I+KikgdG8gdXNlIFNXRCBmb3IgYW55IG9mIGl0
cyBjaGFydGVyZWQgaXRlbXMuIFdoZW4gd2UgaGF2ZSB0aGlzIGRpc2N1c3Npb24sIEkgZXhwZWN0
IGl0IHRvIGluY2x1ZGUgYSBkZXRhaWxlZCBleGFtaW5hdGlvbiBvZiBob3N0LW1ldGEgYW5kIG90
aGVyIHNvbHV0aW9ucyAqPGI+YXMgZXF1YWw8L2I+KiBhbHRlcm5hdGl2ZXMuIFRoZSBPcGVuSUQg
Q29ubmVjdCBncm91cCBwcmVmZXJlbmNlIGlzIGEgdmFsaWQgaW5wdXQgYXMgaXQgY292ZXJzIHNv
bWUgcG90ZW50aWFsIG1hcmtldCBzaGFyZSB3aXRoIE9BdXRoIGRlcGxveW1lbnQsIGJ1dCBpdCBp
cyAqPGI+ZmFyPC9iPiogZnJvbSBhbnkgc2lnbmlmaWNhbnQgZGVwbG95bWVudCB3b3J0aHkgb2Yg
YnlwYXNzaW5nIHRoaXMgZXZhbHVhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFtIEkgbWlzc2lu
ZyBzb21ldGhpbmcgaGVyZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVIPG86cD48L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE
Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs
InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1
ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw
aW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy
aWYiJz4gV2lsbGlhbSBNaWxscyA8YSBocmVmPSJtYWlsdG86W21haWx0bzp3bWlsbHNAeWFob28t
aW5jLmNvbV0iPlttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21dPC9hPiA8YnI+PGI+U2VudDo8
L2I+IFRodXJzZGF5LCBNYXJjaCAyOSwgMjAxMiA0OjI2IFBNPGJyPjxiPlRvOjwvYj4gRXJhbiBI
YW1tZXI7IERlcmVrIEF0a2luczsgPGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciPnNhYWdA
aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYu
b3JnPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0FVVEggUmVwb3J0IGZv
ciBJRVRGLTgzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05v
cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0
eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDtmb250
LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5PbiB0aGUgU1dEIHN0dWZmIHRoZXJl
IHdhcyBnZW5lcmFsIGRpc2N1c3Npb24gYWJvdXQgJnF1b3Q7aXMgdGhpcyB0aGUgcmlnaHQgcGxh
Y2U/JnF1b3Q7LCBhbmQgdGhlcmUgJnF1b3Q7d2VyZSBpc3N1ZXMgcmFpc2VkJnF1b3Q7LiZuYnNw
OyBUaGUgcXVlc3Rpb24gd2FzIGFsc28gYXNrZWQgJnF1b3Q7d2VsbCwgd2hlcmUgaXMgdGhlIHJp
Z2h0IHBsYWNlPyZxdW90OyB3aGljaCBnb3QgY3JpY2tldHMuJm5ic3A7IEl0IGlzIGV4YWN0bHkg
Y29taW5nIGJhY2sgdG8gdGhlIGxpc3QgZm9yIGRpc2N1c3Npb24gdG8gc29ydCBvdXQgdGhlIHJp
Z2h0IHBsYWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxibG9ja3F1b3RlIHN0
eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6
MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6My43NXB0O21h
cmdpbi1ib3R0b206NS4wcHQnPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3
aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdj48
ZGl2PjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpj
ZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxociBzaXplPTEgd2lk
dGg9IjEwMCUiIGFsaWduPWNlbnRlcj48L3NwYW4+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0
eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh
bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gRXJhbiBIYW1tZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpl
cmFuQGh1ZW5pdmVyc2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDs8YnI+PGI+VG86
PC9iPiBEZXJlayBBdGtpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpkZXJla0BpaHRmcC5jb20iPmRl
cmVrQGlodGZwLmNvbTwvYT4mZ3Q7OyAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2FhZ0BpZXRmLm9y
ZyI+c2FhZ0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWFnQGlldGYu
b3JnIj5zYWFnQGlldGYub3JnPC9hPiZndDs7ICZxdW90OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBp
ZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1
dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDsgPGJyPjxiPlNlbnQ6PC9iPiBUaHVy
c2RheSwgTWFyY2ggMjksIDIwMTIgODo0NCBBTTxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVU
SC1XR10gT0FVVEggUmVwb3J0IGZvciBJRVRGLTgzPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi
bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls
ZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Nv
bG9yOmJsYWNrJz48YnI+SGkgRGVyZWssPGJyPjxicj5UaGFua3MgZm9yIHRoZSBub3Rlcy4gSXMg
YW4gYXVkaW8gcmVjb3JkaW5nIGF2YWlsYWJsZT88YnI+PGJyPiZndDsgLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS08YnI+Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWls
dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u
IEJlaGFsZjxicj4mZ3Q7IE9mIERlcmVrIEF0a2luczxicj4mZ3Q7IFNlbnQ6IFRodXJzZGF5LCBN
YXJjaCAyOSwgMjAxMiA4OjI3IEFNPGJyPiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpzYWFnQGll
dGYub3JnIj5zYWFnQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn
Ij5vYXV0aEBpZXRmLm9yZzwvYT48YnI+Jmd0OyBTdWJqZWN0OiBbT0FVVEgtV0ddIE9BVVRIIFJl
cG9ydCBmb3IgSUVURi04Mzxicj4mZ3Q7IDxicj4mZ3Q7IEhpLDxicj4mZ3Q7IDxicj4mZ3Q7IE9B
VVRIIG1ldCBlYXJsaWVyIHRoaXMgYWZ0ZXJub29uIGluIEFmdGVybm9vbiBTZXNzaW9uIEkgYXQg
MTNoMDAgZm9yIGEgdHdvPGJyPiZndDsgaG91ciBzZXNzaW9uLiZuYnNwOyBBZnRlciBpbnRyb2R1
Y2luZyBvdXJzZWx2ZXMgYW5kIHdlbGNvbWluZyBtZSB0byB0aGUgd29ya2luZzxicj4mZ3Q7IGdy
b3VwIHdlIHRoYW5rZWQgQmFycnkgYW5kIEJsYWluZSBmb3IgdGhlaXIgc2VydmljZS48YnI+Jmd0
OyA8YnI+Jmd0OyBUb3JzdGVuIHNwb2tlIGFib3V0IGRyYWZ0LWlldGYtb2F1dGgtdjItdGhyZWF0
bW9kZWwuJm5ic3A7IFRoaXMgZG9jdW1lbnQgaGFzPGJyPiZndDsgY29tcGxldGVkIFdHIExhc3Qg
Q2FsbC4mbmJzcDsgVG9yc3RlbiBoYXMgYXBwbGllZCBjaGFuZ2VzIGJhc2VkIG9uIHRoZSBMYXN0
IENhbGw8YnI+Jmd0OyBDb21tZW50cyBhbmQgaGFzIHB1Ymxpc2hlZCBhIG5ldyByZXZpc2lvbi4m
bmJzcDsgQmFycnkgcHJvbWlzZWQgdG8gZmluaXNoIGhpczxicj4mZ3Q7IFBST1RPIFNoZXBhcmQg
cmV2aWV3IG5leHQgd2VlayBzbyB3ZSBjYW4gc2VuZCB0aGlzIGRvY3VtZW50IHRvIHRoZTxicj4m
Z3Q7IElFU0cuJm5ic3A7IEhlIHByb21pc2VzIHRvIHRha2UgTWlrZSBUaG9tYXMnIGlzc3VlcyBm
cm9tIHRoZSBsaXN0IGludG8gYWNjb3VudCBhbmQ8YnI+Jmd0OyBtYWtlIHN1cmUgdGhhdCBldmVy
eW9uZSBpcyBoYXBweS48YnI+Jmd0OyA8YnI+Jmd0OyBbIEknZCBsaWtlIHRvIGV4dGVuZCBhIHBl
cnNvbmFsIHRoYW5rIHlvdSB0byBCYXJyeSBmb3IgY29udGludWluZyBoaXMgcm9sZTxicj4mZ3Q7
Jm5ic3A7IGFzIGRvY3VtZW50IHNoZXBoYXJkIGZvciB0aGlzIGRyYWZ0LiZuYnNwOyAtLSBkZXJl
ayBdPGJyPiZndDsgPGJyPiZndDsgTmV4dCwgTWlrZSBKb25lcyBzcG9rZSBhYm91dCB0aGUgQXNz
ZXJ0aW9ucywgU0FNTDIgQmVhcmVyLCBhbmQgVVJOLVN1Yi08YnI+Jmd0OyBOUyBkcmFmdHMuJm5i
c3A7IEV4Y2VwdCBmb3Igb25lIG91dHN0YW5kaW5nIGlzc3VlIE1pa2UgYmVsaWV2ZXMgdGhlc2Ug
ZG9jdW1lbnRzPGJyPiZndDsgYXJlIHJlYWR5IGZvciBXR0xDLiZuYnNwOyBDb25zZW5zdXMgaW4g
dGhlIHJvb20gd2FzIHRvIHRha2UgdGhlc2UgdGhyZWUgZG9jcyB0bzxicj4mZ3Q7IFdHTEMsIHdo
aWNoIHRoZSBjaGFpcnMgd2lsbCBkbyBieSB0aGUgZW5kIG9mIG5leHQgd2Vlay48YnI+Jmd0OyA8
YnI+Jmd0OyBUaGUgTUFDIFRva2VuIGRyYWZ0IGhhcyBsYW5ndWlzaGVkIHdoaWxlIHRpbWUgd2Fz
IHNwZW50IHdvcmtpbmcgb24gdGhlPGJyPiZndDsgY29yZSBkb2N1bWVudC4mbmJzcDsgRXJhbiB3
YXMgbm90IGhlcmUsIG5vciB3YXMgaGUgb25saW5lLCB0byB0YWxrIGFib3V0IHRoZTxicj4mZ3Q7
IHN0YXR1cyBvZiB0aGUgTUFDIFRva2VuIGRyYWZ0LiZuYnNwOyBUaGVyZSB3ZXJlIG9ubHkgYSBm
ZXcgcGVvcGxlIGluIHRoZSByb29tPGJyPiZndDsgaW50ZXJlc3RlZCBpbiByZXZpZXdpbmcgdGhl
IGRyYWZ0LCB3aGljaCB3YXMgbm90IGEgY2xlYXIgY29uc2Vuc3VzIG9mPGJyPiZndDsgaW50ZXJl
c3QsIGV2ZW4gdGhvdWdoIHRoaXMgZG9jdW1lbnQgZG9lcyBzb2x2ZSBhIHByb2JsZW0gdGhhdCB0
aGUgYmVhcmVyPGJyPiZndDsgdG9rZW5zIGNhbm5vdC4mbmJzcDsgVGhlIGNoYWlycyB3aWxsIHRh
a2UgaXQgdG8gdGhlIGxpc3QgdG8gZXZhbHVhdGUgaWYgdGhlcmUgaXMgZW5vdWdoPGJyPiZndDsg
aW50ZXJlc3QgdG8gY29udGludWUgd2l0aCB0aGlzIGRvY3VtZW50Ljxicj48YnI+QXMgSSd2ZSB1
cGRhdGVkIHRoZSBsaXN0IGFuZCBjaGFpcnMgb24gbXVsdGlwbGUgb2NjYXNpb25zLCB0aGUgZHJh
ZnQgaXMgcHJhY3RpY2FsbHkgcmVhZHkuIFRoZXJlIHdhcyBzb21lIGxhdGUgYXJyaXZpbmcgZmVl
ZGJhY2sgd2hpY2ggSSBkaWQgbm90IGdldCBhcm91bmQgdG8gcHJvY2Vzcy4gSG93ZXZlciwgdGhl
IG1haW4gaXNzdWUgaXMgbGFjayBvZiBXRyBpbnRlcmVzdCBpbiB0aGlzIHdvcmsuIEkgYW0gc3Rp
bGwgcGxhbm5pbmcgdG8gZmluaXNoIGl0IGJ5IG1ha2luZyB2ZXJ5IG1pbm9yIHR3ZWFrcyB0byB0
aGUgY3VycmVudCBkcmFmdCwgYnV0IHdvdWxkIGJlIHZlcnkgaGFwcHkgdG8gbWFrZSBpdCBhbiBp
bmRpdmlkdWFsIHN1Ym1pc3Npb24uPGJyPjxicj5UaGUgTUFDIGRyYWZ0IGhhcyBsYXJnZWx5IGJl
ZW4gbXkgcGVyc29uYWwgcHJvamVjdCB0byBkYXRlLjxicj48YnI+Jmd0OyBJbiBhIHJlbGF0ZWQg
bm90ZSwgdGhpcyBkb2N1bWVudCAoYXMgd2VsbCBhcyB0aGUgdjItYmVhcmVyIGRvY3VtZW50KSBp
cyBub3Q8YnI+Jmd0OyBhdmFpbGFibGUgb2ZmIHRoZSB0b29scyBwYWdlIGV2ZW4gdGhvdWdoIGl0
IGhhcyBub3QgZXhwaXJlZC4mbmJzcDsgSSBoYXZlIHRha2VuIHRoZTxicj4mZ3Q7IGFjdGlvbiBp
dGVtIHRvIGdldCB0aGF0IHNvcnRlZCBvdXQuPGJyPiZndDsgPGJyPiZndDsgRmluYWxseSwgd2Ug
c3BlbnQgdGhlIG1ham9yaXR5IG9mIG91ciB0aW1lIHRhbGtpbmcgYWJvdXQgcmVjaGFydGVyaW5n
IGJhc2VkIG9uPGJyPiZndDsgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgc2VudCB0byB0aGUgbGlzdCBi
eSBIYW5uZXMgYSB3ZWVrIG9yIHR3byBhZ28uPGJyPiZndDsgQ29uc2Vuc3VzIG9mIHRoZSByb29t
IHdhcyB0aGF0IHRoZXJlIHdhcyBlbm91Z2ggaW50ZXJlc3QgdG8gcmVjaGFydGVyPGJyPiZndDsg
YmFzZWQgcm91Z2hseSBvbiB0aGUgcHJvcG9zZWQgY2hhcnRlci4mbmJzcDsgVGhlcmUgd2FzIGFs
c28gY29uc2Vuc3VzIHRvIGluY2x1ZGU8YnI+Jmd0OyBTaW1wbGUgV2ViIERpc2NvdmVyeSAoaW4g
YWRkaXRpb24gdG8sIGFuZCBzZXBhcmF0ZSBmcm9tLCBEeW5hbWljIENsaWVudDxicj4mZ3Q7IFJl
Z2lzdHJhdGlvbiksIGFsdGhvdWdoIHdlIHdpbGwgbmVlZCB0byB3b3JrIHdpdGggdGhlIEFEcyB0
byBtYWtlIHN1cmUgaXQ8YnI+Jmd0OyBnZXRzIGhhbmRsZWQgaW4gdGhlIGFwcHJvcHJpYXRlIFdH
IGFuZCBBcmVhLjxicj4mZ3Q7IE1vcmVvdmVyLCBpdCdzIGltcG9ydGFudCB0byBtYWtlIHN1cmUg
dGhlIGFwcHJvcHJpYXRlIGFwcGxpY2F0aW9ucyBhcmVhPGJyPiZndDsgcGFydGljaXBhbnRzIGdl
dCBpbnZvbHZlZCBpbiB0aGUgU1dEIHdvcmsuPGJyPjxicj5UaGVyZSBpcyBzb21ldGhpbmcgdmVy
eSBhd2t3YXJkIGFib3V0IGRpc2N1c3NpbmcgU1dEIGJvdGggaW4gdGhlIGNvbnRleHQgb2YgdGhp
cyB3b3JraW5nIGdyb3VwLCBhbmQgaW4gdGhlIGNvbnRleHQgb2YgZnV0dXJlIE9BdXRoIGRpc2Nv
dmVyeSB3b3JrLiBUaGUgaWRlYSBvZiBwaWNraW5nIGEgZGlzY292ZXJ5IG1lY2hhbmlzbSBiZWZv
cmUgdGhlIFdHIGhhZCBhIHNpbmdsZSBkaXNjdXNzaW9uIGFib3V0IHdoYXQgaXMgaW5jbHVkZWQg
aW4gZGlzY292ZXJ5IGFuZCB3aGF0IGFyZSB0aGUgdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudCBp
cyBhYnN1cmQuPGJyPjxicj5UaGVyZSBoYXMgbm90IGJlZW4gY29uc2Vuc3VzIG9uIHRoZSBsaXN0
IGZvciBpbmNsdWRpbmcgU1dEIGluIHRoZSBXRyBjaGFydGVyLjxicj48YnI+VGhlIG9ubHkganVz
dGlmaWNhdGlvbiBJIGhhdmUgaGVhcmQgc28gZmFyIGZvciB0aGlzIFdHIHRvIGJlIHRoZSBTV0Qg
dmVudWUgaXMgdGhhdCBpdCdzIGVhc3kgYmVjYXVzZSB0aGUgYXV0aG9yIGFuZCBhIGZldyBvdGhl
ciBwZW9wbGUgaW50ZXJlc3RlZCBhcmUgYWxyZWFkeSBoZXJlLiBUaGF0J3Mgbm90IGEgdmFsaWQg
cmVhc29uLjxicj48YnI+QW55IGZ1cnRoZXIgd29yayBvbiBTV0QgYWxzbyByZXF1aXJlcyB0aGUg
SUVURiB0byB2aWV3IGl0IGluIGxpZ2h0IG9mIFJGQyA2NDE1IChob3N0LW1ldGEpIHdoaWNoIGlz
IGEgcHJvcG9zZWQgc3RhbmRhcmQgYXBwcm92ZWQgaW4gT2N0b2JlciAyMDExLiBUaGUgSUVURiBp
cyBub3QgaW4gdGhlICdmbGF2b3Igb2YgdGhlIG1vbnRoJyBidXNpbmVzcy4gUHJvcGVyIHByb2Nl
c3MgcmVxdWlyZXMgZGlzY3Vzc2lvbiBhYm91dCB0aGUgbWVyaXRzIG9mIHJlZG9pbmcgdGhlIGhv
c3QtbWV0YSB3b3JrIGZyb20gc2NyYXRjaCBpbiBhIG5vbi1jb21wYXRpYmxlIHdheSBqdXN0IGJl
Y2F1c2UgYSBoYW5kZnVsIG9mIHBlb3BsZSAnbGlrZSBpdCBiZXR0ZXInIHdpdGggbGl0dGxlIHRl
Y2huaWNhbCBqdXN0aWZpY2F0aW9uLjxicj48YnI+RWl0aGVyIHdheSwgdGhpcyBkaXNjdXNzaW9u
IGRvZXMgbm90IGJlbG9uZyBoZXJlLjxicj48YnI+RUg8YnI+PGJyPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPk9BdXRoIG1haWxpbmcgbGlzdDxicj48
YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj48YSBo
cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2
PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+

--_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5D4P3PW5EX1MB01E_--

From eran@hueniverse.com  Fri Mar 30 00:37:26 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CE421F8622 for ; Fri, 30 Mar 2012 00:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNZxrGydKM8M for ; Fri, 30 Mar 2012 00:37:25 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 67EAD21F85F4 for ; Fri, 30 Mar 2012 00:37:25 -0700 (PDT)
Received: (qmail 24476 invoked from network); 30 Mar 2012 07:37:24 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Mar 2012 07:37:24 -0000
Received: from P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id rjdQ1i0010U5vnL01jdQ03; Fri, 30 Mar 2012 00:37:24 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 30 Mar 2012 00:37:24 -0700
From: Eran Hammer 
To: William Mills , Derek Atkins , "saag@ietf.org" , "oauth@ietf.org" 
Date: Fri, 30 Mar 2012 00:37:15 -0700
Thread-Topic: [OAUTH-WG] OAUTH Report for IETF-83
Thread-Index: Ac0OPDQnyHD4N+ubRGuCp/Me96jLUgAA40mw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5D5@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1333087994.88149.YahooMailNeo@web31811.mail.mud.yahoo.com>
In-Reply-To: <1333087994.88149.YahooMailNeo@web31811.mail.mud.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 07:37:26 -0000

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV2lsbGlhbSBNaWxscyBb
bWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMjks
IDIwMTIgMTE6MTMgUE0NCj4gVG86IEVyYW4gSGFtbWVyOyBEZXJlayBBdGtpbnM7IHNhYWdAaWV0
Zi5vcmc7IG9hdXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BVVRIIFJl
cG9ydCBmb3IgSUVURi04Mw0KPiANCj4gVGhhbmtzIGZvciB0aGUgcHJvY2VzcyBsZWN0dXJlLi4u
LsKgIGV4Y2VwdCB3ZSBhbHJlYWR5IGhhZCBleHRlbnNpdmUNCj4gZGlzY3Vzc2lvbiBvZiBzYW1l
IGluIHRoZSBXRyBtZWV0aW5nLi4uDQoNClRoZSBjb21tZW50IHNoYXJlZCB3aXRoIHRoZSBsaXN0
IHdhczoNCg0KIlRoZXJlIHdhcyBhbHNvIGNvbnNlbnN1cyB0byBpbmNsdWRlIFNpbXBsZSBXZWIg
RGlzY292ZXJ5IChpbiBhZGRpdGlvbiB0bywgYW5kIHNlcGFyYXRlIGZyb20sIER5bmFtaWMgQ2xp
ZW50IFJlZ2lzdHJhdGlvbikiDQoNClRoaXMgImxlY3R1cmUiIGlzIG15IGF0dGVtcHQgYXQgdW5k
ZXJzdGFuZGluZyBob3cgdGhlIHBlb3BsZSBpbiB0aGUgcm9vbSAoSSB3YXMgdW5hYmxlIHRvIGFm
Zm9yZCBmbHlpbmcgdG8gUGFyaXMgb3IgYmUgdXAgYXQgNGFtKSBnb3QgZnJvbSB0aGUgRHluYW1p
YyBDbGllbnQgUmVnaXN0cmF0aW9uIHByb3Bvc2FsIHdoaWNoIGRvZXMgbm90IGV2ZW4gbWVudGlv
biBTV0QgKGJ1dCBkb2VzIHJlbHkgb24gYW4gb3V0ZGF0ZWQgdmVyc2lvbiBvZiBSRkMgNjQxNSks
IHRvIGluY2x1ZGluZyBTV0QgYXMgYSAic2VwYXJhdGUiIGl0ZW0gd2l0aG91dCBhbnkgZGlyZWN0
IGxpbmsgdG8gT0F1dGggKG90aGVyIHRoYW4gImludGVyZXN0IGluIHRoZSByb29tIikuDQoNClNp
bmNlIHRoZSBjaGFpciBpbXBsaWVkIHRoYXQgdGhlcmUgd2FzIGFscmVhZHkgY29uc2Vuc3VzICh3
aGljaCBpcyBhIHZlcnkgc2lnbmlmaWNhbnQgSUVURiBwcm9jZXNzIHN0YXRlbWVudCksIHJhaXNp
bmcgcHJvY2VzcyBpc3N1ZXMgaXMgb25lIHRvb2wgdGhlIElFVEYgcHJvdmlkZXMgZm9yIHRob3Nl
IGluIGRpc2FncmVlbWVudC4NCg0KPiBQYXJ0aWFsbHkgdGhpcyBpc3N1ZSB3YXMgcmFpc2VkIGJl
Y2F1c2UgbXkgZHJhZnQgZG9lcyBhIGRpc2NvdmVyeSB0aGluZyBhbmQgSQ0KPiB3YW50IHRoaXMg
c29ydGVkIG91dCB0byBmaWd1cmUgb3V0IHdoYXQgaG9va3MgSSBuZWVkIHRvIHB1dCBpbiBzbyBJ
IGNhbiBnZXQNCj4gZG9uZS7CoCBJIHdhbnQgdG8gYmUgY29uc2lzdGVudCB3aXRoIHdoYXRldmVy
IHdpbGwgYmUgdGhlIGNob3NlbiBzdGFuZGFyZGl6ZWQNCj4gdXNhZ2UuIEkgcmVhbGx5IERPIE5P
VCBjYXJlIGhvdyB3ZSBzb2x2ZSB0aGUgcHJvYmxlbSBhcyBsb25nIGFzIGl0J3Mgc29sdmVkLg0K
DQpJIERPIGNhcmUgaG93IHdlIHNvbHZlIHRoaXMgcHJvYmxlbSwgYnV0IG1vcmUgaW1wb3J0YW50
bHksIGRlZmluaW5nIHdoYXQgdGhlIHByb2JsZW0gYWN0dWFsbHkgaXMuIA0KDQo+IEkgdGhpbmsg
eW91ciBwb2ludCB0aGF0IGhvc3QtbWV0YSBhbmQgTElOSy9SRUwgc29sdmUgdGhlIHNhbWUgcHJv
YmxlbSBpcyBhDQo+IGZhaXIgb25lLCBpdCBjYW1lIHVwIGluIHRoZSByb29tLsKgIEFub3RoZXIg
Y29tbWVudCBpbiB0aGUgcm9vbSB3YXMgdGhhdCBmb3INCj4gSlMgYmFzZWQgc3R1ZmYgSlNPTiBp
cyBmYXIgZWFzaWVyIHRvIGRlYWwgd2l0aCB0aGFuIFhNTCwgYW5kIEkgdGhpbmsgdGhhdCdzDQo+
IHByb2JhYmx5IGFsc28gcmVhbGx5IHRydWUsIHNvIHRoZXJlIGFyZSBzb21lIGNvbXBldGluZyBp
c3Vlcy4NCg0KVGhpcyBqdXN0IHNob3dzIGhvdyBsaXR0bGUgdGVjaG5pY2FsIGR1ZS1kaWxpZ2Vu
Y2Ugd2FzIGRvbmUgYnkgdGhpcyBncm91cC4NCg0KUkZDIDY0MTUgcHJvdmlkZXMgZnVsbCBKU09O
IHN1cHBvcnQuIFRoZSBXZWJGaW5nZXIgZHJhZnQgd2hpY2ggc2xpZ2h0bHkgZXh0ZW5kcyBSRkMg
NjQxNSwgbWFrZXMgSlNPTiBzdXBwb3J0IHJlcXVpcmVkIGFuZCBhZGRzIHRoZSAncmVzb3VyY2Un
IHF1ZXJ5IHBhcmFtZXRlciBbMV0uIEEgYWRkaXRpb25hbCAncmVsJyBxdWVyeSBwYXJhbWV0ZXIg
aGFzIGFsc28gYmVlbiBwcm9wb3NlZCBhbmQgaXMgYmVpbmcgZGlzY3Vzc2VkIG9uIHRoZSBBUFBT
IGRpc2N1c3MgbGlzdC4NCg0KSSBndWVzcyBteSBxdWVzdGlvbiBpcywgd2h5IGlzbid0IFJGQyA2
NDE1IGJ5IHRoZSBzaW1wbGUgdmlydHVlIG9mIGl0IGJlaW5nIGEgcHVibGlzaCBJRVRGIHByb3Bv
c2VkIHN0YW5kYXJkIFJGQyB0aGUgZGVmYXVsdCBhbmQgb2J2aW91cyBjaG9pY2UgaGVyZT8gV2h5
IGlzbid0IHRoaXMgZGlzY3Vzc2lvbiBmcmFtZWQgaW4gdGVybXMgb2YgbWFraW5nIGVuaGFuY2Vt
ZW50cyB0byBSRkMgNjQxNSAoYXMgYWxyZWFkeSBpbiBwcm9ncmVzcyBieSB0aGUgV2ViRmluZ2Vy
IHByb3Bvc2FsLCB3aGljaCBCVFcsIGlzIGFsc28gdW5kZXIgZGlzY3Vzc2lvbiBmb3IgSUVURiB2
ZW51ZSkgb3IgaW4gdGVybXMgb2YgZGlzY3Vzc2luZyB3aHkgUkZDIDY0MTUgaXMgbm90IHRoZSBz
dWl0YWJsZSBjaG9pY2UgZm9yIHRoZSB5ZXQtdG8tYmUtZGVmaW5lZCBPQXV0aCBkaXNjb3Zlcnkg
ZnJhbWV3b3JrPw0KDQpJcyB0aGlzIGdyb3VwIGV2ZW4gYXdhcmUgdGhhdCB0aGUgNSB5ZWFycyBl
ZmZvcnQgKCEpIGxlYWRpbmcgdG8gUkZDIDY0MTUgd2FzIHByaW1hcmlseSBkb25lIGZvciBPQXV0
aCBkaXNjb3Zlcnk/IFRoZXJlIGlzIHNvIG11Y2ggcmVsZXZhbnQgaGlzdG9yeSBoZXJlIGJlaW5n
IGNvbXBsZXRlbHkgaWdub3JlZC4NCg0KSWYgdGhlIE9BdXRoIGNoYXJ0ZXIgaXMgZ29pbmcgdG8g
bWVudGlvbiBTV0QsIGl0IG11c3QgYWxzbyBtZW50aW9uIFJGQyA2NDE1IGFzIGFuIGVxdWFsIGFs
dGVybmF0aXZlIHRvIGJlIGRpc2N1c3NlZCBieSB0aGUgV0cuIFRoZSBjaGFydGVyIGRpc2N1c3Np
b24gaXMgY2xlYXJseSBub3QgdGhlIHBsYWNlIHRvIG1ha2UgdGhpcyBkZWNpc2lvbi4gSW4gYWRk
aXRpb24sIGlmIHRoaXMgV0cgaXMgZ29pbmcgdG8gYnVzeSBpdHNlbGYgd2l0aCBoZWxwaW5nIGZp
bmQgU1dEIGEgcHJvcGVyIGhvbWUsIHRoYXQgZGlzY3Vzc2lvbiBtdXN0IGFsc28gaW5jbHVkZSBm
aW5kaW5nIGEgcHJvcGVyIGhvbWUgZm9yIHRoZSBXZWJGaW5nZXIgcHJvcG9zYWwsIGdpdmVuIHRo
ZSBjbGVhciBJRVRGIGNvbmZsaWN0IGluIHByb21vdGluZyBib3RoLg0KDQpUaGUgZGlzY292ZXJ5
IHNvbHV0aW9uIGFkb3B0ZWQgYnkgT0F1dGggaXMgdmVyeSBsaWtlbHkgdG8gaGF2ZSBzaWduaWZp
Y2FudCBpbmZsdWVuY2Ugb3ZlciBmdXR1cmUgd2ViIGRpc2NvdmVyeSBiZXlvbmQgT0F1dGguIFRo
ZSBzdGFrZXMgaGVyZSBhcmUgcHJldHR5IGhpZ2guDQoNCkVIDQoNClsxXSBodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1hcHBzYXdnLXdlYmZpbmdlci0wMiNzZWN0aW9uLTQu
Mg0KDQo=

From rbarnes@bbn.com  Fri Mar 30 17:30:41 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A874121F8616 for ; Fri, 30 Mar 2012 17:30:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.552
X-Spam-Level: 
X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBNsCLWmfzCq for ; Fri, 30 Mar 2012 17:30:41 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 248E121F8618 for ; Fri, 30 Mar 2012 17:30:41 -0700 (PDT)
Received: from [128.89.255.57] (port=63625 helo=neutrino.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDmD1-0006wf-PA for oauth@ietf.org; Fri, 30 Mar 2012 20:30:23 -0400
Message-ID: <4F76502C.5040409@bbn.com>
Date: Sat, 31 Mar 2012 02:30:36 +0200
From: "Richard L. Barnes" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: oauth@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [OAUTH-WG] Review of draft-ietf-oauth-v2-http-mac-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 31 Mar 2012 00:30:41 -0000

As promised in the OAuth meeting at IETF 83, I have don a review of 
draft-ietf-oauth-v2-http-mac-01.  I have sent detailed comments to the 
authors, which are summarized below.

This document is in pretty good shape.  The definition of the 
authentication scheme itself, and the OAuth mechanism for distributing 
MAC parameters, both seem clearly specified and easy to implement. 
Modulo some minor comments, for example: The current normalized request 
seems to protect GET query parameters and not POST; this should either 
be corrected or noted.

The main area where I would like to see more work on this document is 
around operational considerations.  What parameters do servers need to 
maintain in order to manage timestamps and nonces?  How do they decide 
when they can forget nonces?

Thanks to the authors for their good work on this.  Looking forward to 
seeing the next version.

--Richard