From asanso@adobe.com Mon Feb 3 01:21:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55931A019C for ; Mon, 3 Feb 2014 01:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhg5XIyN4MRr for ; Mon, 3 Feb 2014 01:21:14 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 919981A0170 for ; Mon, 3 Feb 2014 01:21:13 -0800 (PST) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.868.8; Mon, 3 Feb 2014 09:21:02 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.56]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.56]) with mapi id 15.00.0868.013; Mon, 3 Feb 2014 09:21:01 +0000 From: Antonio Sanso To: George Fletcher Thread-Topic: [OAUTH-WG] Resource Owner Password Credential error response question Thread-Index: AQHPHENr+2LgCgqy6kGWjeyMWFC/apqjSfiA Date: Mon, 3 Feb 2014 09:21:00 +0000 Message-ID: References: <52E7D5FD.1080700@aol.com> In-Reply-To: <52E7D5FD.1080700@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.34.74.153] x-forefront-prvs: 01110342A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(377454003)(164054003)(24454002)(199002)(189002)(92726001)(93136001)(56816005)(224313003)(80976001)(15975445006)(94946001)(94316002)(87266001)(2656002)(74366001)(86362001)(90146001)(85306002)(224303002)(85852003)(81816001)(16236675002)(83072002)(92566001)(15395725003)(31966008)(74706001)(82746002)(83716003)(19580405001)(19580395003)(79102001)(77096001)(36756003)(74662001)(77982001)(74876001)(65816001)(33656001)(54356001)(47976001)(50986001)(76796001)(63696002)(54316002)(69226001)(76786001)(46102001)(66066001)(76482001)(53806001)(81542001)(74502001)(81342001)(51856001)(47446002)(83322001)(87936001)(81686001)(80022001)(49866001)(47736001)(56776001)(4396001)(59766001)(93516002)(15202345003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; CLIP:79.34.74.153; FPR:BCD6F935.A0125FE9.F9D37D8F.8EE4D970.2027B; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_C1DB3D66D21D40D6ACD88A3110F2C865adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Resource Owner Password Credential error response question X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 09:21:17 -0000 --_000_C1DB3D66D21D40D6ACD88A3110F2C865adobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jan 28, 2014, at 5:08 PM, George Fletcher > wrote: I have a situation where some "trusted" clients would like to use the ROPC = flow. However, there are a number of external circumstances that can block = the request even though the user's credentials are actually valid. Basicall= y, from a back-end perspective we want to force the user through a web flow= . I looked through the list of error responses and none seem to fit. 'inval= id_grant' is the closest but that wouldn't give the client any indication t= hat the user might be able to successfully complete the authorization flow = if the client sends the user through a web flow instead of the ROPC flow. Now I know one answer... which is... to just always use the web flow :) +1, :) why can=92t you use this in your case? regards antonio Has any one else run into this? Do I register a new error response via Sect= ion 11.4? In looking at the template it doesn't appear possible to add erro= r responses to an existing flow. Does that mean I'd need to create an extension grant that is basically the = same as the ROPC but because it's an extension now can have additional erro= r responses? Best practice guidance greatly appreciated! :) Thanks, George -- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C1DB3D66D21D40D6ACD88A3110F2C865adobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <60BF16D42DE59E45AF97F14516AF6F64@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On Jan 28, 2014, at 5:08 PM, George Fletcher <gffletch@aol.com> wrote:

I have a situation where some "trusted" clients would = like to use the ROPC flow. However, there are a number of external circumst= ances that can block the request even though the user's credentials are actually valid. Basically, from a back-end perspect= ive we want to force the user through a web flow. I looked through the list= of error responses and none seem to fit. 'invalid_grant' is the closest bu= t that wouldn't give the client any indication that the user might be able to successfully complete the au= thorization flow if the client sends the user through a web flow instead of= the ROPC flow.

Now I know one answer... which is... to just always use the web flow :)

+1, :) why can=92t you use this in your case?

regards

antonio


Has any one else run into this? Do I register a new error response via Sect= ion 11.4? In looking at the template it doesn't appear possible to add erro= r responses to an existing flow.

Does that mean I'd need to create an extension grant that is basically the = same as the ROPC but because it's an extension now can have additional erro= r responses?

Best practice guidance greatly appreciated! :)

Thanks,
George
--
<Mail Attachment.png>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_C1DB3D66D21D40D6ACD88A3110F2C865adobecom_-- From phil.hunt@oracle.com Mon Feb 3 12:17:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49DC1A01FB for ; Mon, 3 Feb 2014 12:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.236 X-Spam-Level: X-Spam-Status: No, score=-4.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q8GJyvWN24v for ; Mon, 3 Feb 2014 12:17:46 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A0DEA1A015A for ; Mon, 3 Feb 2014 12:17:46 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s13KHgpv005026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Feb 2014 20:17:43 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s13KHgDW017322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 20:17:42 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s13KHfS8012723; Mon, 3 Feb 2014 20:17:41 GMT Received: from [192.168.1.124] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Feb 2014 12:17:41 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com> Date: Mon, 3 Feb 2014 12:17:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com> To: Eve Maler X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 20:17:49 -0000 I am generally in agreement on the new drafts. Thanks Mike! Here are some comments: In the software statement section 3: > If the authorization server determines that the claims in a software > statement uniquely identify a piece of software, the same Client ID > value MAY be returned for all dynamic registrations using that > software statement. >=20 > In some cases, authorization servers MAY choose to accept a = software > statement value directly as a Client ID in an authorization = request, > without a prior dynamic client registration having been performed. > The circumstances under which an authorization server would do so, > and the specific software statement characteristics required in = this > case, are beyond the scope of this specification. >=20 We should call out that the server MAY also issue per instance = client_id's (the opposite of the first quoted paragraph above) if it = chooses to use client_id as an instance identifier (the software_id = identifies what clients are based on the same software). I think this = will be the typical use case. Not sure whether the first paragraph = should be re-written, or a new one added. Section 4.1 It would be good to have an example with a software statement and no = initial access token (or both). Section 5.1 Should we also say that is not necessary to return the software = statement. Note: the server should return the meta data that was = obtained from the statement. Dyn-Reg-Metadata The metadata document looks fine. I would prefer it being included in = dyn reg, but can live with it as is. Dyn-Reg-Management I'd like to discuss this more in London. I think a SCIM based = management API may be simpler to write up and can leverage the features = of SCIM without having to redefine them in a new API. Still, SCIM is a = way off from approval -- so I understand the need to move forward now. = Is experimental the right way to go? I am not sure. Glossary The terms Software API Publisher and Software API Deployer are defined = but never used, Specifically the text describing the issue of when these = are two distinct entities is missing. When publisher and deployer are = the same (eg. as with Facebook), the dynamic registration need is = minimal since a client_id can be issued from a single domain. When = publisher and deployer are different, such as with OpenID Connect, SCIM, = then the client developer cannot pre-register for a client_id at = development time. =20 The software statement is an optional mechanism that enables developers = to pre-registrater to obtain a signed statement (instead of a client_id) = so that API deployers can recognize the pre-registration relationship = with the publisher. Of course, software statements are optional if you = don't need to be able to recognize what the client is. (apologies if I = have not phrased the issue optimally) Maybe if we can put in a couple of paragraphs explaining this = distinction? =20 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2014-01-30, at 7:33 PM, Eve Maler wrote: > Hi Hannes-- The UMA Core spec currently points directly to the basic = dynamic client reg doc with MAY statements, and is agnostic as to usage = of the higher-order functions. (These turn into optional interop feature = tests.) So I think it's fair to say that the split has no structural = problems from an UMA perspective. >=20 > Eve >=20 > On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig = wrote: >=20 >> Hi all, >>=20 >> as you have seen from the meeting minutes of our recent status chat = it >> is time to proceed with the dynamic client registration work. >>=20 >> The earlier version of the dynamic client registration document was >> split into three parts, namely >> (1) the current working group draft containing only minimal >> functionality, >> (2) a document describing meta-data, and >> (3) a document containing management functionality. >>=20 >> This change was made as outcome of the discussions we had more or = less >> over the last 9 months. >>=20 >> The latter two documents are individual submissions at this point. = New >> content is not available with the recent changes. So, it is one of = those >> document management issues. >>=20 >> I had a chat with Stephen about WG adoption of the two individual >> submissions as WG items. It was OK for him given that it is a purely >> document management action. However, before we turn the documents = into >> WG items we need your feedback on a number of issues: >>=20 >> 1) Do you have concerns with the document split? Do you object or >> approve it? >> 2) Is the separation of the functionality into these three documents >> correct? Should the line be drawn differently? >> 3) Do you have comments on the documents overall? >>=20 >> We would like to receive high-level feedback within a week. We are = also >> eager to hear from implementers and other projects using the dynamic >> client registration work (such as OpenID Connect, UMA, the >> BlueButton/GreenButton Initiative, etc.) >>=20 >> For more detailed reviews please wait till we re-do the WGLC (which = we >> plan to do soon). We have to restart the WGLC due to discussions last >> years and the resulting changes to these documents. >>=20 >> Ciao >> Hannes & Derek >>=20 >> PS: Derek and I also think that Phil should become co-auhor of these >> documents for his contributions. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Mon Feb 3 18:36:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D901A0251 for ; Mon, 3 Feb 2014 18:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.235 X-Spam-Level: X-Spam-Status: No, score=-4.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IewpTipHinom for ; Mon, 3 Feb 2014 18:36:39 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 19AD51A01B6 for ; Mon, 3 Feb 2014 18:36:39 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B5E391F0427; Mon, 3 Feb 2014 21:36:38 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9552E1F0276; Mon, 3 Feb 2014 21:36:38 -0500 (EST) Received: from bva-172-31-10-76.mitre.org (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 3 Feb 2014 21:36:38 -0500 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Justin Richer In-Reply-To: Date: Mon, 3 Feb 2014 21:36:30 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6DE3797C-33A7-46DE-9B57-1A9C9E37DB94@mitre.org> References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com> To: Phil Hunt X-Mailer: Apple Mail (2.1827) X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 02:36:42 -0000 I still haven't done a deeply comprehensive read of the three posted = drafts, but I'm pretty happy with what I've read so far. Implementors = should note that if you merge all three drafts together you get = functionality that is compatible with -14 (plus software statements).=20 Some comments inline to respond to Phil's review: On Feb 3, 2014, at 3:17 PM, Phil Hunt wrote: > I am generally in agreement on the new drafts. Thanks Mike! >=20 > Here are some comments: >=20 > In the software statement section 3: >> If the authorization server determines that the claims in a software >> statement uniquely identify a piece of software, the same Client ID >> value MAY be returned for all dynamic registrations using that >> software statement. >>=20 >> In some cases, authorization servers MAY choose to accept a = software >> statement value directly as a Client ID in an authorization = request, >> without a prior dynamic client registration having been performed. >> The circumstances under which an authorization server would do so, >> and the specific software statement characteristics required in = this >> case, are beyond the scope of this specification. >>=20 >=20 > We should call out that the server MAY also issue per instance = client_id's (the opposite of the first quoted paragraph above) if it = chooses to use client_id as an instance identifier (the software_id = identifies what clients are based on the same software). I think this = will be the typical use case. Not sure whether the first paragraph = should be re-written, or a new one added. Agree that if we're going to call out the exception we should state the = rule. This might be better handled in text about the client_id itself, = but it should be referenced here as well. Perhaps with something simple = along the lines of "An Authorization Server will generally issue a new = client id for each dynamic registration. However, if the authorization = server determines [...]" >=20 > Section 4.1 > It would be good to have an example with a software statement and no = initial access token (or both). Perhaps we should move all but the most basic examples to a more = comprehensive appendix? Now that the matrix of optionality is increased = we should definitely *have* the examples of the different cases, but = there's probably not a good reason to put them all inline. >=20 > Section 5.1 > Should we also say that is not necessary to return the software = statement. Note: the server should return the meta data that was = obtained from the statement. Agree to both -- good catches. Though I think the server MAY return the = statement if it wants to, not really any harm in it. >=20 > Dyn-Reg-Metadata > The metadata document looks fine. I would prefer it being included in = dyn reg, but can live with it as is. I agree with Phil on this one. I would also rather it be inside the main = document but with the components marked as optional (as they are in = -14), but if there's a strong sentiment to keep them separate then this = is not a hill I care to die on. >=20 > Dyn-Reg-Management > I'd like to discuss this more in London. I think a SCIM based = management API may be simpler to write up and can leverage the features = of SCIM without having to redefine them in a new API. Still, SCIM is a = way off from approval -- so I understand the need to move forward now. = Is experimental the right way to go? I am not sure. I'm still in favor of a simple RESTful API for this, non-SCIM. SCIM = brings in a lot of weight with it (schemas and object types, data = models, etc). I completely understand that if you're doing SCIM then = it's simpler to have all of your object-management APIs be SCIM-based. = But it's important to realize that there are literally millions of = non-SCIM RESTful object provisioning and management APIs out there as = well, and they work fine. That said, if we can make sure (as best as we = can) to not step on any SCIM namespace bits that would make it difficult = to include the OAuth Dynamic Registration Client Model (tm) as a SCIM = object as part of a future SCIM extension, we should try to do that now. = That is to say, I think the best way forward is to define our own simple = RESTful API but leave the door wide open for the SCIM group to make = their own SCIM-based API to use at a future date as they see fit. >=20 > Glossary > The terms Software API Publisher and Software API Deployer are defined = but never used, Specifically the text describing the issue of when these = are two distinct entities is missing. When publisher and deployer are = the same (eg. as with Facebook), the dynamic registration need is = minimal since a client_id can be issued from a single domain. When = publisher and deployer are different, such as with OpenID Connect, SCIM, = then the client developer cannot pre-register for a client_id at = development time. =20 >=20 > The software statement is an optional mechanism that enables = developers to pre-registrater to obtain a signed statement (instead of a = client_id) so that API deployers can recognize the pre-registration = relationship with the publisher. Of course, software statements are = optional if you don't need to be able to recognize what the client is. = (apologies if I have not phrased the issue optimally) >=20 > Maybe if we can put in a couple of paragraphs explaining this = distinction? =20 Phil, I think you're in the best position to get these definitions = correct, so any text that you could contribute would be a good addition = here. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > On 2014-01-30, at 7:33 PM, Eve Maler wrote: >=20 >> Hi Hannes-- The UMA Core spec currently points directly to the basic = dynamic client reg doc with MAY statements, and is agnostic as to usage = of the higher-order functions. (These turn into optional interop feature = tests.) So I think it's fair to say that the split has no structural = problems from an UMA perspective. >>=20 >> Eve >>=20 >> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig = wrote: >>=20 >>> Hi all, >>>=20 >>> as you have seen from the meeting minutes of our recent status chat = it >>> is time to proceed with the dynamic client registration work. >>>=20 >>> The earlier version of the dynamic client registration document was >>> split into three parts, namely >>> (1) the current working group draft containing only minimal >>> functionality, >>> (2) a document describing meta-data, and >>> (3) a document containing management functionality. >>>=20 >>> This change was made as outcome of the discussions we had more or = less >>> over the last 9 months. >>>=20 >>> The latter two documents are individual submissions at this point. = New >>> content is not available with the recent changes. So, it is one of = those >>> document management issues. >>>=20 >>> I had a chat with Stephen about WG adoption of the two individual >>> submissions as WG items. It was OK for him given that it is a purely >>> document management action. However, before we turn the documents = into >>> WG items we need your feedback on a number of issues: >>>=20 >>> 1) Do you have concerns with the document split? Do you object or >>> approve it? >>> 2) Is the separation of the functionality into these three documents >>> correct? Should the line be drawn differently? >>> 3) Do you have comments on the documents overall? >>>=20 >>> We would like to receive high-level feedback within a week. We are = also >>> eager to hear from implementers and other projects using the dynamic >>> client registration work (such as OpenID Connect, UMA, the >>> BlueButton/GreenButton Initiative, etc.) >>>=20 >>> For more detailed reviews please wait till we re-do the WGLC (which = we >>> plan to do soon). We have to restart the WGLC due to discussions = last >>> years and the resulting changes to these documents. >>>=20 >>> Ciao >>> Hannes & Derek >>>=20 >>> PS: Derek and I also think that Phil should become co-auhor of these >>> documents for his contributions. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> Eve Maler = http://www.xmlgrrl.com/blog >> +1 425 345 6756 = http://www.twitter.com/xmlgrrl >>=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 phil.hunt@oracle.com Mon Feb 3 19:22:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F7B1A035E for ; Mon, 3 Feb 2014 19:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.236 X-Spam-Level: X-Spam-Status: No, score=-4.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NEE4J7jhLOF for ; Mon, 3 Feb 2014 19:22:34 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 499CA1A035C for ; Mon, 3 Feb 2014 19:22:34 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s143MXLA012020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Feb 2014 03:22:33 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s143MWkR018078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Feb 2014 03:22:32 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s143MWgO018073; Tue, 4 Feb 2014 03:22:32 GMT Received: from [192.168.1.124] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Feb 2014 19:22:32 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <6DE3797C-33A7-46DE-9B57-1A9C9E37DB94@mitre.org> Date: Mon, 3 Feb 2014 19:22:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <954F4101-CF29-4B93-9B7A-18F974E065AC@oracle.com> References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com> <6DE3797C-33A7-46DE-9B57-1A9C9E37DB94@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 03:22:37 -0000 Regarding glossary, I can take a shot unless Mike wants to first. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2014-02-03, at 6:36 PM, Justin Richer wrote: > I still haven't done a deeply comprehensive read of the three posted = drafts, but I'm pretty happy with what I've read so far. Implementors = should note that if you merge all three drafts together you get = functionality that is compatible with -14 (plus software statements).=20 >=20 > Some comments inline to respond to Phil's review: >=20 > On Feb 3, 2014, at 3:17 PM, Phil Hunt wrote: >=20 >> I am generally in agreement on the new drafts. Thanks Mike! >>=20 >> Here are some comments: >>=20 >> In the software statement section 3: >>> If the authorization server determines that the claims in a software >>> statement uniquely identify a piece of software, the same Client ID >>> value MAY be returned for all dynamic registrations using that >>> software statement. >>>=20 >>> In some cases, authorization servers MAY choose to accept a = software >>> statement value directly as a Client ID in an authorization = request, >>> without a prior dynamic client registration having been performed. >>> The circumstances under which an authorization server would do so, >>> and the specific software statement characteristics required in = this >>> case, are beyond the scope of this specification. >>>=20 >>=20 >> We should call out that the server MAY also issue per instance = client_id's (the opposite of the first quoted paragraph above) if it = chooses to use client_id as an instance identifier (the software_id = identifies what clients are based on the same software). I think this = will be the typical use case. Not sure whether the first paragraph = should be re-written, or a new one added. >=20 > Agree that if we're going to call out the exception we should state = the rule. This might be better handled in text about the client_id = itself, but it should be referenced here as well. Perhaps with something = simple along the lines of "An Authorization Server will generally issue = a new client id for each dynamic registration. However, if the = authorization server determines [...]" >=20 >>=20 >> Section 4.1 >> It would be good to have an example with a software statement and no = initial access token (or both). >=20 > Perhaps we should move all but the most basic examples to a more = comprehensive appendix? Now that the matrix of optionality is increased = we should definitely *have* the examples of the different cases, but = there's probably not a good reason to put them all inline. >=20 >>=20 >> Section 5.1 >> Should we also say that is not necessary to return the software = statement. Note: the server should return the meta data that was = obtained from the statement. >=20 > Agree to both -- good catches. Though I think the server MAY return = the statement if it wants to, not really any harm in it. >=20 >>=20 >> Dyn-Reg-Metadata >> The metadata document looks fine. I would prefer it being included = in dyn reg, but can live with it as is. >=20 > I agree with Phil on this one. I would also rather it be inside the = main document but with the components marked as optional (as they are in = -14), but if there's a strong sentiment to keep them separate then this = is not a hill I care to die on. >=20 >>=20 >> Dyn-Reg-Management >> I'd like to discuss this more in London. I think a SCIM based = management API may be simpler to write up and can leverage the features = of SCIM without having to redefine them in a new API. Still, SCIM is a = way off from approval -- so I understand the need to move forward now. = Is experimental the right way to go? I am not sure. >=20 > I'm still in favor of a simple RESTful API for this, non-SCIM. SCIM = brings in a lot of weight with it (schemas and object types, data = models, etc). I completely understand that if you're doing SCIM then = it's simpler to have all of your object-management APIs be SCIM-based. = But it's important to realize that there are literally millions of = non-SCIM RESTful object provisioning and management APIs out there as = well, and they work fine. That said, if we can make sure (as best as we = can) to not step on any SCIM namespace bits that would make it difficult = to include the OAuth Dynamic Registration Client Model (tm) as a SCIM = object as part of a future SCIM extension, we should try to do that now. = That is to say, I think the best way forward is to define our own simple = RESTful API but leave the door wide open for the SCIM group to make = their own SCIM-based API to use at a future date as they see fit. >=20 >>=20 >> Glossary >> The terms Software API Publisher and Software API Deployer are = defined but never used, Specifically the text describing the issue of = when these are two distinct entities is missing. When publisher and = deployer are the same (eg. as with Facebook), the dynamic registration = need is minimal since a client_id can be issued from a single domain. = When publisher and deployer are different, such as with OpenID Connect, = SCIM, then the client developer cannot pre-register for a client_id at = development time. =20 >>=20 >> The software statement is an optional mechanism that enables = developers to pre-registrater to obtain a signed statement (instead of a = client_id) so that API deployers can recognize the pre-registration = relationship with the publisher. Of course, software statements are = optional if you don't need to be able to recognize what the client is. = (apologies if I have not phrased the issue optimally) >>=20 >> Maybe if we can put in a couple of paragraphs explaining this = distinction? =20 >=20 > Phil, I think you're in the best position to get these definitions = correct, so any text that you could contribute would be a good addition = here. >=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> On 2014-01-30, at 7:33 PM, Eve Maler wrote: >>=20 >>> Hi Hannes-- The UMA Core spec currently points directly to the basic = dynamic client reg doc with MAY statements, and is agnostic as to usage = of the higher-order functions. (These turn into optional interop feature = tests.) So I think it's fair to say that the split has no structural = problems from an UMA perspective. >>>=20 >>> Eve >>>=20 >>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig = wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> as you have seen from the meeting minutes of our recent status chat = it >>>> is time to proceed with the dynamic client registration work. >>>>=20 >>>> The earlier version of the dynamic client registration document was >>>> split into three parts, namely >>>> (1) the current working group draft containing only minimal >>>> functionality, >>>> (2) a document describing meta-data, and >>>> (3) a document containing management functionality. >>>>=20 >>>> This change was made as outcome of the discussions we had more or = less >>>> over the last 9 months. >>>>=20 >>>> The latter two documents are individual submissions at this point. = New >>>> content is not available with the recent changes. So, it is one of = those >>>> document management issues. >>>>=20 >>>> I had a chat with Stephen about WG adoption of the two individual >>>> submissions as WG items. It was OK for him given that it is a = purely >>>> document management action. However, before we turn the documents = into >>>> WG items we need your feedback on a number of issues: >>>>=20 >>>> 1) Do you have concerns with the document split? Do you object or >>>> approve it? >>>> 2) Is the separation of the functionality into these three = documents >>>> correct? Should the line be drawn differently? >>>> 3) Do you have comments on the documents overall? >>>>=20 >>>> We would like to receive high-level feedback within a week. We are = also >>>> eager to hear from implementers and other projects using the = dynamic >>>> client registration work (such as OpenID Connect, UMA, the >>>> BlueButton/GreenButton Initiative, etc.) >>>>=20 >>>> For more detailed reviews please wait till we re-do the WGLC (which = we >>>> plan to do soon). We have to restart the WGLC due to discussions = last >>>> years and the resulting changes to these documents. >>>>=20 >>>> Ciao >>>> Hannes & Derek >>>>=20 >>>> PS: Derek and I also think that Phil should become co-auhor of = these >>>> documents for his contributions. >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> Eve Maler = http://www.xmlgrrl.com/blog >>> +1 425 345 6756 = http://www.twitter.com/xmlgrrl >>>=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 tonynad@microsoft.com Mon Feb 3 21:26:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800251A036A for ; Mon, 3 Feb 2014 21:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bF6VuzBzhEU for ; Mon, 3 Feb 2014 21:26:34 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 60D541A02D6 for ; Mon, 3 Feb 2014 21:26:34 -0800 (PST) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB310.namprd03.prod.outlook.com (10.141.48.25) with Microsoft SMTP Server (TLS) id 15.0.873.10; Tue, 4 Feb 2014 05:26:33 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0873.009; Tue, 4 Feb 2014 05:26:33 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed! Thread-Index: AQHPHZrcj5aIvhL6QUWwHABRilQciJqkjwrg Date: Tue, 4 Feb 2014 05:26:32 +0000 Message-ID: <576f34cc19fb4926978a5078504f3476@BLUPR03MB309.namprd03.prod.outlook.com> References: <52E87DE4.1070000@gmx.net> In-Reply-To: <52E87DE4.1070000@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.126.7] x-forefront-prvs: 01128BA907 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(377454003)(13464003)(53754006)(189002)(199002)(59766001)(77982001)(80022001)(79102001)(74706001)(69226001)(63696002)(65816001)(46102001)(33646001)(66066001)(74316001)(86612001)(31966008)(50986001)(47446002)(74876001)(74366001)(74502001)(53806001)(74662001)(4396001)(76482001)(54356001)(54316002)(56776001)(87936001)(47976001)(87266001)(2656002)(80976001)(51856001)(93136001)(85306002)(83322001)(76796001)(19580405001)(76576001)(94316002)(19580395003)(81686001)(56816005)(90146001)(83072002)(81342001)(47736001)(49866001)(76786001)(92566001)(81542001)(86362001)(93516002)(81816001)(94946001)(85852003)(42262001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB310; H:BLUPR03MB309.namprd03.prod.outlook.com; CLIP:50.46.126.7; FPR:BE6AD239.22F667AA.30D1BDFB.82E9DA41.203D2; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 05:26:36 -0000 So it's a tiny bit better but not sure it has captured all of what was bein= g proposed to fix the original, still not there. 1. The signature on the software statement should be optional=20 2. The software statement should be an assertion, the assertion can be what= ever profiles exist, I understand the desire this to be a JWT but that is t= oo limiting, for interop purposes this could be as JWT assertion. 3. The idea was to be able to remove the client secrets to reduce required = management for secrets, we need to get away from this -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, January 28, 2014 8:05 PM To: oauth@ietf.org Subject: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed! Hi all, as you have seen from the meeting minutes of our recent status chat it is t= ime to proceed with the dynamic client registration work. The earlier version of the dynamic client registration document was split i= nto three parts, namely (1) the current working group draft containing only minimal functionality= , (2) a document describing meta-data, and (3) a document containing management functionality. This change was made as outcome of the discussions we had more or less over= the last 9 months. The latter two documents are individual submissions at this point. New cont= ent is not available with the recent changes. So, it is one of those docume= nt management issues. I had a chat with Stephen about WG adoption of the two individual submissio= ns as WG items. It was OK for him given that it is a purely document manage= ment action. However, before we turn the documents into WG items we need yo= ur feedback on a number of issues: 1) Do you have concerns with the document split? Do you object or approve i= t? 2) Is the separation of the functionality into these three documents correc= t? Should the line be drawn differently? 3) Do you have comments on the documents overall? We would like to receive high-level feedback within a week. We are also eag= er to hear from implementers and other projects using the dynamic client re= gistration work (such as OpenID Connect, UMA, the BlueButton/GreenButton In= itiative, etc.) For more detailed reviews please wait till we re-do the WGLC (which we plan= to do soon). We have to restart the WGLC due to discussions last years and= the resulting changes to these documents. Ciao Hannes & Derek PS: Derek and I also think that Phil should become co-auhor of these docume= nts for his contributions. From wwwrun@rfc-editor.org Tue Feb 4 08:13:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801B01A013B for ; Tue, 4 Feb 2014 08:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6YpBOnH6VAL for ; Tue, 4 Feb 2014 08:13:40 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9961A0130 for ; Tue, 4 Feb 2014 08:13:40 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9A4007FC168; Tue, 4 Feb 2014 08:13:38 -0800 (PST) To: dick.hardt@gmail.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com From: RFC Errata System Message-Id: <20140204161338.9A4007FC168@rfc-editor.org> Date: Tue, 4 Feb 2014 08:13:38 -0800 (PST) Cc: eriksencosta@gmail.com, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:13:41 -0000 The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880 -------------------------------------- Type: Technical Reported by: Eriksen Costa Section: 10.16 Original Text ------------- For public clients using implicit flows, this specification does not provide any method for the client to determine what client an access token was issued to. Corrected Text -------------- For public clients using implicit flows, this specification does not provide any method for the authorization server to determine what client an access token was issued to. Notes ----- A client can only know about tokens issued to it and not for other clients. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From dick.hardt@gmail.com Tue Feb 4 08:17:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5601A0164 for ; Tue, 4 Feb 2014 08:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G_MYmFj8fm1 for ; Tue, 4 Feb 2014 08:16:58 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id E68FB1A0167 for ; Tue, 4 Feb 2014 08:16:57 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id e9so13637612qcy.26 for ; Tue, 04 Feb 2014 08:16:57 -0800 (PST) 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; bh=V9PwW4jLI7icuz0ieUw6/jvdOdVrt9eler0DYWnMy+E=; b=kQW+/HofBMVZPF+zYz5exLEgzS95GSkAXthdyA5kSwhWqaFon0UnWe/5khVExUIFpS eYK0OYOhlO88/DD0R3sRqCCfUCLDdZXpOzI9/8/IyWVRaJgzNV0m6f6Tm3DhUVnL5T74 bfLFVsoUvgtVgJjSfhmBG2ammknrllI2l4Mvef4gIhwyiBwFqgAAW7iCcBFq0B7KxdQw /CsHgvDIY4lSyJhdGWQCxvStsITl1MJ1Ff/P9FaKuGwCTz/IjW+6/v5sYYTPd3At7BxT 6hkwNYUu2cNgPCrqdonV2R/BCpfstR1dnj0Ir2R4Mf6Okl7QDZVpRVMNvYWEXsmodsis 4FLQ== X-Received: by 10.224.28.72 with SMTP id l8mr68636570qac.6.1391530617363; Tue, 04 Feb 2014 08:16:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.87.71 with HTTP; Tue, 4 Feb 2014 08:16:37 -0800 (PST) In-Reply-To: <20140204161338.9A4007FC168@rfc-editor.org> References: <20140204161338.9A4007FC168@rfc-editor.org> From: Dick Hardt Date: Tue, 4 Feb 2014 08:16:37 -0800 Message-ID: To: RFC Errata System Content-Type: multipart/alternative; boundary=001a11c1c9a62465be04f196f8d7 Cc: eriksencosta@gmail.com, turners@ieca.com, derek@ihtfp.com, OAuth WG Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:17:00 -0000 --001a11c1c9a62465be04f196f8d7 Content-Type: text/plain; charset=ISO-8859-1 This change is appropriate and reflects the intent of the statement. On Tue, Feb 4, 2014 at 8:13 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC6749, > "The OAuth 2.0 Authorization Framework". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880 > > -------------------------------------- > Type: Technical > Reported by: Eriksen Costa > > Section: 10.16 > > Original Text > ------------- > For public clients using implicit flows, this specification does not > provide any method for the client to determine what client an access > token was issued to. > > Corrected Text > -------------- > For public clients using implicit flows, this specification does not > provide any method for the authorization server to determine what > client an access token was issued to. > > Notes > ----- > A client can only know about tokens issued to it and not for other clients. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6749 (draft-ietf-oauth-v2-31) > -------------------------------------- > Title : The OAuth 2.0 Authorization Framework > Publication Date : October 2012 > Author(s) : D. Hardt, Ed. > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > --001a11c1c9a62465be04f196f8d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This change is appropriate and reflects the intent of the = statement.


On Tue, Feb 4, 2014 at 8:13 AM, RFC Errata System <= rfc-editor@r= fc-editor.org> wrote:
The following errata report has been submitt= ed for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D6749&eid=3D3880

--------------------------------------
Type: Technical
Reported by: Eriksen Costa <er= iksencosta@gmail.com>

Section: 10.16

Original Text
-------------
For public clients using implicit flows, this specification does not
provide any method for the client to determine what client an access
token was issued to.

Corrected Text
--------------
For public clients using implicit flows, this specification does not
provide any method for the authorization server to determine what
client an access token was issued to.

Notes
-----
A client can only know about tokens issued to it and not for other clients.=

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : The OAuth 2.0 Authorization Framework Publication Date =A0 =A0: October 2012
Author(s) =A0 =A0 =A0 =A0 =A0 : D. Hardt, Ed.
Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Web Authorization Protocol
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Security
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG

--001a11c1c9a62465be04f196f8d7-- From ve7jtb@ve7jtb.com Tue Feb 4 08:33:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DC21A01AE for ; Tue, 4 Feb 2014 08:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8Ef1gkYvzj1 for ; Tue, 4 Feb 2014 08:33:42 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id F04791A0130 for ; Tue, 4 Feb 2014 08:33:41 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id j5so12388226qaq.6 for ; Tue, 04 Feb 2014 08:33:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=uKw06yy91fXNcHdy9SbHBlwAmfSkhGjYEwtZhlIIrq0=; b=iPXtckGK+GjatZeqGG4e+UWl41XdsZWHhUZc7DQXx0F7UFNLb66iC3KtA25rYGwuTi uTFxE5s+ekTFzhZCGE6AdGmbzQoyqVCpt/+8IWShiKTY5R8rEaKmdf44vPqHBoPsp5Hh 1ad5Ci+m6QzWTrVrDHHc7ilfpcSpiMxIVIA7c2z0mcY1T/U2lwmomZRy1PeXCmHfrHW3 YSZP9e+012YP3BPpwp66er+LkF3Eq7iZi6U0ajt+Bn7wyS4ubKP5Wh5DKoLRmKVznd+B YIBvMQSTJtnnz3csLd292Gv5G4I+5XMqX5eSpcw3bttlX85sSFqWU/m7AwC0r0sjZHoc O6WQ== X-Gm-Message-State: ALoCoQmVNARC18+inMJophuE7BMjA//qqzbUNJw+lMpEn2aP38a0fNv+F5He+4QaRUyEUs7bLXeF X-Received: by 10.140.39.212 with SMTP id v78mr63495817qgv.77.1391531621380; Tue, 04 Feb 2014 08:33:41 -0800 (PST) Received: from [192.168.0.200] ([201.188.48.63]) by mx.google.com with ESMTPSA id z9sm32855237qgz.20.2014.02.04.08.33.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Feb 2014 08:33:38 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_BEE9B491-36BF-4E0B-8E76-08CE321EB1AA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: John Bradley In-Reply-To: <20140204161338.9A4007FC168@rfc-editor.org> Date: Tue, 4 Feb 2014 13:33:26 -0300 Message-Id: <9B180E22-D31A-48A7-A233-8F3DA05ABF71@ve7jtb.com> References: <20140204161338.9A4007FC168@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1827) Cc: eriksencosta@gmail.com, Sean Turner , Derek Atkins , oauth Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:33:49 -0000 --Apple-Mail=_BEE9B491-36BF-4E0B-8E76-08CE321EB1AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The text in 10.16 is correct. This is a security consideration that has caused serious problems for = Facebook and other implementers. In the Implicit flow there is no way for a client to know if a access = token was issued to it or another client. The UA presenting the access token in an implicit flow may be the = resource owner but may also be any other client that has ever received = an access token for the resource. In the implicit flow the Authorization server knows what client it has = issued a access token to via the registered redirect URI. The change doesn't reflect the intent of the security consideration. John B. On Feb 4, 2014, at 1:13 PM, RFC Errata System = wrote: > The following errata report has been submitted for RFC6749, > "The OAuth 2.0 Authorization Framework". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D3880 >=20 > -------------------------------------- > Type: Technical > Reported by: Eriksen Costa >=20 > Section: 10.16 >=20 > Original Text > ------------- > For public clients using implicit flows, this specification does not > provide any method for the client to determine what client an access > token was issued to. >=20 > Corrected Text > -------------- > For public clients using implicit flows, this specification does not > provide any method for the authorization server to determine what > client an access token was issued to. >=20 > Notes > ----- > A client can only know about tokens issued to it and not for other = clients. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6749 (draft-ietf-oauth-v2-31) > -------------------------------------- > Title : The OAuth 2.0 Authorization Framework > Publication Date : October 2012 > Author(s) : D. Hardt, Ed. > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_BEE9B491-36BF-4E0B-8E76-08CE321EB1AA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA0MTYzMzI2WjAjBgkqhkiG9w0BCQQxFgQUO+qH0k4m TxlkM8kC7MxM4thRGoYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAaWZVIkxU4CpC8ev575pSMoInm1+KyuN9VVuBpd6w YebCHwyjT02rc/aHWIqcdnPaZGgQwq0yyK3PJahKhsQGJ5+kQbKbEAzp8gtX6MJDWRXDwsd5MprR lk31AssidKFIqpBt2U8iav688zTa+VksovxuWbrSlwdLaXLNBg1/9KoMttrcJ5WobDoYQvA9gIoG 6v0ElqMxV2efSQx5LR5CAvvPDJFJRsUyYz8DIPHGvYlajK8C+o5037EDjp8ecFkEvKbT+aOsdAOx Tuqrt7nTDOwlzUKBq68852dDxLAGOGXhBhTxHuUGG/xeF+86Ie6i1i1Vv82Le30RFHLHzmtwHAAA AAAAAA== --Apple-Mail=_BEE9B491-36BF-4E0B-8E76-08CE321EB1AA-- From phil.hunt@oracle.com Tue Feb 4 08:58:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EF11A019F for ; Tue, 4 Feb 2014 08:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ5sn8pvyR1Y for ; Tue, 4 Feb 2014 08:58:41 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id BF1441A0135 for ; Tue, 4 Feb 2014 08:58:41 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s14Gwa3T005614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Feb 2014 16:58:37 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s14GwWdo022149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Feb 2014 16:58:33 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s14GwWOB008445; Tue, 4 Feb 2014 16:58:32 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Feb 2014 08:58:32 -0800 References: <20140204161338.9A4007FC168@rfc-editor.org> <9B180E22-D31A-48A7-A233-8F3DA05ABF71@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: <9B180E22-D31A-48A7-A233-8F3DA05ABF71@ve7jtb.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <78C9DCAB-0258-4AAE-9FE6-951AAC1BF47C@oracle.com> X-Mailer: iPhone Mail (11B554a) From: Phil Hunt Date: Tue, 4 Feb 2014 08:58:29 -0800 To: John Bradley X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "eriksencosta@gmail.com" , oauth , Derek Atkins , Sean Turner , RFC Errata System Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:58:44 -0000 +1 Phil > On Feb 4, 2014, at 8:33, John Bradley wrote: >=20 > The text in 10.16 is correct. >=20 > This is a security consideration that has caused serious problems for Face= book and other implementers. >=20 > In the Implicit flow there is no way for a client to know if a access toke= n was issued to it or another client. >=20 > The UA presenting the access token in an implicit flow may be the resource= owner but may also be any other client that has ever received an access tok= en for the resource. >=20 > In the implicit flow the Authorization server knows what client it has iss= ued a access token to via the registered redirect URI. >=20 > The change doesn't reflect the intent of the security consideration. >=20 > John B. >=20 >=20 >> On Feb 4, 2014, at 1:13 PM, RFC Errata System = wrote: >>=20 >> The following errata report has been submitted for RFC6749, >> "The OAuth 2.0 Authorization Framework". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D3880 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Eriksen Costa >>=20 >> Section: 10.16 >>=20 >> Original Text >> ------------- >> For public clients using implicit flows, this specification does not >> provide any method for the client to determine what client an access >> token was issued to. >>=20 >> Corrected Text >> -------------- >> For public clients using implicit flows, this specification does not >> provide any method for the authorization server to determine what >> client an access token was issued to. >>=20 >> Notes >> ----- >> A client can only know about tokens issued to it and not for other client= s. >>=20 >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC6749 (draft-ietf-oauth-v2-31) >> -------------------------------------- >> Title : The OAuth 2.0 Authorization Framework >> Publication Date : October 2012 >> Author(s) : D. Hardt, Ed. >> Category : PROPOSED STANDARD >> Source : Web Authorization Protocol >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> 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 dick.hardt@gmail.com Tue Feb 4 10:28:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48921A0125 for ; Tue, 4 Feb 2014 10:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zcXKtnvVYEa for ; Tue, 4 Feb 2014 10:28:13 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA9F1A0164 for ; Tue, 4 Feb 2014 10:28:08 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id e16so14125370qcx.21 for ; Tue, 04 Feb 2014 10:28:07 -0800 (PST) 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; bh=pGbL4uc/onQ5A+OovenJF9OfjWlWf5p09J5M0d/B1pY=; b=THItKho26KjJ3Qr1FstH/vbSwL76Ybvyr8petydmdunUHhxl3RVfk7u2YIU2bKKgqC m4oWrIdzkooEeLDu9MSYQOtoyuOOPgw86VzoLt+hLIzU20X5GQzszmiERX+R1ssd7mQf MvxmQU0g4A6JDkp2Pb1THsTD8g0nu6BINwZ/eQ9qUfbsIamR3sR6ncOalI1bo+H6gs2/ c/JMMAq+pDx5/tWoAbXBHN7rw4z1agwj1e4X5jgUSVA/+UFcuPXXbmyBoQfX81kDP+IU CTsJo860gSd/tiaQ9Wsme6hE0KXB5iON5BEcSq8jXVpsnEqJeNn/pm3Dr4/a2pjfL9jA Q1dg== X-Received: by 10.140.31.247 with SMTP id f110mr64213839qgf.58.1391538487623; Tue, 04 Feb 2014 10:28:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.87.71 with HTTP; Tue, 4 Feb 2014 10:27:47 -0800 (PST) In-Reply-To: <78C9DCAB-0258-4AAE-9FE6-951AAC1BF47C@oracle.com> References: <20140204161338.9A4007FC168@rfc-editor.org> <9B180E22-D31A-48A7-A233-8F3DA05ABF71@ve7jtb.com> <78C9DCAB-0258-4AAE-9FE6-951AAC1BF47C@oracle.com> From: Dick Hardt Date: Tue, 4 Feb 2014 10:27:47 -0800 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a113a9c023f05a704f198cd1a Cc: "eriksencosta@gmail.com" , Sean Turner , Derek Atkins , oauth , RFC Errata System Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 18:28:25 -0000 --001a113a9c023f05a704f198cd1a Content-Type: text/plain; charset=ISO-8859-1 My bad, sorry. On Tue, Feb 4, 2014 at 8:58 AM, Phil Hunt wrote: > +1 > > Phil > > > On Feb 4, 2014, at 8:33, John Bradley wrote: > > > > The text in 10.16 is correct. > > > > This is a security consideration that has caused serious problems for > Facebook and other implementers. > > > > In the Implicit flow there is no way for a client to know if a access > token was issued to it or another client. > > > > The UA presenting the access token in an implicit flow may be the > resource owner but may also be any other client that has ever received an > access token for the resource. > > > > In the implicit flow the Authorization server knows what client it has > issued a access token to via the registered redirect URI. > > > > The change doesn't reflect the intent of the security consideration. > > > > John B. > > > > > >> On Feb 4, 2014, at 1:13 PM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > >> > >> The following errata report has been submitted for RFC6749, > >> "The OAuth 2.0 Authorization Framework". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Eriksen Costa > >> > >> Section: 10.16 > >> > >> Original Text > >> ------------- > >> For public clients using implicit flows, this specification does not > >> provide any method for the client to determine what client an access > >> token was issued to. > >> > >> Corrected Text > >> -------------- > >> For public clients using implicit flows, this specification does not > >> provide any method for the authorization server to determine what > >> client an access token was issued to. > >> > >> Notes > >> ----- > >> A client can only know about tokens issued to it and not for other > clients. > >> > >> Instructions: > >> ------------- > >> This errata is currently posted as "Reported". If necessary, please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party (IESG) > >> can log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC6749 (draft-ietf-oauth-v2-31) > >> -------------------------------------- > >> Title : The OAuth 2.0 Authorization Framework > >> Publication Date : October 2012 > >> Author(s) : D. Hardt, Ed. > >> Category : PROPOSED STANDARD > >> Source : Web Authorization Protocol > >> Area : Security > >> Stream : IETF > >> Verifying Party : IESG > >> _______________________________________________ > >> 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 > --001a113a9c023f05a704f198cd1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My bad, sorry.


On Tue, Feb 4, 2014 at 8:58 AM, Phil Hunt <phil= .hunt@oracle.com> wrote:
+1

Phil

> On Feb 4, 2014, at 8:33, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> The text in 10.16 is correct.
>
> This is a security consideration that has caused serious problems for = Facebook and other implementers.
>
> In the Implicit flow there is no way for a client to know if a access = token was issued to it or another client.
>
> The UA presenting the access token in an implicit flow may be the reso= urce owner but may also be any other client that has ever received an acces= s token for the resource.
>
> In the implicit flow the Authorization server knows what client it has= issued a access token to via the registered redirect URI.
>
> The change doesn't reflect the intent of the security consideratio= n.
>
> John B.
>
>
>> On Feb 4, 2014, at 1:13 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>>
>> The following errata report has been submitted for RFC6749,
>> "The OAuth 2.0 Authorization Framework".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.p= hp?rfc=3D6749&eid=3D3880
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Eriksen Costa <eriksencosta@gmail.com>
>>
>> Section: 10.16
>>
>> Original Text
>> -------------
>> For public clients using implicit flows, this specification does n= ot
>> provide any method for the client to determine what client an acce= ss
>> token was issued to.
>>
>> Corrected Text
>> --------------
>> For public clients using implicit flows, this specification does n= ot
>> provide any method for the authorization server to determine what<= br> >> client an access token was issued to.
>>
>> Notes
>> -----
>> A client can only know about tokens issued to it and not for other= clients.
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necess= ary, please
>> use "Reply All" to discuss whether it should be verified= or
>> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=
>>
>> --------------------------------------
>> RFC6749 (draft-ietf-oauth-v2-31)
>> --------------------------------------
>> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : The OAuth 2.0 Authorization Fr= amework
>> Publication Date =A0 =A0: October 2012
>> Author(s) =A0 =A0 =A0 =A0 =A0 : D. Hardt, Ed.
>> Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
>> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Web Authorization Protocol
>> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Security
>> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
>> Verifying Party =A0 =A0 : IESG
>> _______________________________________________
>> 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
h= ttps://www.ietf.org/mailman/listinfo/oauth

--001a113a9c023f05a704f198cd1a-- From prateek.mishra@oracle.com Tue Feb 4 10:51:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAD21A0169 for ; Tue, 4 Feb 2014 10:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5zarNk2k6xY for ; Tue, 4 Feb 2014 10:51:03 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id BF3B01A0125 for ; Tue, 4 Feb 2014 10:51:03 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s14IowbZ017436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Feb 2014 18:50:59 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s14IouWD008100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Feb 2014 18:50:56 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s14Iot3N008076; Tue, 4 Feb 2014 18:50:55 GMT Received: from [130.35.50.173] (/130.35.50.173) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Feb 2014 10:50:55 -0800 Message-ID: <52F1368D.9040106@oracle.com> Date: Tue, 04 Feb 2014 10:50:53 -0800 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: John Bradley , RFC Errata System References: <20140204161338.9A4007FC168@rfc-editor.org> <9B180E22-D31A-48A7-A233-8F3DA05ABF71@ve7jtb.com> In-Reply-To: <9B180E22-D31A-48A7-A233-8F3DA05ABF71@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------090306020203040307090309" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: eriksencosta@gmail.com, Derek Atkins , Sean Turner , oauth Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 18:51:06 -0000 This is a multi-part message in MIME format. --------------090306020203040307090309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Well, the proposed correction does point to a genuine security hazard Specifically, when client instances share the same re-direct URI, typically mobile clients this is independent of whether implicit or code flows are used It is only injective clients - each of whose instances bind to unique redirect URLs - that can support discriminative Az servers So I would re-phrase the proposed text as: [quote] For public, non-injective clients, this specification does not provide any method for the authorization server to determine what client an access token was issued to. [\quote] - prateek > The text in 10.16 is correct. > > This is a security consideration that has caused serious problems for Facebook and other implementers. > > In the Implicit flow there is no way for a client to know if a access token was issued to it or another client. > > The UA presenting the access token in an implicit flow may be the resource owner but may also be any other client that has ever received an access token for the resource. > > In the implicit flow the Authorization server knows what client it has issued a access token to via the registered redirect URI. > > The change doesn't reflect the intent of the security consideration. > > John B. > > > On Feb 4, 2014, at 1:13 PM, RFC Errata System wrote: > >> The following errata report has been submitted for RFC6749, >> "The OAuth 2.0 Authorization Framework". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880 >> >> -------------------------------------- >> Type: Technical >> Reported by: Eriksen Costa >> >> Section: 10.16 >> >> Original Text >> ------------- >> For public clients using implicit flows, this specification does not >> provide any method for the client to determine what client an access >> token was issued to. >> >> Corrected Text >> -------------- >> For public clients using implicit flows, this specification does not >> provide any method for the authorization server to determine what >> client an access token was issued to. >> >> Notes >> ----- >> A client can only know about tokens issued to it and not for other clients. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6749 (draft-ietf-oauth-v2-31) >> -------------------------------------- >> Title : The OAuth 2.0 Authorization Framework >> Publication Date : October 2012 >> Author(s) : D. Hardt, Ed. >> Category : PROPOSED STANDARD >> Source : Web Authorization Protocol >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> 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 --------------090306020203040307090309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well, the proposed correction does point to a genuine security hazard

Specifically, when client instances share the same re-direct URI, typically mobile clients

this is independent of whether implicit or code flows are used

It is only injective clients - each of whose instances bind to unique redirect URLs - that can support discriminative Az servers

So I would re-phrase the proposed text as:

[quote]
For public, non-injective clients, this specification does not
provide any method for the authorization server to determine what
client an access token was issued to.
[\quote]

- prateek


The text in 10.16 is correct.

This is a security consideration that has caused serious problems for Facebook and other implementers.

In the Implicit flow there is no way for a client to know if a access token was issued to it or another client.

The UA presenting the access token in an implicit flow may be the resource owner but may also be any other client that has ever received an access token for the resource.

In the implicit flow the Authorization server knows what client it has issued a access token to via the registered redirect URI.

The change doesn't reflect the intent of the security consideration.

John B.


On Feb 4, 2014, at 1:13 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:


The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880

--------------------------------------
Type: Technical
Reported by: Eriksen Costa <eriksencosta@gmail.com>

Section: 10.16

Original Text
-------------
For public clients using implicit flows, this specification does not
provide any method for the client to determine what client an access
token was issued to.

Corrected Text
--------------
For public clients using implicit flows, this specification does not
provide any method for the authorization server to determine what
client an access token was issued to.

Notes
-----
A client can only know about tokens issued to it and not for other clients.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework
Publication Date    : October 2012
Author(s)           : D. Hardt, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
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


    

    

  


--------------090306020203040307090309--

From wmills_92105@yahoo.com  Tue Feb  4 10:56:14 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891781A0164 for ; Tue,  4 Feb 2014 10:56:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.033
X-Spam-Level: 
X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgBG55lL6NOP for ; Tue,  4 Feb 2014 10:56:12 -0800 (PST)
Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) by ietfa.amsl.com (Postfix) with ESMTP id DC8CA1A01DD for ; Tue,  4 Feb 2014 10:56:11 -0800 (PST)
Received: from [98.139.215.142] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2014 18:56:11 -0000
Received: from [98.139.212.208] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2014 18:56:11 -0000
Received: from [127.0.0.1] by omp1017.mail.bf1.yahoo.com with NNFMP; 04 Feb 2014 18:56:11 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 91808.43864.bm@omp1017.mail.bf1.yahoo.com
Received: (qmail 76959 invoked by uid 60001); 4 Feb 2014 18:56:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1391540170; bh=Xg9Q5rYcwyv9NjHLkl65d9E7aMcWtG0mqSkEkRxGd3M=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vZ5qVPXaFYq+0KPiFNxQID+CW6dNISm/NNjrUT0NxfpUV99Eh85o7tPN3Y3Pk2l8wRsZ0c2cNgBBUy8W1X9oOxUVu08b/OULfDz9KEMYmAIIIfGzJCEYWBWhuinWSS400N/y0wHKuGBt8R+hAyLK5C2EbhenZYkIiqSC2vwT0/Y=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zwTGeyzxud7hmsbN5ksFJTNwKYDeut76BZG7GQIn6E/7PCksmGVvEpGYCkT8dH8SANBeGyHvvNxDVsL7yCisvzJxlzmTiqeH8QNNNMN6nixY8/Y2KuIsWBjFngskv1hmwWTG3UiZRzrtLFvKam52/HIv+JqeSW2x9RLsx2I/fqU=;
X-YMail-OSG: yR1cTbwVM1k5yGYUmEvtU6aVr5fun32FmPMdovEP8EmNmQ_ JLO7tZrlUJFRMZUMC91MRGJ8dCjc4SdfvZtQCu8CETdyvUOKCeNMkJib3mIG oqISZOnyR2wH11R4gk.qM9sXKHOxJsFXvzWoJuhUB6w9y22AYIbpOZsEwzry 95Zg9DvRhQAS_siHnwAJX8qtz9UzNWChkT4xRr4eIGzIzZZP.AgQngoA3lnd Q6xAF0rVaJLltLCwMivsh8ATZoJrh3GCAGRY9c91FxHz4vm3cDEc7qSr0ogl 4xdHonc10F2XoWwfKkS6lMKZSQDg12SD84VzR6UnYdizeFgaI3AoN3lNzwZl n31UM5_wTgN1qfiIl04y1U4mhYjHaeBEJ9KLzhnWQQJ0Uzyirz.dxuIS.03j xcCDWC7811WMnyukIxzloi7qiCwD3.KPN_kJeRx2Xe762X3o0HsWQgpVib98 VrNxv.utmF1mcJvVwOHB9TRDI1yx191JTCAm1sGjG1jtUCeSQmkXoQOB01uO oOY8oEHFIOMwBVKaha72GxkMb26cUm9bLWNYddfToVZ4ysUgKSbSuJ_KVONh B8w5U80fmcapqra_JYU7FR5Ui
Received: from [66.228.162.44] by web142801.mail.bf1.yahoo.com via HTTP; Tue, 04 Feb 2014 10:56:10 PST
X-Rocket-MIMEInfo: 002.001, QWdyZWVkLgoKCgpPbiBUdWVzZGF5LCBGZWJydWFyeSA0LCAyMDE0IDg6MTcgQU0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPiB3cm90ZToKIApUaGlzIGNoYW5nZSBpcyBhcHByb3ByaWF0ZSBhbmQgcmVmbGVjdHMgdGhlIGludGVudCBvZiB0aGUgc3RhdGVtZW50LgoKCgpPbiBUdWUsIEZlYiA0LCAyMDE0IGF0IDg6MTMgQU0sIFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPiB3cm90ZToKClRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWIBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.174.630
References: <20140204161338.9A4007FC168@rfc-editor.org> 
Message-ID: <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com>
Date: Tue, 4 Feb 2014 10:56:10 -0800 (PST)
From: Bill Mills 
To: Dick Hardt , RFC Errata System 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="469468616-1184692804-1391540170=:23334"
Cc: "eriksencosta@gmail.com" , "derek@ihtfp.com" , "turners@ieca.com" , OAuth WG 
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Feb 2014 18:56:14 -0000

--469468616-1184692804-1391540170=:23334
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Agreed.=0A=0A=0A=0AOn Tuesday, February 4, 2014 8:17 AM, Dick Hardt  wrote:=0A =0AThis change is appropriate and reflects the in=
tent of the statement.=0A=0A=0A=0AOn Tue, Feb 4, 2014 at 8:13 AM, RFC Errat=
a System  wrote:=0A=0AThe following errata repor=
t has been submitted for RFC6749,=0A>"The OAuth 2.0 Authorization Framework=
".=0A>=0A>--------------------------------------=0A>You may review the repo=
rt below and at:=0A>http://www.rfc-editor.org/errata_search.php?rfc=3D6749&=
eid=3D3880=0A>=0A>--------------------------------------=0A>Type: Technical=
=0A>Reported by: Eriksen Costa =0A>=0A>Section: 10.=
16=0A>=0A>Original Text=0A>-------------=0A>For public clients using implic=
it flows, this specification does not=0A>provide any method for the client =
to determine what client an access=0A>token was issued to.=0A>=0A>Corrected=
 Text=0A>--------------=0A>For public clients using implicit flows, this sp=
ecification does not=0A>provide any method for the authorization server to =
determine what=0A>client an access token was issued to.=0A>=0A>Notes=0A>---=
--=0A>A client can only know about tokens issued to it and not for other cl=
ients.=0A>=0A>Instructions:=0A>-------------=0A>This errata is currently po=
sted as "Reported". If necessary, please=0A>use "Reply All" to discuss whet=
her it should be verified or=0A>rejected. When a decision is reached, the v=
erifying party (IESG)=0A>can log in to change the status and edit the repor=
t, if necessary.=0A>=0A>--------------------------------------=0A>RFC6749 (=
draft-ietf-oauth-v2-31)=0A>--------------------------------------=0A>Title =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 : The OAuth 2.0 Authorization Framework=0A>Publ=
ication Date =A0 =A0: October 2012=0A>Author(s) =A0 =A0 =A0 =A0 =A0 : D. Ha=
rdt, Ed.=0A>Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD=0A>Source =
=A0 =A0 =A0 =A0 =A0 =A0 =A0: Web Authorization Protocol=0A>Area =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0: Security=0A>Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF=
=0A>Verifying Party =A0 =A0 : IESG=0A>=0A=0A=0A____________________________=
___________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.iet=
f.org/mailman/listinfo/oauth
--469468616-1184692804-1391540170=:23334
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


Agreed.
 
 
 
 
 
  On Tuesday, February 4, 2014 8:17 AM,=
 Dick Hardt <dick.hardt@gmail.com> wrote:
  
  
Thi=
s change is appropriate and reflects the intent of the statement.


<=
div class=3D"yiv9767709770yqt4874246893" id=3D"yiv9767709770yqtfd36451">On Tue, Feb 4, 2014 at 8:13 AM, RFC Err=
ata System <rfc-editor@rfc-editor.org> wrote:
=0A=0A
The follow=
ing errata report has been submitted for RFC6749,
=0A"The=
 OAuth 2.0 Authorization Framework".
=0A
=0A--------------------------------------
=0AYou may re=
view the report below and at:
=0Ahttp://www.rfc-editor.org/errata_search.ph=
p?rfc=3D6749&eid=3D3880
=0A
=0A=
--------------------------------------
=0AType: Technical=

=0AReported by: Eriksen Costa <eriksencosta@gmail.com>
=0A
=0ASection: 10.16
=0A=0AOriginal Text
=0A-------------
=0AFor public clients using implicit flows, this specification d=
oes not
=0Aprovide any method for the client to determine=
 what client an access
=0Atoken was issued to.
=0A
=0ACorrected Text
=0A----=
----------
=0AFor public clients using implicit flows, th=
is specification does not
=0Aprovide any method for the a=
uthorization server to determine what
=0Aclient an access=
 token was issued to.
=0A
=0ANotes
=0A-----
=0AA client can only know about to=
kens issued to it and not for other clients.
=0A
=0AInstructions:
=0A-------------
=0AThis errata is currently posted as "Reported". If necessary, please=

=0Ause "Reply All" to discuss whether it should be verif=
ied or
=0Arejected. When a decision is reached, the verif=
ying party (IESG)
=0Acan log in to change the status and =
edit the report, if necessary.
=0A
=0A-=
-------------------------------------
=0ARFC6749 (draft-i=
etf-oauth-v2-31)
=0A-------------------------------------=
-
=0ATitle             &nbs=
p; : The OAuth 2.0 Authorization Framework
=0APublication=
 Date    : October 2012
=0AAuthor(s)   &nb=
sp;       : D. Hardt, Ed.
=0ACategory &nbs=
p;          : PROPOSED STANDARD
=
=0ASource              : Web Authorizati=
on Protocol
=0AArea           &n=
bsp;    : Security
=0AStream     &nbs=
p;        : IETF
=0AVerifying Party &=
nbsp;   : IESG
=0A


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


  
    
--469468616-1184692804-1391540170=:23334--

From phil.hunt@oracle.com  Tue Feb  4 11:05:47 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3326A1A01CD for ; Tue,  4 Feb 2014 11:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Level: 
X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzPhIbJfop13 for ; Tue,  4 Feb 2014 11:05:45 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id EB75C1A01E7 for ; Tue,  4 Feb 2014 11:05:44 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s14J5fsG025781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Feb 2014 19:05:42 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s14J5eHr016824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2014 19:05:41 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s14J5dUP010825; Tue, 4 Feb 2014 19:05:40 GMT
Received: from [192.168.1.124] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Feb 2014 11:05:39 -0800
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Phil Hunt 
In-Reply-To: <576f34cc19fb4926978a5078504f3476@BLUPR03MB309.namprd03.prod.outlook.com>
Date: Tue, 4 Feb 2014 11:05:37 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <64767C7A-41C8-43C0-9387-A52CE4A8CAE0@oracle.com>
References: <52E87DE4.1070000@gmx.net> <576f34cc19fb4926978a5078504f3476@BLUPR03MB309.namprd03.prod.outlook.com>
To: Anthony Nadalin 
X-Mailer: Apple Mail (2.1510)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Feb 2014 19:05:47 -0000

Some discussion below=85

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-02-03, at 9:26 PM, Anthony Nadalin  =
wrote:

> So it's a tiny bit better but not sure it has captured all of what was =
being proposed to fix the original, still not there.
>=20
> 1. The signature on the software statement should be optional=20

Signatures should be REQUIRED.  Unsigned data should be passed in the =
normal registration request.  The point of the statement is to "lock" =
the registration metadata between instances. =20

> 2. The software statement should be an assertion, the assertion can be =
whatever profiles exist, I understand the desire this to be a JWT but =
that is too limiting, for interop purposes this could be  as JWT =
assertion.

Not sure I understand the distinction here. Are you suggesting that a =
SAML assertion should also be acceptable?  I guess it doesn't matter as =
long as the servers are prepared to handle it. =20

This is brand-new functionality, so I'm not sure why other assertions =
are important. Can you give a case where a non-JWT assertion would be =
beneficial?  e.g. are you thinking it might be easier to extend an =
existing MS signed software assertion with dyn reg metadata than create =
new JWT assertions?
> 3. The idea was to be able to remove the client secrets to reduce =
required management for secrets, we need to get away from this

I agree on this. But in IETF Vancouver there was a general disagreement =
around use of client_secrets.  Some of us interpret secrets as being =
passwords only while others are passing assertions as secrets.  I think =
this is where some of the debate/confusion is stemming from.

I would like to:
a.  clarify that secrets are passwords (this is not the way to pass =
assertions even though they may behave like passwords to a client)
b.  the use of passwords should be discouraged

As new functionality (no legacy), I would like to drop support for the =
use of passwords (secrets) for managing client registration profiles.
>=20
>=20
>=20
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes =
Tschofenig
> Sent: Tuesday, January 28, 2014 8:05 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
>=20
> Hi all,
>=20
> as you have seen from the meeting minutes of our recent status chat it =
is time to proceed with the dynamic client registration work.
>=20
> The earlier version of the dynamic client registration document was =
split into three parts, namely
>  (1) the current working group draft containing only minimal =
functionality,
>  (2) a document describing meta-data, and
>  (3) a document containing management functionality.
>=20
> This change was made as outcome of the discussions we had more or less =
over the last 9 months.
>=20
> The latter two documents are individual submissions at this point. New =
content is not available with the recent changes. So, it is one of those =
document management issues.
>=20
> I had a chat with Stephen about WG adoption of the two individual =
submissions as WG items. It was OK for him given that it is a purely =
document management action. However, before we turn the documents into =
WG items we need your feedback on a number of issues:
>=20
> 1) Do you have concerns with the document split? Do you object or =
approve it?
> 2) Is the separation of the functionality into these three documents =
correct? Should the line be drawn differently?
> 3) Do you have comments on the documents overall?
>=20
> We would like to receive high-level feedback within a week. We are =
also eager to hear from implementers and other projects using the =
dynamic client registration work (such as OpenID Connect, UMA, the =
BlueButton/GreenButton Initiative, etc.)
>=20
> For more detailed reviews please wait till we re-do the WGLC (which we =
plan to do soon). We have to restart the WGLC due to discussions last =
years and the resulting changes to these documents.
>=20
> Ciao
> Hannes & Derek
>=20
> PS: Derek and I also think that Phil should become co-auhor of these =
documents for his contributions.
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From ve7jtb@ve7jtb.com  Tue Feb  4 12:23:15 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A4A1A01F8 for ; Tue,  4 Feb 2014 12:23:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6COMCdLFq1g for ; Tue,  4 Feb 2014 12:23:11 -0800 (PST)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 18B7F1A016D for ; Tue,  4 Feb 2014 12:23:10 -0800 (PST)
Received: by mail-qc0-f182.google.com with SMTP id c9so14459712qcz.41 for ; Tue, 04 Feb 2014 12:23:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xpZDx7NlRScLCtsZd7YwfroRZC/JOZyhEsuh4mP9WDY=; b=a/PqdrMwbIcy38udd3/H5INQ/7ZA5HWMqZAseNcgbzC2Yp3YbJp+deQnjSHDYXktic jUxMYrHN72yxgy62BdjHsNK3xYDN+MinvIytj3r3GuKgYwt/cSLdCICU+A3bbLxJzC79 bLnMuxeii5bVSUIBWVY3ZAJmgVTO5Om9p8dp6XHqul04XG4FITJNhMN8Yp9yIVJ3zQxB HihTMzfV6LpYJphiSlthjrhCmpQM/SXg5TwQx4MpmC0GtQiYKjaUfAmXcFV/mp2X+oFz b/MUV0WXebh+rRzmyQVuMqpfVmNZxE+ajWT3xGpv7RzlfmBEZQHIAkrGEYhdkUCnhsSe hB5A==
X-Gm-Message-State: ALoCoQn/92+fjJmmhPM+cIphDFTXKEdGJbz59XyjBM7t/ThO+4t9HT8v19ZaKCXGMUOqxpTP8hgh
X-Received: by 10.224.88.70 with SMTP id z6mr70016212qal.14.1391545390185; Tue, 04 Feb 2014 12:23:10 -0800 (PST)
Received: from [192.168.0.200] ([201.188.196.139]) by mx.google.com with ESMTPSA id u4sm69937105qai.21.2014.02.04.12.23.00 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Feb 2014 12:23:09 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_041658BC-4950-4168-96AF-EBE03433BCF2"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley 
In-Reply-To: <52F1368D.9040106@oracle.com>
Date: Tue, 4 Feb 2014 17:22:48 -0300
Message-Id: <76932D08-5599-4A45-A2F3-50476D865A17@ve7jtb.com>
References: <20140204161338.9A4007FC168@rfc-editor.org> <9B180E22-D31A-48A7-A233-8F3DA05ABF71@ve7jtb.com> <52F1368D.9040106@oracle.com>
To: Prateek Mishra 
X-Mailer: Apple Mail (2.1827)
Cc: eriksencosta@gmail.com, oauth , Derek Atkins , Sean Turner , RFC Errata System 
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Feb 2014 20:23:15 -0000

--Apple-Mail=_041658BC-4950-4168-96AF-EBE03433BCF2
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FE596F1F-6FEB-4945-8DAB-3D847A5260F9"


--Apple-Mail=_FE596F1F-6FEB-4945-8DAB-3D847A5260F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

It is true that a AS cannot tell what instance of a native client it is =
issuing a token to via the redirect URI.

10.16 is only talking about an attack on the client based on a lack of =
audience information.=20

If there is a security consideration around AS differentiating between =
instances of public clients that should be documented separately.
It might be possible using dynamic registration to give each instance of =
a client a separate client_id but I don't think that is manageable if =
the AS needs to maintain state for each client_id.

Depending on the threat we are trying to mitigate using the forthcoming =
Proof of Possession spec to bind tokens to specific client instances may =
be a solution.

I think the issues need to be kept separate.

John B.


On Feb 4, 2014, at 3:50 PM, Prateek Mishra  =
wrote:

> Well, the proposed correction does point to a genuine security hazard
>=20
> Specifically, when client instances share the same re-direct URI, =
typically mobile clients
>=20
> this is independent of whether implicit or code flows are used
>=20
> It is only injective clients - each of whose instances bind to unique =
redirect URLs - that can support discriminative Az servers
>=20
> So I would re-phrase the proposed text as:
>=20
> [quote]
> For public, non-injective clients, this specification does not
> provide any method for the authorization server to determine what
> client an access token was issued to.
> [\quote]
>=20
> - prateek
>=20
>=20
>> The text in 10.16 is correct.
>>=20
>> This is a security consideration that has caused serious problems for =
Facebook and other implementers.
>>=20
>> In the Implicit flow there is no way for a client to know if a access =
token was issued to it or another client.
>>=20
>> The UA presenting the access token in an implicit flow may be the =
resource owner but may also be any other client that has ever received =
an access token for the resource.
>>=20
>> In the implicit flow the Authorization server knows what client it =
has issued a access token to via the registered redirect URI.
>>=20
>> The change doesn't reflect the intent of the security consideration.
>>=20
>> John B.
>>=20
>>=20
>> On Feb 4, 2014, at 1:13 PM, RFC Errata System =
 wrote:
>>=20
>>> The following errata report has been submitted for RFC6749,
>>> "The OAuth 2.0 Authorization Framework".
>>>=20
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D3880
>>>=20
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Eriksen Costa 
>>>=20
>>> Section: 10.16
>>>=20
>>> Original Text
>>> -------------
>>> For public clients using implicit flows, this specification does not
>>> provide any method for the client to determine what client an access
>>> token was issued to.
>>>=20
>>> Corrected Text
>>> --------------
>>> For public clients using implicit flows, this specification does not
>>> provide any method for the authorization server to determine what
>>> client an access token was issued to.
>>>=20
>>> Notes
>>> -----
>>> A client can only know about tokens issued to it and not for other =
clients.
>>>=20
>>> Instructions:
>>> -------------
>>> This errata is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party (IESG)
>>> can log in to change the status and edit the report, if necessary.=20=

>>>=20
>>> --------------------------------------
>>> RFC6749 (draft-ietf-oauth-v2-31)
>>> --------------------------------------
>>> Title               : The OAuth 2.0 Authorization Framework
>>> Publication Date    : October 2012
>>> Author(s)           : D. Hardt, Ed.
>>> Category            : PROPOSED STANDARD
>>> Source              : Web Authorization Protocol
>>> Area                : Security
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>> _______________________________________________
>>> 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


--Apple-Mail=_FE596F1F-6FEB-4945-8DAB-3D847A5260F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

It is =
true that a AS cannot tell what instance of a native client it is =
issuing a token to via the redirect URI.

10.16 =
is only talking about an attack on the client based on a lack of =
audience information. 

If there is a =
security consideration around AS differentiating between instances of =
public clients that should be documented separately.
It might =
be possible using dynamic registration to give each instance of a client =
a separate client_id but I don't think that is manageable if the AS =
needs to maintain state for each =
client_id.

Depending on the threat we are =
trying to mitigate using the forthcoming Proof of Possession spec to =
bind tokens to specific client instances may be a =
solution.

I think the issues need to be kept =
separate.

John =
B.


On Feb 4, 2014, at 3:50 PM, =
Prateek Mishra <prateek.mishra@oracle.com>=
; wrote:


 =20
    
 =20
  

    Well, the proposed correction does point to a genuine security
    hazard

    

    Specifically, when client instances share the same re-direct URI,
    typically mobile clients

    

    this is independent of whether implicit or code flows are used

    

    It is only injective clients - each of whose instances bind to
    unique redirect URLs - that can support discriminative Az =
servers

    

    So I would re-phrase the proposed text as:

    

    [quote]

    
For public, non-injective clients, this specification =
does not
provide any method for the authorization server to determine what
client an access token was issued to.

    [\quote]

    

    - prateek

    

    


    

    

      
The text in 10.16 is correct.

This is a security consideration that has caused serious problems for =
Facebook and other implementers.

In the Implicit flow there is no way for a client to know if a access =
token was issued to it or another client.

The UA presenting the access token in an implicit flow may be the =
resource owner but may also be any other client that has ever received =
an access token for the resource.

In the implicit flow the Authorization server knows what client it has =
issued a access token to via the registered redirect URI.

The change doesn't reflect the intent of the security consideration.

John B.


On Feb 4, 2014, at 1:13 PM, RFC Errata System <rfc-editor@rfc-editor.org>=
; wrote:



      

        
The following errata report has been submitted =
for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D3880=


--------------------------------------
Type: Technical
Reported by: Eriksen Costa <eriksencosta@gmail.com>

Section: 10.16

Original Text
-------------
For public clients using implicit flows, this specification does not
provide any method for the client to determine what client an access
token was issued to.

Corrected Text
--------------
For public clients using implicit flows, this specification does not
provide any method for the authorization server to determine what
client an access token was issued to.

Notes
-----
A client can only know about tokens issued to it and not for other =
clients.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.=20

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework
Publication Date    : October 2012
Author(s)           : D. Hardt, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
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=_FE596F1F-6FEB-4945-8DAB-3D847A5260F9--

--Apple-Mail=_041658BC-4950-4168-96AF-EBE03433BCF2
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA0MjAyMjQ5WjAjBgkqhkiG9w0BCQQxFgQUOONGEwZj
EfiA7g1oztOkPtStpawwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAYPbdcG6nndWNxKgKNJgnqItSWwIdiaEP1vYP+xyG
5lQQdGaeRiwjxMj8EuIJ7toHVAXIdPS+MovlmmRKn32AjOquYE+VYa3b9masyvXc3/K1ECUYhHJt
AZHFSYcyERqle5T8KT1R5VSH1Y7sgGI9Ool35jMdPXm3rxND2H+M1OKAkoDMLr+sKBNt9t3NN1Cd
/hc4ugHEFFm2jc+j2E1bEjrbs0C1wdjQmkFh2NsrsqObr0O0Vsm6TYV/FAtgH89oVNRDfPVIQRFw
n2VFOWBCEfgMHjTRfIKUvESMTRUwZlVtv9HZiLZY/KcVbZuw/xOhUasvFxRZyxsyx1jltRA6RwAA
AAAAAA==

--Apple-Mail=_041658BC-4950-4168-96AF-EBE03433BCF2--

From philip.kershaw@stfc.ac.uk  Wed Feb  5 01:13:48 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4ED1A00B0 for ; Wed,  5 Feb 2014 01:13:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmXdCVcQ17mU for ; Wed,  5 Feb 2014 01:13:46 -0800 (PST)
Received: from engine29-1277-2.icritical.com (engine29-1277-2.icritical.com [212.57.248.116]) by ietfa.amsl.com (Postfix) with ESMTP id BB7701A00A5 for ; Wed,  5 Feb 2014 01:13:45 -0800 (PST)
Received: by iCritical outbound mailer at engine29-1277-2.icritical.com for oauth@ietf.org; Wed, 05 Feb 2014 09:13:44 +0000
Received: from engine29-1277-2.icritical.com ([127.0.0.1]) by localhost (engine29-1277-2.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 30868-03 for ; Wed,  5 Feb 2014 09:13:37 +0000 (GMT)
Received: (qmail 31007 invoked by uid 599); 5 Feb 2014 09:13:37 -0000
Received: from unknown (HELO exchsmtp.stfc.ac.uk) (130.246.236.9) by engine29-1277-2.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 05 Feb 2014 09:13:37 +0000
Received: from EXCHMBX01.fed.cclrc.ac.uk ([169.254.3.132]) by EXCHHUB01.fed.cclrc.ac.uk ([130.246.236.9]) with mapi id 14.02.0318.004; Wed, 5 Feb 2014 09:12:25 +0000
From: 
To: 
Thread-Topic: Suitable grant type for a Javascript use case
Thread-Index: AQHPIlJi6GugnXxeXUGov5NHIis8Cw==
Date: Wed, 5 Feb 2014 09:12:24 +0000
Message-ID: <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk>
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com>
In-Reply-To: <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.246.121.33]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <38E52BC5FB498D4DA936961C56FC758D@fed.cclrc.ac.uk>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Virus-Scanned: by iCritical at engine29-1277-2.icritical.com
Subject: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Feb 2014 09:13:48 -0000

Hi all,

I'm looking to apply OAuth for a particular use case with a Javascript clie=
nt and would like to get some guidance with this.  Bear with me as I'm new =
to this list.

I have a Javascript client which needs to be deployed on a number of differ=
ent sites for which we don't have control over the server-side code.  The c=
lient needs to obtain an access token to submit data to another 3rd party s=
ite on behalf of the user. =20

We've looked at the Implicit Grant type (http://tools.ietf.org/html/rfc6749=
#section-4.2).  Our third party site hosts an Authorisation server and Reso=
urce Server.  The client provides a redirect URI to return the token to.  M=
y understanding is that the redirect URI is a security measure to ensure th=
e token is returned to an endpoint known to the Authorisation Server. =20

However, in my case it is only the Javascript client that needs the token. =
 I can see how the token can be passed to the Javascript via step E in figu=
re 4.  However, we have limited control over the site hosting the Javascrip=
t ('Web-hosted Client Resource' in Figure 4).  We can host Javascript but w=
e can't easily alter any server-side code.  There's a danger that the serve=
r-side code will choke when it receives the redirect the URI containing the=
 access token.  I'm wondering if there is a suitable workaround for this.  =
Can we dispense with the redirect URI or does this compromise security too =
far?  Perhaps we should be looking at an implementing an alternative grant =
type?

Any help much appreciated.

Cheers,
Phil=
-- 
Scanned by iCritical.

From manfred.steyer@gmx.net  Wed Feb  5 03:30:51 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AE91A00B2 for ; Wed,  5 Feb 2014 03:30:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.665
X-Spam-Level: 
X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW2r_tmGVctl for ; Wed,  5 Feb 2014 03:30:49 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0BD1A00E5 for ; Wed,  5 Feb 2014 03:30:49 -0800 (PST)
Received: from IWINB07 ([81.189.215.252]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LfSyv-1VRDXq3A6r-00p1vE for ; Wed, 05 Feb 2014 12:30:48 +0100
From: "Manfred Steyer" 
To: , 
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com> <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk>
In-Reply-To: <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk>
Date: Wed, 5 Feb 2014 12:30:46 +0100
Message-ID: <005701cf2265$b77bd120$26737360$@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGzVxyFCxj6YjFCX6+t5VGUNAs9tAK/fjYnAqSUC8MCnDkvr5qeGNow
Content-Language: de
X-Provags-ID: V03:K0:eEudo7RqNM9qc2Uy2ia4eR+XPUKWbWjYCvWhIpncmUpD51F5wRC ulXupfaHkvxFtI8xRT61l1ZuD//Lvt2PWVJLINwVWVw5SxM7fDrL9X1ksOKxBSy9U2B4/DX zZ4hnubIV76cdYn9b7IWtTNbyit1Ost+vtc6bb+CLpScRV66mywq1fFV0QiAcQR9kawaMgL KOzWWogwPjr7hRIeeYsCg==
Subject: Re: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Feb 2014 11:30:52 -0000

Hi Phil,

the server won't see the access-code, cause it is returned within the =
hash
that stays at the client-site:=20
	http://.../returnUri#access_code=3DABCDE.=20

By definition, the returnURI has to be the URI that was registered for =
the
client. IMHO, you are only allowed to add additional URL-Parameters.

In my opinion, your use-case suits _very_ well to the implicit flow.

Wishes,
Manfred





-----Urspr=FCngliche Nachricht-----
Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von
philip.kershaw@stfc.ac.uk
Gesendet: Mittwoch, 5. Februar 2014 10:12
An: oauth@ietf.org
Betreff: [OAUTH-WG] Suitable grant type for a Javascript use case

Hi all,

I'm looking to apply OAuth for a particular use case with a Javascript
client and would like to get some guidance with this.  Bear with me as =
I'm
new to this list.

I have a Javascript client which needs to be deployed on a number of
different sites for which we don't have control over the server-side =
code.
The client needs to obtain an access token to submit data to another 3rd
party site on behalf of the user. =20

We've looked at the Implicit Grant type
(http://tools.ietf.org/html/rfc6749#section-4.2).  Our third party site
hosts an Authorisation server and Resource Server.  The client provides =
a
redirect URI to return the token to.  My understanding is that the =
redirect
URI is a security measure to ensure the token is returned to an endpoint
known to the Authorisation Server. =20

However, in my case it is only the Javascript client that needs the =
token.
I can see how the token can be passed to the Javascript via step E in =
figure
4.  However, we have limited control over the site hosting the =
Javascript
('Web-hosted Client Resource' in Figure 4).  We can host Javascript but =
we
can't easily alter any server-side code.  There's a danger that the
server-side code will choke when it receives the redirect the URI =
containing
the access token.  I'm wondering if there is a suitable workaround for =
this.
Can we dispense with the redirect URI or does this compromise security =
too
far?  Perhaps we should be looking at an implementing an alternative =
grant
type?

Any help much appreciated.

Cheers,
Phil--=20
Scanned by iCritical.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


From philip.kershaw@stfc.ac.uk  Wed Feb  5 03:49:30 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBB11A00E8 for ; Wed,  5 Feb 2014 03:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1jeZMkSLg6F for ; Wed,  5 Feb 2014 03:49:28 -0800 (PST)
Received: from engine29-1277-4.icritical.com (engine29-1277-4.icritical.com [212.57.248.93]) by ietfa.amsl.com (Postfix) with ESMTP id A785E1A00B2 for ; Wed,  5 Feb 2014 03:49:27 -0800 (PST)
Received: by iCritical outbound mailer at engine29-1277-4.icritical.com for oauth@ietf.org; Wed, 05 Feb 2014 11:49:25 +0000
Received: from engine29-1277-4.icritical.com ([127.0.0.1]) by localhost (engine29-1277-4.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 07711-02 for ; Wed,  5 Feb 2014 11:49:23 +0000 (GMT)
Received: (qmail 7749 invoked by uid 599); 5 Feb 2014 11:49:13 -0000
Received: from unknown (HELO exchsmtp.stfc.ac.uk) (130.246.236.11) by engine29-1277-4.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 05 Feb 2014 11:49:13 +0000
Received: from EXCHMBX01.fed.cclrc.ac.uk ([169.254.3.132]) by EXCHHUB03.fed.cclrc.ac.uk ([130.246.236.11]) with mapi id 14.02.0318.004; Wed, 5 Feb 2014 11:49:05 +0000
From: 
To: 
Thread-Topic: [OAUTH-WG] Suitable grant type for a Javascript use case
Thread-Index: AQHPIlJi6GugnXxeXUGov5NHIis8C5qmhscAgAAFHQA=
Date: Wed, 5 Feb 2014 11:49:04 +0000
Message-ID: <836226893590734FA88B31162359477F594D4B3C@EXCHMBX01.fed.cclrc.ac.uk>
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com> <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk> <005701cf2265$b77bd120$26737360$@gmx.net>
In-Reply-To: <005701cf2265$b77bd120$26737360$@gmx.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.246.121.33]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1FD5F1F35FCD8A4B874AF776BB07455F@fed.cclrc.ac.uk>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Virus-Scanned: by iCritical at engine29-1277-4.icritical.com
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Feb 2014 11:49:30 -0000

Hi Manfred,

On 5 Feb 2014, at 11:30, Manfred Steyer wrote:

> Hi Phil,
>=20
> the server won't see the access-code, cause it is returned within the has=
h
> that stays at the client-site:=20
> 	http://.../returnUri#access_code=3DABCDE.=20
>=20

That's excellent.  I hadn't picked that up in the text.  I think it would b=
e really helpful to have an explicit note in 4.2.2 to highlight this point.

Thanks,
Phil

> By definition, the returnURI has to be the URI that was registered for th=
e
> client. IMHO, you are only allowed to add additional URL-Parameters.
>=20
> In my opinion, your use-case suits _very_ well to the implicit flow.
>=20
> Wishes,
> Manfred
>=20
>=20
>=20
>=20
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von
> philip.kershaw@stfc.ac.uk
> Gesendet: Mittwoch, 5. Februar 2014 10:12
> An: oauth@ietf.org
> Betreff: [OAUTH-WG] Suitable grant type for a Javascript use case
>=20
> Hi all,
>=20
> I'm looking to apply OAuth for a particular use case with a Javascript
> client and would like to get some guidance with this.  Bear with me as I'=
m
> new to this list.
>=20
> I have a Javascript client which needs to be deployed on a number of
> different sites for which we don't have control over the server-side code=
.
> The client needs to obtain an access token to submit data to another 3rd
> party site on behalf of the user. =20
>=20
> We've looked at the Implicit Grant type
> (http://tools.ietf.org/html/rfc6749#section-4.2).  Our third party site
> hosts an Authorisation server and Resource Server.  The client provides a
> redirect URI to return the token to.  My understanding is that the redire=
ct
> URI is a security measure to ensure the token is returned to an endpoint
> known to the Authorisation Server. =20
>=20
> However, in my case it is only the Javascript client that needs the token=
.
> I can see how the token can be passed to the Javascript via step E in fig=
ure
> 4.  However, we have limited control over the site hosting the Javascript
> ('Web-hosted Client Resource' in Figure 4).  We can host Javascript but w=
e
> can't easily alter any server-side code.  There's a danger that the
> server-side code will choke when it receives the redirect the URI contain=
ing
> the access token.  I'm wondering if there is a suitable workaround for th=
is.
> Can we dispense with the redirect URI or does this compromise security to=
o
> far?  Perhaps we should be looking at an implementing an alternative gran=
t
> type?
>=20
> Any help much appreciated.
>=20
> Cheers,
> Phil--=20
> Scanned by iCritical.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20

-- 
Scanned by iCritical.

From prateek.mishra@oracle.com  Wed Feb  5 10:33:20 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5729D1A017D for ; Wed,  5 Feb 2014 10:33:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Level: 
X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRIypSr7k5jl for ; Wed,  5 Feb 2014 10:33:18 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E9E731A01BB for ; Wed,  5 Feb 2014 10:33:15 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s15IXBNX023706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Feb 2014 18:33:12 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s15IXA1S007225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Feb 2014 18:33:10 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s15IX9JB025589; Wed, 5 Feb 2014 18:33:10 GMT
Received: from [130.35.50.173] (/130.35.50.173) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 Feb 2014 10:33:09 -0800
Message-ID: <52F283E4.50507@oracle.com>
Date: Wed, 05 Feb 2014 10:33:08 -0800
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: oauth@ietf.org, philip.kershaw@stfc.ac.uk
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com> <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk> <005701cf2265$b77bd120$26737360$@gmx.net>
In-Reply-To: <005701cf2265$b77bd120$26737360$@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: Re: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Feb 2014 18:33:20 -0000

Well, this means you are completely dependent on a security model that 
is based on a very specific property of HTTP
redirects. The User agent MUST NOT forward any component of a fragment 
URI in a redirect - you are depending on the user having
a conformant and uptodate user agent.

I would say that the authorization code grant has more robust security 
properties. From my perspective depending
on this type of subtle and complex requirement on other layers of the 
protocol stack is a considerable risk.

So you should factor that in your analysis of the security properties of 
your client.

- prateek
> Hi Phil,
>
> the server won't see the access-code, cause it is returned within the hash
> that stays at the client-site:
> 	http://.../returnUri#access_code=ABCDE.
>
> By definition, the returnURI has to be the URI that was registered for the
> client. IMHO, you are only allowed to add additional URL-Parameters.
>
> In my opinion, your use-case suits _very_ well to the implicit flow.
>
> Wishes,
> Manfred
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von
> philip.kershaw@stfc.ac.uk
> Gesendet: Mittwoch, 5. Februar 2014 10:12
> An: oauth@ietf.org
> Betreff: [OAUTH-WG] Suitable grant type for a Javascript use case
>
> Hi all,
>
> I'm looking to apply OAuth for a particular use case with a Javascript
> client and would like to get some guidance with this.  Bear with me as I'm
> new to this list.
>
> I have a Javascript client which needs to be deployed on a number of
> different sites for which we don't have control over the server-side code.
> The client needs to obtain an access token to submit data to another 3rd
> party site on behalf of the user.
>
> We've looked at the Implicit Grant type
> (http://tools.ietf.org/html/rfc6749#section-4.2).  Our third party site
> hosts an Authorisation server and Resource Server.  The client provides a
> redirect URI to return the token to.  My understanding is that the redirect
> URI is a security measure to ensure the token is returned to an endpoint
> known to the Authorisation Server.
>
> However, in my case it is only the Javascript client that needs the token.
> I can see how the token can be passed to the Javascript via step E in figure
> 4.  However, we have limited control over the site hosting the Javascript
> ('Web-hosted Client Resource' in Figure 4).  We can host Javascript but we
> can't easily alter any server-side code.  There's a danger that the
> server-side code will choke when it receives the redirect the URI containing
> the access token.  I'm wondering if there is a suitable workaround for this.
> Can we dispense with the redirect URI or does this compromise security too
> far?  Perhaps we should be looking at an implementing an alternative grant
> type?
>
> Any help much appreciated.
>
> Cheers,
> Phil--
> Scanned by iCritical.
> _______________________________________________
> 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  Wed Feb  5 11:29:36 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFCC1A0138 for ; Wed,  5 Feb 2014 11:29:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.735
X-Spam-Level: 
X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEjgvnpbNTZC for ; Wed,  5 Feb 2014 11:29:30 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BA8F51A00EB for ; Wed,  5 Feb 2014 11:29:29 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E85531F04DE; Wed,  5 Feb 2014 14:29:28 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CFF672260053; Wed,  5 Feb 2014 14:29:28 -0500 (EST)
Received: from bvb-172-31-60-57.mitre.org (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 5 Feb 2014 14:29:28 -0500
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Justin Richer 
In-Reply-To: <52F283E4.50507@oracle.com>
Date: Wed, 5 Feb 2014 14:29:24 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <6BF381DC-791A-4220-9C95-F0ED0718190B@mitre.org>
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com> <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk> <005701cf2265$b77bd120$26737360$@gmx.net> <52F283E4.50507@oracle.com>
To: Prateek Mishra 
X-Mailer: Apple Mail (2.1827)
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Feb 2014 19:29:36 -0000

While you should always factor in an analysis of the security properties =
of your client, you should also realize that by hosting the client =
completely inside the browser, most of the benefits of the code flow go =
away. You're no longer able to separate the knowledge of different parts =
of the protocol, and so much of what you're protecting with the auth =
code doesn't actually apply anymore.=20

Also, if the user is using a user agent that is not conformant or up to =
date, there's no need to sniff OAuth because it can just steal the =
primary credentials from the auth server connection directly -- so the =
counter argument is a bit of a red herring. Yes, it's a requirement for =
this to work properly, but it's a requirement for many other things to =
work properly also.=20

 -- Justin

On Feb 5, 2014, at 1:33 PM, Prateek Mishra  =
wrote:

> Well, this means you are completely dependent on a security model that =
is based on a very specific property of HTTP
> redirects. The User agent MUST NOT forward any component of a fragment =
URI in a redirect - you are depending on the user having
> a conformant and uptodate user agent.
>=20
> I would say that the authorization code grant has more robust security =
properties. =46rom my perspective depending
> on this type of subtle and complex requirement on other layers of the =
protocol stack is a considerable risk.
>=20
> So you should factor that in your analysis of the security properties =
of your client.
>=20
> - prateek
>> Hi Phil,
>>=20
>> the server won't see the access-code, cause it is returned within the =
hash
>> that stays at the client-site:
>> 	http://.../returnUri#access_code=3DABCDE.
>>=20
>> By definition, the returnURI has to be the URI that was registered =
for the
>> client. IMHO, you are only allowed to add additional URL-Parameters.
>>=20
>> In my opinion, your use-case suits _very_ well to the implicit flow.
>>=20
>> Wishes,
>> Manfred
>>=20
>>=20
>>=20
>>=20
>>=20
>> -----Urspr=FCngliche Nachricht-----
>> Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von
>> philip.kershaw@stfc.ac.uk
>> Gesendet: Mittwoch, 5. Februar 2014 10:12
>> An: oauth@ietf.org
>> Betreff: [OAUTH-WG] Suitable grant type for a Javascript use case
>>=20
>> Hi all,
>>=20
>> I'm looking to apply OAuth for a particular use case with a =
Javascript
>> client and would like to get some guidance with this.  Bear with me =
as I'm
>> new to this list.
>>=20
>> I have a Javascript client which needs to be deployed on a number of
>> different sites for which we don't have control over the server-side =
code.
>> The client needs to obtain an access token to submit data to another =
3rd
>> party site on behalf of the user.
>>=20
>> We've looked at the Implicit Grant type
>> (http://tools.ietf.org/html/rfc6749#section-4.2).  Our third party =
site
>> hosts an Authorisation server and Resource Server.  The client =
provides a
>> redirect URI to return the token to.  My understanding is that the =
redirect
>> URI is a security measure to ensure the token is returned to an =
endpoint
>> known to the Authorisation Server.
>>=20
>> However, in my case it is only the Javascript client that needs the =
token.
>> I can see how the token can be passed to the Javascript via step E in =
figure
>> 4.  However, we have limited control over the site hosting the =
Javascript
>> ('Web-hosted Client Resource' in Figure 4).  We can host Javascript =
but we
>> can't easily alter any server-side code.  There's a danger that the
>> server-side code will choke when it receives the redirect the URI =
containing
>> the access token.  I'm wondering if there is a suitable workaround =
for this.
>> Can we dispense with the redirect URI or does this compromise =
security too
>> far?  Perhaps we should be looking at an implementing an alternative =
grant
>> type?
>>=20
>> Any help much appreciated.
>>=20
>> Cheers,
>> Phil--
>> Scanned by iCritical.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From prateek.mishra@oracle.com  Wed Feb  5 11:40:49 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5B11A0192 for ; Wed,  5 Feb 2014 11:40:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Level: 
X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4e_nb3biPvR for ; Wed,  5 Feb 2014 11:40:47 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2E01A0138 for ; Wed,  5 Feb 2014 11:40:47 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s15JejRE007234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Feb 2014 19:40:46 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s15JeiaU024982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Feb 2014 19:40:44 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s15Jeh0v024688; Wed, 5 Feb 2014 19:40:43 GMT
Received: from [130.35.50.173] (/130.35.50.173) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 Feb 2014 11:40:43 -0800
Message-ID: <52F293AF.50108@oracle.com>
Date: Wed, 05 Feb 2014 11:40:31 -0800
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Justin Richer 
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com> <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk> <005701cf2265$b77bd120$26737360$@gmx.net> <52F283E4.50507@oracle.com> <6BF381DC-791A-4220-9C95-F0ED0718190B@mitre.org>
In-Reply-To: <6BF381DC-791A-4220-9C95-F0ED0718190B@mitre.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Feb 2014 19:40:49 -0000

Well, there is a fundamental difference between the security properties 
of implicit vs. code flow: in the former access tokens are passed via 
URLs (protected only by the fragment URI requirement), whereas in the
latter this is never the case. So I do see a foundational difference in 
security properties between the two. The core issue the type of artifact 
exposed in network flows in both the models.

Another way to put it would be: the authorization code flow is a 
re-purposing of the well known SAML SSO Web Artifact profile which has a 
long history of deployment and use. The implicit flow "simplifies" that 
but there
are definitely some consequences from a security point of view.

I can see that certain low-value clients (or even better, clients for 
whom the client issuing entity assumes no liability :-) can reasonably 
utilize the implicit flow. But it would be good if its weaknesses were 
kept in mind.

- prateek
> While you should always factor in an analysis of the security properties of your client, you should also realize that by hosting the client completely inside the browser, most of the benefits of the code flow go away. You're no longer able to separate the knowledge of different parts of the protocol, and so much of what you're protecting with the auth code doesn't actually apply anymore.
>
> Also, if the user is using a user agent that is not conformant or up to date, there's no need to sniff OAuth because it can just steal the primary credentials from the auth server connection directly -- so the counter argument is a bit of a red herring. Yes, it's a requirement for this to work properly, but it's a requirement for many other things to work properly also.
>
>   -- Justin
>
> On Feb 5, 2014, at 1:33 PM, Prateek Mishra  wrote:
>
>> Well, this means you are completely dependent on a security model that is based on a very specific property of HTTP
>> redirects. The User agent MUST NOT forward any component of a fragment URI in a redirect - you are depending on the user having
>> a conformant and uptodate user agent.
>>
>> I would say that the authorization code grant has more robust security properties. From my perspective depending
>> on this type of subtle and complex requirement on other layers of the protocol stack is a considerable risk.
>>
>> So you should factor that in your analysis of the security properties of your client.
>>
>> - prateek
>>> Hi Phil,
>>>
>>> the server won't see the access-code, cause it is returned within the hash
>>> that stays at the client-site:
>>> 	http://.../returnUri#access_code=ABCDE.
>>>
>>> By definition, the returnURI has to be the URI that was registered for the
>>> client. IMHO, you are only allowed to add additional URL-Parameters.
>>>
>>> In my opinion, your use-case suits _very_ well to the implicit flow.
>>>
>>> Wishes,
>>> Manfred
>>>
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von
>>> philip.kershaw@stfc.ac.uk
>>> Gesendet: Mittwoch, 5. Februar 2014 10:12
>>> An: oauth@ietf.org
>>> Betreff: [OAUTH-WG] Suitable grant type for a Javascript use case
>>>
>>> Hi all,
>>>
>>> I'm looking to apply OAuth for a particular use case with a Javascript
>>> client and would like to get some guidance with this.  Bear with me as I'm
>>> new to this list.
>>>
>>> I have a Javascript client which needs to be deployed on a number of
>>> different sites for which we don't have control over the server-side code.
>>> The client needs to obtain an access token to submit data to another 3rd
>>> party site on behalf of the user.
>>>
>>> We've looked at the Implicit Grant type
>>> (http://tools.ietf.org/html/rfc6749#section-4.2).  Our third party site
>>> hosts an Authorisation server and Resource Server.  The client provides a
>>> redirect URI to return the token to.  My understanding is that the redirect
>>> URI is a security measure to ensure the token is returned to an endpoint
>>> known to the Authorisation Server.
>>>
>>> However, in my case it is only the Javascript client that needs the token.
>>> I can see how the token can be passed to the Javascript via step E in figure
>>> 4.  However, we have limited control over the site hosting the Javascript
>>> ('Web-hosted Client Resource' in Figure 4).  We can host Javascript but we
>>> can't easily alter any server-side code.  There's a danger that the
>>> server-side code will choke when it receives the redirect the URI containing
>>> the access token.  I'm wondering if there is a suitable workaround for this.
>>> Can we dispense with the redirect URI or does this compromise security too
>>> far?  Perhaps we should be looking at an implementing an alternative grant
>>> type?
>>>
>>> Any help much appreciated.
>>>
>>> Cheers,
>>> Phil--
>>> Scanned by iCritical.
>>> _______________________________________________
>>> 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 ve7jtb@ve7jtb.com  Wed Feb  5 12:33:56 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8EB1A0209 for ; Wed,  5 Feb 2014 12:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uX1sOErLKIGp for ; Wed,  5 Feb 2014 12:33:53 -0800 (PST)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1531A0201 for ; Wed,  5 Feb 2014 12:33:53 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id f11so1369933qae.38 for ; Wed, 05 Feb 2014 12:33:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ANPGcxxaHpUIsGR+TVwfMhaOcQLEpNgpr/cKlT1cO+A=; b=idKFbQNTaEALbpJELK1UKeSkAuQWDPsa6mQCmkKrbpYOAMjMO/lp73+4bcwXiAHoOL wFgMuqCcrz8t25F3lTulMTUITlKizvhywtzjt5wVSzH4tvqBEjJIsn6Oa9URvrJ7t7uB JKTi/FME97S9W+jEfkOil63hFP/f2sPXZcWBT4kFPCf2FNSeWiX4V9RPn3axBXdrIiUN DcOsrN2GqqgL0f488dyPU78AddxmKf7peauF67MfKnF7p1LvrV/oQg+D2QrwSZ7Uok5I c1bxFSPQY0kyUlT+tKdAnK+rbDhWaASdEzrETk4MFTVIFCE2xGr8vDuT3Xag6c9qUjzD Fz4A==
X-Gm-Message-State: ALoCoQlZTUZrqWfKqhjFsX1haMfyJ01wZPZhpuCnLOBKVL7bzX1pPNB7XKKHtjt9E2SuHF8vNYRw
X-Received: by 10.140.30.66 with SMTP id c60mr5796148qgc.13.1391632432162; Wed, 05 Feb 2014 12:33:52 -0800 (PST)
Received: from [192.168.0.200] ([201.188.15.242]) by mx.google.com with ESMTPSA id w7sm80149284qaj.23.2014.02.05.12.33.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 12:33:50 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_79236E23-8CED-478A-A254-16BF725F99D1"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley 
In-Reply-To: <52F293AF.50108@oracle.com>
Date: Wed, 5 Feb 2014 17:33:14 -0300
Message-Id: <18332002-43F0-4FE3-9587-F1B63CDD7EC3@ve7jtb.com>
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com> <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk> <005701cf2265$b77bd120$26737360$@gmx.net> <52F283E4.50507@oracle.com> <6BF381DC-791A-4220-9C95-F0ED0718190B@mitre.org> <52F293AF.50108@oracle.com>
To: Prateek Mishra 
X-Mailer: Apple Mail (2.1827)
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Feb 2014 20:33:57 -0000

--Apple-Mail=_79236E23-8CED-478A-A254-16BF725F99D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

The implicit flow is intended to get a access code to JS clients in the =
browser.   It is true that you could use the code flow, but only if the =
AS token endpoint allowed CORES requests.

Given that the client is in the UA and has a direct TLS connection to =
the Authorization endpoint, from the clients point of view the call to =
the authorization endpoint and the call to the token endpoint are =
equally secure.  =20

Given that Java Script in the browser typically can't protect a client =
secret, the two flows are about equal in security for the AS.

It is true that people use implicit for things that they probably =
shouldn't, but to get a token to Java Script in the UA implicit is =
probably the best way to do it without jumping through extra hoops that =
don't add anything.

At some point we need to do a PostMessage binding for Implicit as an =
option passing the token in the fragment,  many implementations do that =
today for JS clients but it is not interoperable without a profile.

John B.


On Feb 5, 2014, at 4:40 PM, Prateek Mishra  =
wrote:

> Well, there is a fundamental difference between the security =
properties of implicit vs. code flow: in the former access tokens are =
passed via URLs (protected only by the fragment URI requirement), =
whereas in the
> latter this is never the case. So I do see a foundational difference =
in security properties between the two. The core issue the type of =
artifact exposed in network flows in both the models.
>=20
> Another way to put it would be: the authorization code flow is a =
re-purposing of the well known SAML SSO Web Artifact profile which has a =
long history of deployment and use. The implicit flow "simplifies" that =
but there
> are definitely some consequences from a security point of view.
>=20
> I can see that certain low-value clients (or even better, clients for =
whom the client issuing entity assumes no liability :-) can reasonably =
utilize the implicit flow. But it would be good if its weaknesses were =
kept in mind.
>=20
> - prateek
>> While you should always factor in an analysis of the security =
properties of your client, you should also realize that by hosting the =
client completely inside the browser, most of the benefits of the code =
flow go away. You're no longer able to separate the knowledge of =
different parts of the protocol, and so much of what you're protecting =
with the auth code doesn't actually apply anymore.
>>=20
>> Also, if the user is using a user agent that is not conformant or up =
to date, there's no need to sniff OAuth because it can just steal the =
primary credentials from the auth server connection directly -- so the =
counter argument is a bit of a red herring. Yes, it's a requirement for =
this to work properly, but it's a requirement for many other things to =
work properly also.
>>=20
>>  -- Justin
>>=20
>> On Feb 5, 2014, at 1:33 PM, Prateek Mishra =
 wrote:
>>=20
>>> Well, this means you are completely dependent on a security model =
that is based on a very specific property of HTTP
>>> redirects. The User agent MUST NOT forward any component of a =
fragment URI in a redirect - you are depending on the user having
>>> a conformant and uptodate user agent.
>>>=20
>>> I would say that the authorization code grant has more robust =
security properties. =46rom my perspective depending
>>> on this type of subtle and complex requirement on other layers of =
the protocol stack is a considerable risk.
>>>=20
>>> So you should factor that in your analysis of the security =
properties of your client.
>>>=20
>>> - prateek
>>>> Hi Phil,
>>>>=20
>>>> the server won't see the access-code, cause it is returned within =
the hash
>>>> that stays at the client-site:
>>>> 	http://.../returnUri#access_code=3DABCDE.
>>>>=20
>>>> By definition, the returnURI has to be the URI that was registered =
for the
>>>> client. IMHO, you are only allowed to add additional =
URL-Parameters.
>>>>=20
>>>> In my opinion, your use-case suits _very_ well to the implicit =
flow.
>>>>=20
>>>> Wishes,
>>>> Manfred
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> -----Urspr=FCngliche Nachricht-----
>>>> Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von
>>>> philip.kershaw@stfc.ac.uk
>>>> Gesendet: Mittwoch, 5. Februar 2014 10:12
>>>> An: oauth@ietf.org
>>>> Betreff: [OAUTH-WG] Suitable grant type for a Javascript use case
>>>>=20
>>>> Hi all,
>>>>=20
>>>> I'm looking to apply OAuth for a particular use case with a =
Javascript
>>>> client and would like to get some guidance with this.  Bear with me =
as I'm
>>>> new to this list.
>>>>=20
>>>> I have a Javascript client which needs to be deployed on a number =
of
>>>> different sites for which we don't have control over the =
server-side code.
>>>> The client needs to obtain an access token to submit data to =
another 3rd
>>>> party site on behalf of the user.
>>>>=20
>>>> We've looked at the Implicit Grant type
>>>> (http://tools.ietf.org/html/rfc6749#section-4.2).  Our third party =
site
>>>> hosts an Authorisation server and Resource Server.  The client =
provides a
>>>> redirect URI to return the token to.  My understanding is that the =
redirect
>>>> URI is a security measure to ensure the token is returned to an =
endpoint
>>>> known to the Authorisation Server.
>>>>=20
>>>> However, in my case it is only the Javascript client that needs the =
token.
>>>> I can see how the token can be passed to the Javascript via step E =
in figure
>>>> 4.  However, we have limited control over the site hosting the =
Javascript
>>>> ('Web-hosted Client Resource' in Figure 4).  We can host Javascript =
but we
>>>> can't easily alter any server-side code.  There's a danger that the
>>>> server-side code will choke when it receives the redirect the URI =
containing
>>>> the access token.  I'm wondering if there is a suitable workaround =
for this.
>>>> Can we dispense with the redirect URI or does this compromise =
security too
>>>> far?  Perhaps we should be looking at an implementing an =
alternative grant
>>>> type?
>>>>=20
>>>> Any help much appreciated.
>>>>=20
>>>> Cheers,
>>>> Phil--
>>>> Scanned by iCritical.
>>>> _______________________________________________
>>>> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_79236E23-8CED-478A-A254-16BF725F99D1
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA1MjAzMzE1WjAjBgkqhkiG9w0BCQQxFgQUA+TrGYdU
gw5gVUJJKfGtD3iRH/0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAebyT+5xpfO6z3T8DLkluPjYCknTHpPSXTPxE4DOz
LYkukNPcP3fvAjKuLYPGlUR+aValy+uXYLleCQO/jTohThG5pjt05UNx1kcW9KjsavkLp8gyTV5v
VUQxS2sMC8nHLsxGigBAshB6os4v4r8iDuKMOQDf9TNs44xoel8x7sTC3eX0CSmTiLAreSxp6lIn
BEdBjjWDHhy4ZEMSl/vvjVtGm40yzgscKfPStqzatV9KZy0V99PFmG9sdc+A0Uj36g5AeeROcgrk
eAo3XjVGB0O2ID/RTL6gwYkzyBCOP0RXt/3LATCorO/Ru0s3x1kO141xYCxBzabIssXvTU/jcQAA
AAAAAA==

--Apple-Mail=_79236E23-8CED-478A-A254-16BF725F99D1--

From philip.kershaw@stfc.ac.uk  Wed Feb  5 13:22:47 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267BD1A022E for ; Wed,  5 Feb 2014 13:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjp-PmItDmcP for ; Wed,  5 Feb 2014 13:22:44 -0800 (PST)
Received: from engine29-1277-4.icritical.com (engine29-1277-4.icritical.com [212.57.248.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA471A0224 for ; Wed,  5 Feb 2014 13:22:43 -0800 (PST)
Received: by iCritical outbound mailer at engine29-1277-4.icritical.com for oauth@ietf.org; Wed, 05 Feb 2014 21:22:42 +0000
Received: from engine29-1277-4.icritical.com ([127.0.0.1]) by localhost (engine29-1277-4.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 14411-04 for ; Wed,  5 Feb 2014 21:22:42 +0000 (GMT)
Received: (qmail 14776 invoked by uid 599); 5 Feb 2014 21:22:35 -0000
Received: from unknown (HELO exchsmtp.stfc.ac.uk) (130.246.236.11) by engine29-1277-4.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 05 Feb 2014 21:22:35 +0000
Received: from EXCHMBX01.fed.cclrc.ac.uk ([169.254.3.132]) by EXCHHUB03.fed.cclrc.ac.uk ([130.246.236.11]) with mapi id 14.02.0318.004; Wed, 5 Feb 2014 21:22:33 +0000
From: 
To: 
Thread-Topic: [OAUTH-WG] Suitable grant type for a Javascript use case
Thread-Index: AQHPIlJi6GugnXxeXUGov5NHIis8C5qmhscAgAB2AgCAAA+5AIAAAxuAgAAOugCAAA3FgA==
Date: Wed, 5 Feb 2014 21:22:32 +0000
Message-ID: <836226893590734FA88B31162359477F594D721F@EXCHMBX01.fed.cclrc.ac.uk>
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com> <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk> <005701cf2265$b77bd120$26737360$@gmx.net> <52F283E4.50507@oracle.com> <6BF381DC-791A-4220-9C95-F0ED0718190B@mitre.org> <52F293AF.50108@oracle.com> <18332002-43F0-4FE3-9587-F1B63CDD7EC3@ve7jtb.com>
In-Reply-To: <18332002-43F0-4FE3-9587-F1B63CDD7EC3@ve7jtb.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.246.135.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <136482214E4D05448C85105784CD7C3A@fed.cclrc.ac.uk>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Virus-Scanned: by iCritical at engine29-1277-4.icritical.com
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Feb 2014 21:22:47 -0000

Thanks all - some interesting points raised.

I've used the Authorisation Code grant for a couple of other use cases on o=
ther projects.  The Implicit Grant is less desirable but it fits here for m=
e because of the particular constraints of the client and its hosting envir=
onment.  The level of security required is low.

I'd be interested in finding out about the examples that use a PostMessage =
approach that you mention John.

Phil

On 5 Feb 2014, at 20:33, John Bradley wrote:

> The implicit flow is intended to get a access code to JS clients in the b=
rowser.   It is true that you could use the code flow, but only if the AS t=
oken endpoint allowed CORES requests.
>=20
> Given that the client is in the UA and has a direct TLS connection to the=
 Authorization endpoint, from the clients point of view the call to the aut=
horization endpoint and the call to the token endpoint are equally secure. =
 =20
>=20
> Given that Java Script in the browser typically can't protect a client se=
cret, the two flows are about equal in security for the AS.
>=20
> It is true that people use implicit for things that they probably shouldn=
't, but to get a token to Java Script in the UA implicit is probably the be=
st way to do it without jumping through extra hoops that don't add anything=
.
>=20
> At some point we need to do a PostMessage binding for Implicit as an opti=
on passing the token in the fragment,  many implementations do that today f=
or JS clients but it is not interoperable without a profile.
>=20
> John B.
>=20
>=20
> On Feb 5, 2014, at 4:40 PM, Prateek Mishra  wr=
ote:
>=20
>> Well, there is a fundamental difference between the security properties =
of implicit vs. code flow: in the former access tokens are passed via URLs =
(protected only by the fragment URI requirement), whereas in the
>> latter this is never the case. So I do see a foundational difference in =
security properties between the two. The core issue the type of artifact ex=
posed in network flows in both the models.
>>=20
>> Another way to put it would be: the authorization code flow is a re-purp=
osing of the well known SAML SSO Web Artifact profile which has a long hist=
ory of deployment and use. The implicit flow "simplifies" that but there
>> are definitely some consequences from a security point of view.
>>=20
>> I can see that certain low-value clients (or even better, clients for wh=
om the client issuing entity assumes no liability :-) can reasonably utiliz=
e the implicit flow. But it would be good if its weaknesses were kept in mi=
nd.
>>=20
>> - prateek
>>> While you should always factor in an analysis of the security propertie=
s of your client, you should also realize that by hosting the client comple=
tely inside the browser, most of the benefits of the code flow go away. You=
're no longer able to separate the knowledge of different parts of the prot=
ocol, and so much of what you're protecting with the auth code doesn't actu=
ally apply anymore.
>>>=20
>>> Also, if the user is using a user agent that is not conformant or up to=
 date, there's no need to sniff OAuth because it can just steal the primary=
 credentials from the auth server connection directly -- so the counter arg=
ument is a bit of a red herring. Yes, it's a requirement for this to work p=
roperly, but it's a requirement for many other things to work properly also=
.
>>>=20
>>> -- Justin
>>>=20
>>> On Feb 5, 2014, at 1:33 PM, Prateek Mishra  =
wrote:
>>>=20
>>>> Well, this means you are completely dependent on a security model that=
 is based on a very specific property of HTTP
>>>> redirects. The User agent MUST NOT forward any component of a fragment=
 URI in a redirect - you are depending on the user having
>>>> a conformant and uptodate user agent.
>>>>=20
>>>> I would say that the authorization code grant has more robust security=
 properties. From my perspective depending
>>>> on this type of subtle and complex requirement on other layers of the =
protocol stack is a considerable risk.
>>>>=20
>>>> So you should factor that in your analysis of the security properties =
of your client.
>>>>=20
>>>> - prateek
>>>>> Hi Phil,
>>>>>=20
>>>>> the server won't see the access-code, cause it is returned within the=
 hash
>>>>> that stays at the client-site:
>>>>> 	http://.../returnUri#access_code=3DABCDE.
>>>>>=20
>>>>> By definition, the returnURI has to be the URI that was registered fo=
r the
>>>>> client. IMHO, you are only allowed to add additional URL-Parameters.
>>>>>=20
>>>>> In my opinion, your use-case suits _very_ well to the implicit flow.
>>>>>=20
>>>>> Wishes,
>>>>> Manfred
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> -----Urspr=FCngliche Nachricht-----
>>>>> Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von
>>>>> philip.kershaw@stfc.ac.uk
>>>>> Gesendet: Mittwoch, 5. Februar 2014 10:12
>>>>> An: oauth@ietf.org
>>>>> Betreff: [OAUTH-WG] Suitable grant type for a Javascript use case
>>>>>=20
>>>>> Hi all,
>>>>>=20
>>>>> I'm looking to apply OAuth for a particular use case with a Javascrip=
t
>>>>> client and would like to get some guidance with this.  Bear with me a=
s I'm
>>>>> new to this list.
>>>>>=20
>>>>> I have a Javascript client which needs to be deployed on a number of
>>>>> different sites for which we don't have control over the server-side =
code.
>>>>> The client needs to obtain an access token to submit data to another =
3rd
>>>>> party site on behalf of the user.
>>>>>=20
>>>>> We've looked at the Implicit Grant type
>>>>> (http://tools.ietf.org/html/rfc6749#section-4.2).  Our third party si=
te
>>>>> hosts an Authorisation server and Resource Server.  The client provid=
es a
>>>>> redirect URI to return the token to.  My understanding is that the re=
direct
>>>>> URI is a security measure to ensure the token is returned to an endpo=
int
>>>>> known to the Authorisation Server.
>>>>>=20
>>>>> However, in my case it is only the Javascript client that needs the t=
oken.
>>>>> I can see how the token can be passed to the Javascript via step E in=
 figure
>>>>> 4.  However, we have limited control over the site hosting the Javasc=
ript
>>>>> ('Web-hosted Client Resource' in Figure 4).  We can host Javascript b=
ut we
>>>>> can't easily alter any server-side code.  There's a danger that the
>>>>> server-side code will choke when it receives the redirect the URI con=
taining
>>>>> the access token.  I'm wondering if there is a suitable workaround fo=
r this.
>>>>> Can we dispense with the redirect URI or does this compromise securit=
y too
>>>>> far?  Perhaps we should be looking at an implementing an alternative =
grant
>>>>> type?
>>>>>=20
>>>>> Any help much appreciated.
>>>>>=20
>>>>> Cheers,
>>>>> Phil--
>>>>> Scanned by iCritical.
>>>>> _______________________________________________
>>>>> 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
>> _______________________________________________
>> 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

-- 
Scanned by iCritical.

From ve7jtb@ve7jtb.com  Wed Feb  5 13:49:41 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FE11A0228 for ; Wed,  5 Feb 2014 13:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np6X-c2Cl-Q4 for ; Wed,  5 Feb 2014 13:49:36 -0800 (PST)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id D79A01A0225 for ; Wed,  5 Feb 2014 13:49:35 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id x13so1698431qcv.5 for ; Wed, 05 Feb 2014 13:49:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xyHxNxPzFApqdJqgsR4fHsd9ssKl7vWYU4u7EQLR0cg=; b=PDgZksV5WR8STpDqGJ/x3IqguhjXZGLecyYWZUbaO8B+cW1ejTi1Es7Lk34csOGbYq ZIVuVodD5mWSu9JXUapSCMp1NsMOyr9Yg7fUecqnPKLS77TpQVWz12DievhxP8wGSKxE 2/CVFH1P0+xQZIp51k/g7f+FdqzeQjmhMn5ZujPVF9ldlBK1R/KQR3eB/vmOWrbs6CM4 Sfo899j5Ye6UwIpVtdREHyPyYAaynV52Z6p23s12LSVD4i6AikCdjFjHsbrOE2hxwjLn YgbbLglMIjfO0tYZh9jsK/dQBzzqc60BIJhnfzTGQOYc1pWlxCMYC1VwI+A5xNXiYyiv Ve9Q==
X-Gm-Message-State: ALoCoQm+dJIu9wZDcKKfkYuq/x6SfdvkoScUl5QPLR5MfhMIvjej9+N4YVF4NR0fTxNnHLdgisB/
X-Received: by 10.140.83.112 with SMTP id i103mr6388064qgd.100.1391636974513;  Wed, 05 Feb 2014 13:49:34 -0800 (PST)
Received: from [192.168.0.200] ([201.188.15.242]) by mx.google.com with ESMTPSA id j97sm38944447qge.22.2014.02.05.13.49.30 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 13:49:33 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_8C309BB9-AAA1-45E1-A0FD-45605D695C44"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley 
In-Reply-To: <836226893590734FA88B31162359477F594D721F@EXCHMBX01.fed.cclrc.ac.uk>
Date: Wed, 5 Feb 2014 18:49:09 -0300
Message-Id: 
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com> <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk> <005701cf2265$b77bd120$26737360$@gmx.net> <52F283E4.50507@oracle.com> <6BF381DC-791A-4220-9C95-F0ED0718190B@mitre.org> <52F293AF.50108@oracle.com> <18332002-43F0-4FE3-9587-F1B63CDD7EC3@ve7jtb.com> <836226893590734FA88B31162359477F594D721F@EXCHMBX01.fed.cclrc.ac.uk>
To: philip.kershaw@stfc.ac.uk
X-Mailer: Apple Mail (2.1827)
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Feb 2014 21:49:41 -0000

--Apple-Mail=_8C309BB9-AAA1-45E1-A0FD-45605D695C44
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

You can use PostMessage if you control both the client and AS.

Google uses it in there identity toolkit if you use there g+ Java Script =
client. =
http://www.riskcompletefailure.com/2013/03/postmessage-oauth-20.html

There is some example code at =
https://code.google.com/p/oauth2-postmessage-profile

In OpenID Connect the same technique is used for session management. =
http://openid.net/specs/openid-connect-session-1_0-18.html

You can do it but it would be custom to your AS.

John B.


On Feb 5, 2014, at 6:22 PM,  =
 wrote:

> Thanks all - some interesting points raised.
>=20
> I've used the Authorisation Code grant for a couple of other use cases =
on other projects.  The Implicit Grant is less desirable but it fits =
here for me because of the particular constraints of the client and its =
hosting environment.  The level of security required is low.
>=20
> I'd be interested in finding out about the examples that use a =
PostMessage approach that you mention John.
>=20
> Phil
>=20
> On 5 Feb 2014, at 20:33, John Bradley wrote:
>=20
>> The implicit flow is intended to get a access code to JS clients in =
the browser.   It is true that you could use the code flow, but only if =
the AS token endpoint allowed CORES requests.
>>=20
>> Given that the client is in the UA and has a direct TLS connection to =
the Authorization endpoint, from the clients point of view the call to =
the authorization endpoint and the call to the token endpoint are =
equally secure.  =20
>>=20
>> Given that Java Script in the browser typically can't protect a =
client secret, the two flows are about equal in security for the AS.
>>=20
>> It is true that people use implicit for things that they probably =
shouldn't, but to get a token to Java Script in the UA implicit is =
probably the best way to do it without jumping through extra hoops that =
don't add anything.
>>=20
>> At some point we need to do a PostMessage binding for Implicit as an =
option passing the token in the fragment,  many implementations do that =
today for JS clients but it is not interoperable without a profile.
>>=20
>> John B.
>>=20
>>=20
>> On Feb 5, 2014, at 4:40 PM, Prateek Mishra =
 wrote:
>>=20
>>> Well, there is a fundamental difference between the security =
properties of implicit vs. code flow: in the former access tokens are =
passed via URLs (protected only by the fragment URI requirement), =
whereas in the
>>> latter this is never the case. So I do see a foundational difference =
in security properties between the two. The core issue the type of =
artifact exposed in network flows in both the models.
>>>=20
>>> Another way to put it would be: the authorization code flow is a =
re-purposing of the well known SAML SSO Web Artifact profile which has a =
long history of deployment and use. The implicit flow "simplifies" that =
but there
>>> are definitely some consequences from a security point of view.
>>>=20
>>> I can see that certain low-value clients (or even better, clients =
for whom the client issuing entity assumes no liability :-) can =
reasonably utilize the implicit flow. But it would be good if its =
weaknesses were kept in mind.
>>>=20
>>> - prateek
>>>> While you should always factor in an analysis of the security =
properties of your client, you should also realize that by hosting the =
client completely inside the browser, most of the benefits of the code =
flow go away. You're no longer able to separate the knowledge of =
different parts of the protocol, and so much of what you're protecting =
with the auth code doesn't actually apply anymore.
>>>>=20
>>>> Also, if the user is using a user agent that is not conformant or =
up to date, there's no need to sniff OAuth because it can just steal the =
primary credentials from the auth server connection directly -- so the =
counter argument is a bit of a red herring. Yes, it's a requirement for =
this to work properly, but it's a requirement for many other things to =
work properly also.
>>>>=20
>>>> -- Justin
>>>>=20
>>>> On Feb 5, 2014, at 1:33 PM, Prateek Mishra =
 wrote:
>>>>=20
>>>>> Well, this means you are completely dependent on a security model =
that is based on a very specific property of HTTP
>>>>> redirects. The User agent MUST NOT forward any component of a =
fragment URI in a redirect - you are depending on the user having
>>>>> a conformant and uptodate user agent.
>>>>>=20
>>>>> I would say that the authorization code grant has more robust =
security properties. =46rom my perspective depending
>>>>> on this type of subtle and complex requirement on other layers of =
the protocol stack is a considerable risk.
>>>>>=20
>>>>> So you should factor that in your analysis of the security =
properties of your client.
>>>>>=20
>>>>> - prateek
>>>>>> Hi Phil,
>>>>>>=20
>>>>>> the server won't see the access-code, cause it is returned within =
the hash
>>>>>> that stays at the client-site:
>>>>>> 	http://.../returnUri#access_code=3DABCDE.
>>>>>>=20
>>>>>> By definition, the returnURI has to be the URI that was =
registered for the
>>>>>> client. IMHO, you are only allowed to add additional =
URL-Parameters.
>>>>>>=20
>>>>>> In my opinion, your use-case suits _very_ well to the implicit =
flow.
>>>>>>=20
>>>>>> Wishes,
>>>>>> Manfred
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> -----Urspr=FCngliche Nachricht-----
>>>>>> Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von
>>>>>> philip.kershaw@stfc.ac.uk
>>>>>> Gesendet: Mittwoch, 5. Februar 2014 10:12
>>>>>> An: oauth@ietf.org
>>>>>> Betreff: [OAUTH-WG] Suitable grant type for a Javascript use case
>>>>>>=20
>>>>>> Hi all,
>>>>>>=20
>>>>>> I'm looking to apply OAuth for a particular use case with a =
Javascript
>>>>>> client and would like to get some guidance with this.  Bear with =
me as I'm
>>>>>> new to this list.
>>>>>>=20
>>>>>> I have a Javascript client which needs to be deployed on a number =
of
>>>>>> different sites for which we don't have control over the =
server-side code.
>>>>>> The client needs to obtain an access token to submit data to =
another 3rd
>>>>>> party site on behalf of the user.
>>>>>>=20
>>>>>> We've looked at the Implicit Grant type
>>>>>> (http://tools.ietf.org/html/rfc6749#section-4.2).  Our third =
party site
>>>>>> hosts an Authorisation server and Resource Server.  The client =
provides a
>>>>>> redirect URI to return the token to.  My understanding is that =
the redirect
>>>>>> URI is a security measure to ensure the token is returned to an =
endpoint
>>>>>> known to the Authorisation Server.
>>>>>>=20
>>>>>> However, in my case it is only the Javascript client that needs =
the token.
>>>>>> I can see how the token can be passed to the Javascript via step =
E in figure
>>>>>> 4.  However, we have limited control over the site hosting the =
Javascript
>>>>>> ('Web-hosted Client Resource' in Figure 4).  We can host =
Javascript but we
>>>>>> can't easily alter any server-side code.  There's a danger that =
the
>>>>>> server-side code will choke when it receives the redirect the URI =
containing
>>>>>> the access token.  I'm wondering if there is a suitable =
workaround for this.
>>>>>> Can we dispense with the redirect URI or does this compromise =
security too
>>>>>> far?  Perhaps we should be looking at an implementing an =
alternative grant
>>>>>> type?
>>>>>>=20
>>>>>> Any help much appreciated.
>>>>>>=20
>>>>>> Cheers,
>>>>>> Phil--
>>>>>> Scanned by iCritical.
>>>>>> _______________________________________________
>>>>>> 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
>>> _______________________________________________
>>> 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
> --
> Scanned by iCritical.


--Apple-Mail=_8C309BB9-AAA1-45E1-A0FD-45605D695C44
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA1MjE0OTA5WjAjBgkqhkiG9w0BCQQxFgQU1sXO0Fsv
CjcUdgvmvSJihBq+ELEwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAKVope0EZ2Qba0eecwthVwMG/vE0Okj7arFrqLD9L
+tXSCA//MPtTF1pdd/5eWpBp4uIBoWnTI3wfQhZYjzKTzznVQ+FJdnAqd+zqA7x9JiJCfwO6budz
5sHw9U/Gg+kzyllLZDBXmHSQlK6rcJl39Ne0Ugxkj9dl4sDxXChE2T/ItLogCMGFg8+4U9/vWjTY
RFNSb5V1dCHAVZR61+Ze5hxxQLFTnkv1dp1J+ZypTNsAIWHdozvTeWFF0061foc9umerWcBywLk7
kx+cEyuff4ZHaNGZU4NPkMkUCLfqFmLjateB3isQX+gHEP8okjMlSWM202DIxZ5xjpjU30XfWwAA
AAAAAA==

--Apple-Mail=_8C309BB9-AAA1-45E1-A0FD-45605D695C44--

From philip.kershaw@stfc.ac.uk  Wed Feb  5 14:01:20 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B311A012F for ; Wed,  5 Feb 2014 14:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiPBD7viTqef for ; Wed,  5 Feb 2014 14:01:18 -0800 (PST)
Received: from engine19-1277-3.icritical.com (engine19-1277-3.icritical.com [93.95.13.95]) by ietfa.amsl.com (Postfix) with ESMTP id A215B1A0129 for ; Wed,  5 Feb 2014 14:01:17 -0800 (PST)
Received: by iCritical outbound mailer at engine19-1277-3.icritical.com for oauth@ietf.org; Wed, 05 Feb 2014 22:01:36 +0000
Received: from engine19-1277-3.icritical.com ([127.0.0.1]) by localhost (engine19-1277-3.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 08040-07 for ; Wed,  5 Feb 2014 22:01:28 +0000 (GMT)
Received: (qmail 9378 invoked by uid 599); 5 Feb 2014 22:01:28 -0000
Received: from unknown (HELO exchsmtp.stfc.ac.uk) (130.246.236.9) by engine19-1277-3.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 05 Feb 2014 22:01:28 +0000
Received: from EXCHMBX01.fed.cclrc.ac.uk ([169.254.3.132]) by EXCHHUB01.fed.cclrc.ac.uk ([130.246.236.9]) with mapi id 14.02.0318.004; Wed, 5 Feb 2014 22:01:07 +0000
From: 
To: 
Thread-Topic: [OAUTH-WG] Suitable grant type for a Javascript use case
Thread-Index: AQHPIlJi6GugnXxeXUGov5NHIis8C5qmhscAgAB2AgCAAA+5AIAAAxuAgAAOugCAAA3FgIAAB3GAgAADVwA=
Date: Wed, 5 Feb 2014 22:01:06 +0000
Message-ID: <836226893590734FA88B31162359477F594D7956@EXCHMBX01.fed.cclrc.ac.uk>
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com> <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk> <005701cf2265$b77bd120$26737360$@gmx.net> <52F283E4.50507@oracle.com> <6BF381DC-791A-4220-9C95-F0ED0718190B@mitre.org> <52F293AF.50108@oracle.com> <18332002-43F0-4FE3-9587-F1B63CDD7EC3@ve7jtb.com> <836226893590734FA88B31162359477F594D721F@EXCHMBX01.fed.cclrc.ac.uk> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.246.242.142]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <19DC689276DD5344B6887DB2C67E7489@fed.cclrc.ac.uk>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Virus-Scanned: by iCritical at engine19-1277-3.icritical.com
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Feb 2014 22:01:20 -0000

This looks along the same lines as the solution my colleague here has propo=
sed but I was unsure of the security implications and unaware of any existi=
ng implementations.

I agree that a standardised profile for this would be helpful.

Thanks,
Phil
On 5 Feb 2014, at 21:49, John Bradley wrote:

> You can use PostMessage if you control both the client and AS.
>=20
> Google uses it in there identity toolkit if you use there g+ Java Script =
client. http://www.riskcompletefailure.com/2013/03/postmessage-oauth-20.htm=
l
>=20
> There is some example code at https://code.google.com/p/oauth2-postmessag=
e-profile
>=20
> In OpenID Connect the same technique is used for session management. http=
://openid.net/specs/openid-connect-session-1_0-18.html
>=20
> You can do it but it would be custom to your AS.
>=20
> John B.
>=20
>=20
> On Feb 5, 2014, at 6:22 PM,   wrote:
>=20
>> Thanks all - some interesting points raised.
>>=20
>> I've used the Authorisation Code grant for a couple of other use cases o=
n other projects.  The Implicit Grant is less desirable but it fits here fo=
r me because of the particular constraints of the client and its hosting en=
vironment.  The level of security required is low.
>>=20
>> I'd be interested in finding out about the examples that use a PostMessa=
ge approach that you mention John.
>>=20
>> Phil
>>=20
>> On 5 Feb 2014, at 20:33, John Bradley wrote:
>>=20
>>> The implicit flow is intended to get a access code to JS clients in the=
 browser.   It is true that you could use the code flow, but only if the AS=
 token endpoint allowed CORES requests.
>>>=20
>>> Given that the client is in the UA and has a direct TLS connection to t=
he Authorization endpoint, from the clients point of view the call to the a=
uthorization endpoint and the call to the token endpoint are equally secure=
.  =20
>>>=20
>>> Given that Java Script in the browser typically can't protect a client =
secret, the two flows are about equal in security for the AS.
>>>=20
>>> It is true that people use implicit for things that they probably shoul=
dn't, but to get a token to Java Script in the UA implicit is probably the =
best way to do it without jumping through extra hoops that don't add anythi=
ng.
>>>=20
>>> At some point we need to do a PostMessage binding for Implicit as an op=
tion passing the token in the fragment,  many implementations do that today=
 for JS clients but it is not interoperable without a profile.
>>>=20
>>> John B.
>>>=20
>>>=20
>>> On Feb 5, 2014, at 4:40 PM, Prateek Mishra  =
wrote:
>>>=20
>>>> Well, there is a fundamental difference between the security propertie=
s of implicit vs. code flow: in the former access tokens are passed via URL=
s (protected only by the fragment URI requirement), whereas in the
>>>> latter this is never the case. So I do see a foundational difference i=
n security properties between the two. The core issue the type of artifact =
exposed in network flows in both the models.
>>>>=20
>>>> Another way to put it would be: the authorization code flow is a re-pu=
rposing of the well known SAML SSO Web Artifact profile which has a long hi=
story of deployment and use. The implicit flow "simplifies" that but there
>>>> are definitely some consequences from a security point of view.
>>>>=20
>>>> I can see that certain low-value clients (or even better, clients for =
whom the client issuing entity assumes no liability :-) can reasonably util=
ize the implicit flow. But it would be good if its weaknesses were kept in =
mind.
>>>>=20
>>>> - prateek
>>>>> While you should always factor in an analysis of the security propert=
ies of your client, you should also realize that by hosting the client comp=
letely inside the browser, most of the benefits of the code flow go away. Y=
ou're no longer able to separate the knowledge of different parts of the pr=
otocol, and so much of what you're protecting with the auth code doesn't ac=
tually apply anymore.
>>>>>=20
>>>>> Also, if the user is using a user agent that is not conformant or up =
to date, there's no need to sniff OAuth because it can just steal the prima=
ry credentials from the auth server connection directly -- so the counter a=
rgument is a bit of a red herring. Yes, it's a requirement for this to work=
 properly, but it's a requirement for many other things to work properly al=
so.
>>>>>=20
>>>>> -- Justin
>>>>>=20
>>>>> On Feb 5, 2014, at 1:33 PM, Prateek Mishra  wrote:
>>>>>=20
>>>>>> Well, this means you are completely dependent on a security model th=
at is based on a very specific property of HTTP
>>>>>> redirects. The User agent MUST NOT forward any component of a fragme=
nt URI in a redirect - you are depending on the user having
>>>>>> a conformant and uptodate user agent.
>>>>>>=20
>>>>>> I would say that the authorization code grant has more robust securi=
ty properties. From my perspective depending
>>>>>> on this type of subtle and complex requirement on other layers of th=
e protocol stack is a considerable risk.
>>>>>>=20
>>>>>> So you should factor that in your analysis of the security propertie=
s of your client.
>>>>>>=20
>>>>>> - prateek
>>>>>>> Hi Phil,
>>>>>>>=20
>>>>>>> the server won't see the access-code, cause it is returned within t=
he hash
>>>>>>> that stays at the client-site:
>>>>>>> 	http://.../returnUri#access_code=3DABCDE.
>>>>>>>=20
>>>>>>> By definition, the returnURI has to be the URI that was registered =
for the
>>>>>>> client. IMHO, you are only allowed to add additional URL-Parameters=
.
>>>>>>>=20
>>>>>>> In my opinion, your use-case suits _very_ well to the implicit flow=
.
>>>>>>>=20
>>>>>>> Wishes,
>>>>>>> Manfred
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> -----Urspr=FCngliche Nachricht-----
>>>>>>> Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von
>>>>>>> philip.kershaw@stfc.ac.uk
>>>>>>> Gesendet: Mittwoch, 5. Februar 2014 10:12
>>>>>>> An: oauth@ietf.org
>>>>>>> Betreff: [OAUTH-WG] Suitable grant type for a Javascript use case
>>>>>>>=20
>>>>>>> Hi all,
>>>>>>>=20
>>>>>>> I'm looking to apply OAuth for a particular use case with a Javascr=
ipt
>>>>>>> client and would like to get some guidance with this.  Bear with me=
 as I'm
>>>>>>> new to this list.
>>>>>>>=20
>>>>>>> I have a Javascript client which needs to be deployed on a number o=
f
>>>>>>> different sites for which we don't have control over the server-sid=
e code.
>>>>>>> The client needs to obtain an access token to submit data to anothe=
r 3rd
>>>>>>> party site on behalf of the user.
>>>>>>>=20
>>>>>>> We've looked at the Implicit Grant type
>>>>>>> (http://tools.ietf.org/html/rfc6749#section-4.2).  Our third party =
site
>>>>>>> hosts an Authorisation server and Resource Server.  The client prov=
ides a
>>>>>>> redirect URI to return the token to.  My understanding is that the =
redirect
>>>>>>> URI is a security measure to ensure the token is returned to an end=
point
>>>>>>> known to the Authorisation Server.
>>>>>>>=20
>>>>>>> However, in my case it is only the Javascript client that needs the=
 token.
>>>>>>> I can see how the token can be passed to the Javascript via step E =
in figure
>>>>>>> 4.  However, we have limited control over the site hosting the Java=
script
>>>>>>> ('Web-hosted Client Resource' in Figure 4).  We can host Javascript=
 but we
>>>>>>> can't easily alter any server-side code.  There's a danger that the
>>>>>>> server-side code will choke when it receives the redirect the URI c=
ontaining
>>>>>>> the access token.  I'm wondering if there is a suitable workaround =
for this.
>>>>>>> Can we dispense with the redirect URI or does this compromise secur=
ity too
>>>>>>> far?  Perhaps we should be looking at an implementing an alternativ=
e grant
>>>>>>> type?
>>>>>>>=20
>>>>>>> Any help much appreciated.
>>>>>>>=20
>>>>>>> Cheers,
>>>>>>> Phil--
>>>>>>> Scanned by iCritical.
>>>>>>> _______________________________________________
>>>>>>> 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
>>>> _______________________________________________
>>>> 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
>> --
>> Scanned by iCritical.
>=20

-- 
Scanned by iCritical.

From ve7jtb@ve7jtb.com  Wed Feb  5 14:20:56 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FD71A0209 for ; Wed,  5 Feb 2014 14:20:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcG2sbC3f6Kf for ; Wed,  5 Feb 2014 14:20:51 -0800 (PST)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA5B1A012F for ; Wed,  5 Feb 2014 14:20:51 -0800 (PST)
Received: by mail-qc0-f169.google.com with SMTP id w7so1795893qcr.28 for ; Wed, 05 Feb 2014 14:20:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=TmOJr/0cXO+jdP40RO32IyStBGcS9oYDIumkUJ+NA4M=; b=MDS/cDszpdwwnySKoogqOgnppOCGOK6izp5zhJxwlKl2KsKYLYYk4d6NCQQufd1Hhy 648ILwSMTF9f88rrZThRTuuR+vzenpt23FMbHJgqkSlOfAywzFPml2uUgzevcIHBmKJw PE4Mj5fBH+sE1THn3P4UXbXawNqO8F8RUef0A6vjZZOM1MWPi1OMhgtlZ3+T0Wp+khsp oMVx6E0EYsorm6ULFvqifJ8NVpAFzrWQTpynFZDpkQKn5Re8KuSTENzVy1z8R9AbhQxC whxvA71pAYgnjZpP3vO1BUpL1HOAErP4v6mBOdWjrfaCzYpV1nu5qraAXbCf4xT8cn1b 9CUA==
X-Gm-Message-State: ALoCoQkzPXCOsIa1CAg2xXRFOK/SgJ58VugH/iIHi1Koz2xuDGHjK9QYMMkEVxfssual0mJVwKsL
X-Received: by 10.224.127.202 with SMTP id h10mr7013571qas.23.1391638850485; Wed, 05 Feb 2014 14:20:50 -0800 (PST)
Received: from [192.168.0.200] ([201.188.15.242]) by mx.google.com with ESMTPSA id 3sm28939613qan.15.2014.02.05.14.20.46 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 14:20:48 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_4891C85B-C0AD-4433-A044-BA2CAE01B8B4"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley 
In-Reply-To: <836226893590734FA88B31162359477F594D7956@EXCHMBX01.fed.cclrc.ac.uk>
Date: Wed, 5 Feb 2014 19:20:26 -0300
Message-Id: <8C059113-7C75-42FC-BFAB-C75B48798190@ve7jtb.com>
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com> <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk> <005701cf2265$b77bd120$26737360$@gmx.net> <52F283E4.50507@oracle.com> <6BF381DC-791A-4220-9C95-F0ED0718190B@mitre.org> <52F293AF.50108@oracle.com> <18332002-43F0-4FE3-9587-F1B63CDD7EC3@ve7jtb.com> <836226893590734FA88B31162359477F594D721F@EXCHMBX01.fed.cclrc.ac.uk>  <836226893590734FA88B31162359477F594D7956@EXCHMBX01.fed.cclrc.ac.uk>
To: philip.kershaw@stfc.ac.uk
X-Mailer: Apple Mail (2.1827)
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Feb 2014 22:20:57 -0000

--Apple-Mail=_4891C85B-C0AD-4433-A044-BA2CAE01B8B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

The security for PostMessage and fragment encoded is similar as long as =
you pre register the JS origin of the client and use TLS. =20

Some have argued that PostMessage with a registered JS origin is a more =
secure way of doing CORES than using fragment encoding in a redirect.

With fragment encoding there is the possibility that if the AS allows =
wildcarding in redirect URI than an attacker may be able to find an open =
redirector and by inserting !# in the body of the redirect URI be able =
to turn off fragment processing in the browser.

Facebook has been attacked using this technique a number of times to =
extract access tokens for user accounts.=20
=
http://isciurus.blogspot.com/2012/09/pwning-facebook-authorization-through=
.html

Prateek will likely point out that the code flow with a confidential =
client is more secure from open redirector attacks, making the code flow =
better for most cases.

However for public clients it is generally worse as any open redirect =
will receive the code without needing to trick the browser into turning =
off fragment processing.
The attacker can then exchange the code for an access token at the token =
endpoint and it is in.

Selecting the most secure option depends on a number of factors.

John B.


On Feb 5, 2014, at 7:01 PM,  =
 wrote:

> This looks along the same lines as the solution my colleague here has =
proposed but I was unsure of the security implications and unaware of =
any existing implementations.
>=20
> I agree that a standardised profile for this would be helpful.
>=20
> Thanks,
> Phil
> On 5 Feb 2014, at 21:49, John Bradley wrote:
>=20
>> You can use PostMessage if you control both the client and AS.
>>=20
>> Google uses it in there identity toolkit if you use there g+ Java =
Script client. =
http://www.riskcompletefailure.com/2013/03/postmessage-oauth-20.html
>>=20
>> There is some example code at =
https://code.google.com/p/oauth2-postmessage-profile
>>=20
>> In OpenID Connect the same technique is used for session management. =
http://openid.net/specs/openid-connect-session-1_0-18.html
>>=20
>> You can do it but it would be custom to your AS.
>>=20
>> John B.
>>=20
>>=20
>> On Feb 5, 2014, at 6:22 PM,  =
 wrote:
>>=20
>>> Thanks all - some interesting points raised.
>>>=20
>>> I've used the Authorisation Code grant for a couple of other use =
cases on other projects.  The Implicit Grant is less desirable but it =
fits here for me because of the particular constraints of the client and =
its hosting environment.  The level of security required is low.
>>>=20
>>> I'd be interested in finding out about the examples that use a =
PostMessage approach that you mention John.
>>>=20
>>> Phil
>>>=20
>>> On 5 Feb 2014, at 20:33, John Bradley wrote:
>>>=20
>>>> The implicit flow is intended to get a access code to JS clients in =
the browser.   It is true that you could use the code flow, but only if =
the AS token endpoint allowed CORES requests.
>>>>=20
>>>> Given that the client is in the UA and has a direct TLS connection =
to the Authorization endpoint, from the clients point of view the call =
to the authorization endpoint and the call to the token endpoint are =
equally secure.  =20
>>>>=20
>>>> Given that Java Script in the browser typically can't protect a =
client secret, the two flows are about equal in security for the AS.
>>>>=20
>>>> It is true that people use implicit for things that they probably =
shouldn't, but to get a token to Java Script in the UA implicit is =
probably the best way to do it without jumping through extra hoops that =
don't add anything.
>>>>=20
>>>> At some point we need to do a PostMessage binding for Implicit as =
an option passing the token in the fragment,  many implementations do =
that today for JS clients but it is not interoperable without a profile.
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>> On Feb 5, 2014, at 4:40 PM, Prateek Mishra =
 wrote:
>>>>=20
>>>>> Well, there is a fundamental difference between the security =
properties of implicit vs. code flow: in the former access tokens are =
passed via URLs (protected only by the fragment URI requirement), =
whereas in the
>>>>> latter this is never the case. So I do see a foundational =
difference in security properties between the two. The core issue the =
type of artifact exposed in network flows in both the models.
>>>>>=20
>>>>> Another way to put it would be: the authorization code flow is a =
re-purposing of the well known SAML SSO Web Artifact profile which has a =
long history of deployment and use. The implicit flow "simplifies" that =
but there
>>>>> are definitely some consequences from a security point of view.
>>>>>=20
>>>>> I can see that certain low-value clients (or even better, clients =
for whom the client issuing entity assumes no liability :-) can =
reasonably utilize the implicit flow. But it would be good if its =
weaknesses were kept in mind.
>>>>>=20
>>>>> - prateek
>>>>>> While you should always factor in an analysis of the security =
properties of your client, you should also realize that by hosting the =
client completely inside the browser, most of the benefits of the code =
flow go away. You're no longer able to separate the knowledge of =
different parts of the protocol, and so much of what you're protecting =
with the auth code doesn't actually apply anymore.
>>>>>>=20
>>>>>> Also, if the user is using a user agent that is not conformant or =
up to date, there's no need to sniff OAuth because it can just steal the =
primary credentials from the auth server connection directly -- so the =
counter argument is a bit of a red herring. Yes, it's a requirement for =
this to work properly, but it's a requirement for many other things to =
work properly also.
>>>>>>=20
>>>>>> -- Justin
>>>>>>=20
>>>>>> On Feb 5, 2014, at 1:33 PM, Prateek Mishra =
 wrote:
>>>>>>=20
>>>>>>> Well, this means you are completely dependent on a security =
model that is based on a very specific property of HTTP
>>>>>>> redirects. The User agent MUST NOT forward any component of a =
fragment URI in a redirect - you are depending on the user having
>>>>>>> a conformant and uptodate user agent.
>>>>>>>=20
>>>>>>> I would say that the authorization code grant has more robust =
security properties. =46rom my perspective depending
>>>>>>> on this type of subtle and complex requirement on other layers =
of the protocol stack is a considerable risk.
>>>>>>>=20
>>>>>>> So you should factor that in your analysis of the security =
properties of your client.
>>>>>>>=20
>>>>>>> - prateek
>>>>>>>> Hi Phil,
>>>>>>>>=20
>>>>>>>> the server won't see the access-code, cause it is returned =
within the hash
>>>>>>>> that stays at the client-site:
>>>>>>>> 	http://.../returnUri#access_code=3DABCDE.
>>>>>>>>=20
>>>>>>>> By definition, the returnURI has to be the URI that was =
registered for the
>>>>>>>> client. IMHO, you are only allowed to add additional =
URL-Parameters.
>>>>>>>>=20
>>>>>>>> In my opinion, your use-case suits _very_ well to the implicit =
flow.
>>>>>>>>=20
>>>>>>>> Wishes,
>>>>>>>> Manfred
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> -----Urspr=FCngliche Nachricht-----
>>>>>>>> Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von
>>>>>>>> philip.kershaw@stfc.ac.uk
>>>>>>>> Gesendet: Mittwoch, 5. Februar 2014 10:12
>>>>>>>> An: oauth@ietf.org
>>>>>>>> Betreff: [OAUTH-WG] Suitable grant type for a Javascript use =
case
>>>>>>>>=20
>>>>>>>> Hi all,
>>>>>>>>=20
>>>>>>>> I'm looking to apply OAuth for a particular use case with a =
Javascript
>>>>>>>> client and would like to get some guidance with this.  Bear =
with me as I'm
>>>>>>>> new to this list.
>>>>>>>>=20
>>>>>>>> I have a Javascript client which needs to be deployed on a =
number of
>>>>>>>> different sites for which we don't have control over the =
server-side code.
>>>>>>>> The client needs to obtain an access token to submit data to =
another 3rd
>>>>>>>> party site on behalf of the user.
>>>>>>>>=20
>>>>>>>> We've looked at the Implicit Grant type
>>>>>>>> (http://tools.ietf.org/html/rfc6749#section-4.2).  Our third =
party site
>>>>>>>> hosts an Authorisation server and Resource Server.  The client =
provides a
>>>>>>>> redirect URI to return the token to.  My understanding is that =
the redirect
>>>>>>>> URI is a security measure to ensure the token is returned to an =
endpoint
>>>>>>>> known to the Authorisation Server.
>>>>>>>>=20
>>>>>>>> However, in my case it is only the Javascript client that needs =
the token.
>>>>>>>> I can see how the token can be passed to the Javascript via =
step E in figure
>>>>>>>> 4.  However, we have limited control over the site hosting the =
Javascript
>>>>>>>> ('Web-hosted Client Resource' in Figure 4).  We can host =
Javascript but we
>>>>>>>> can't easily alter any server-side code.  There's a danger that =
the
>>>>>>>> server-side code will choke when it receives the redirect the =
URI containing
>>>>>>>> the access token.  I'm wondering if there is a suitable =
workaround for this.
>>>>>>>> Can we dispense with the redirect URI or does this compromise =
security too
>>>>>>>> far?  Perhaps we should be looking at an implementing an =
alternative grant
>>>>>>>> type?
>>>>>>>>=20
>>>>>>>> Any help much appreciated.
>>>>>>>>=20
>>>>>>>> Cheers,
>>>>>>>> Phil--
>>>>>>>> Scanned by iCritical.
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>> _______________________________________________
>>>>> 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
>>> --
>>> Scanned by iCritical.
>>=20
>=20
> --
> Scanned by iCritical.


--Apple-Mail=_4891C85B-C0AD-4433-A044-BA2CAE01B8B4
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA1MjIyMDI3WjAjBgkqhkiG9w0BCQQxFgQUW1wfudpQ
UNDQrs10q9kzzGpyqEYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAdzLqwJEJJi/T7FxfAdkxG6QyOJQd/4F0+DAs2HCE
C2No23KcpCJJkm00xWcZYE8hs5ZYuhZ5aobSMWy9JIPeTU64LY0ZfV4l19v3RGONxRQmXpBBa7Ik
CE+ql3UUaw8UmswIJ2N36ukRqce46RE3FeSIxLkw58u0rFG2lLeFIQlav+ijcUH4nD7IHFk9QtNI
+hDgaLdo19AUUK55x4OleXXTyId5pB1djZYwwoqBMMP5S6W9aziMd4EKNAbs2UnC6C2vvE8Qk0Cc
H+q2TkTZinFlAp7azFPKqxgoZmG4OlbNNxGT0L+URBJgf1FMwoWPWcmgxkaGzKgMAD9AbLfbvAAA
AAAAAA==

--Apple-Mail=_4891C85B-C0AD-4433-A044-BA2CAE01B8B4--

From Michael.Jones@microsoft.com  Wed Feb  5 18:08:40 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76721A0207 for ; Wed,  5 Feb 2014 18:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InHolUsoGyOD for ; Wed,  5 Feb 2014 18:08:37 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 090BD1A0214 for ; Wed,  5 Feb 2014 18:08:36 -0800 (PST)
Received: from BY2PR03CA058.namprd03.prod.outlook.com (10.141.249.31) by BY2PR03MB112.namprd03.prod.outlook.com (10.242.36.26) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 02:08:34 +0000
Received: from BY2FFO11FD013.protection.gbl (2a01:111:f400:7c0c::158) by BY2PR03CA058.outlook.office365.com (2a01:111:e400:2c5d::31) with Microsoft SMTP Server (TLS) id 15.0.859.15 via Frontend Transport; Thu, 6 Feb 2014 02:08:34 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.856.14 via Frontend Transport; Thu, 6 Feb 2014 02:08:33 +0000
Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0174.002; Thu, 6 Feb 2014 02:08:06 +0000
From: Mike Jones 
To: Phil Hunt , Eve Maler 
Thread-Topic: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
Thread-Index: AQHPHZrqEhtxa32Q2EGvHz/lGJszjpqeLykAgAXPnoCAA4FdEA==
Date: Thu, 6 Feb 2014 02:08:05 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.21]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(100?= =?us-ascii?Q?09001)(6009001)(24454002)(189002)(13464003)(199002)(51444003?= =?us-ascii?Q?)(377424004)(51704005)(377454003)(53754006)(20776003)(195803?= =?us-ascii?Q?95003)(46102001)(6806004)(46406003)(79102001)(47976001)(8097?= =?us-ascii?Q?6001)(81816001)(63696002)(50986001)(85852003)(47776003)(4396?= =?us-ascii?Q?001)(76786001)(53806001)(81686001)(92726001)(69226001)(74706?= =?us-ascii?Q?001)(76796001)(92566001)(33656001)(55846006)(65816001)(83322?= =?us-ascii?Q?001)(51856001)(19580405001)(44976005)(74662001)(95416001)(77?= =?us-ascii?Q?982001)(56816005)(31966008)(76482001)(74502001)(74876001)(47?= =?us-ascii?Q?736001)(85306002)(90146001)(94946001)(15975445006)(159748650?= =?us-ascii?Q?02)(86362001)(94316002)(93516002)(15202345003)(54316002)(543?= =?us-ascii?Q?56001)(77096001)(66066001)(83072002)(47446002)(50466002)(743?= =?us-ascii?Q?66001)(59766001)(80022001)(49866001)(81542001)(56776001)(237?= =?us-ascii?Q?26002)(86612001)(87266001)(2656002)(93136001)(81342001)(8793?= =?us-ascii?Q?6001);DIR:OUT;SFP:1101;SCL:1;SRVR:BY2PR03MB112;H:mail.micros?= =?us-ascii?Q?oft.com;CLIP:131.107.125.37;FPR:E6FAD1CC.ACF262A8.31D1F10B.8?= =?us-ascii?Q?265F941.20676;InfoDomainNonexistentMX:1;A:1;LANG:en;?=
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0114FF88F6
X-OriginatorOrg: microsoft.com
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 02:08:40 -0000

Thanks for your comments, Phil.  I'm working on addressing them at present.

One comment confuses me.  You wrote "Section 4.1 - It would be good to have=
 an example with a software statement and no initial access token (or both)=
."  Yet the last example in Section 4.1 already is such as an example (take=
n from draft-hunt-oauth-client-association, actually).  Was there something=
 else that you were thinking of?

Also, the "Deployment Organization" definition *does* describe when it and =
the deployment organization are different.  Where I think that the text des=
cribing the choices for the two cases belongs is a subsection of the Use Ca=
ses appendix.  Do you want to write text about the two cases, Phi?

				-- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, February 03, 2014 12:18 PM
To: Eve Maler
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

I am generally in agreement on the new drafts.  Thanks Mike!

Here are some comments:

In the software statement section 3:
> If the authorization server determines that the claims in a software
>    statement uniquely identify a piece of software, the same Client ID
>    value MAY be returned for all dynamic registrations using that
>    software statement.
>=20
>    In some cases, authorization servers MAY choose to accept a software
>    statement value directly as a Client ID in an authorization request,
>    without a prior dynamic client registration having been performed.
>    The circumstances under which an authorization server would do so,
>    and the specific software statement characteristics required in this
>    case, are beyond the scope of this specification.
>=20

We should call out that the server MAY also issue per instance client_id's =
(the opposite of the first quoted paragraph above) if it chooses to use cli=
ent_id as an instance identifier (the software_id identifies what clients a=
re based on the same software).  I think this will be the typical use case.=
 Not sure whether the first paragraph should be re-written, or a new one ad=
ded.

Section 4.1
It would be good to have an example with a software statement and no initia=
l access token (or both).

Section 5.1
Should we also say that is not necessary to return the software statement. =
 Note: the server should return the meta data that was obtained from the st=
atement.

Dyn-Reg-Metadata
The metadata document looks fine.  I would prefer it being included in dyn =
reg, but can live with it as is.

Dyn-Reg-Management
I'd like to discuss this more in London.  I think a SCIM based management A=
PI may be simpler to write up and can leverage the features of SCIM without=
 having to redefine them in a new API.  Still, SCIM is a way off from appro=
val -- so I understand the need to move forward now. Is experimental the ri=
ght way to go?  I am not sure.

Glossary
The terms Software API Publisher and Software API Deployer are defined but =
never used, Specifically the text describing the issue of when these are tw=
o distinct entities is missing. When publisher and deployer are the same (e=
g. as with Facebook), the dynamic registration need is minimal since a clie=
nt_id can be issued from a single domain.  When publisher and deployer are =
different, such as with OpenID Connect, SCIM, then the client developer can=
not pre-register for a client_id at development time. =20

The software statement is an optional mechanism that enables developers to =
pre-registrater to obtain a signed statement (instead of a client_id) so th=
at API deployers can recognize the pre-registration relationship with the p=
ublisher.  Of course, software statements are optional if you don't need to=
 be able to recognize what the client is.  (apologies if I have not phrased=
 the issue optimally)

Maybe if we can put in a couple of paragraphs explaining this distinction? =
=20

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-01-30, at 7:33 PM, Eve Maler  wrote:

> Hi Hannes-- The UMA Core spec currently points directly to the basic dyna=
mic client reg doc with MAY statements, and is agnostic as to usage of the =
higher-order functions. (These turn into optional interop feature tests.) S=
o I think it's fair to say that the split has no structural problems from a=
n UMA perspective.
>=20
> 	Eve
>=20
> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig =
 wrote:
>=20
>> Hi all,
>>=20
>> as you have seen from the meeting minutes of our recent status chat=20
>> it is time to proceed with the dynamic client registration work.
>>=20
>> The earlier version of the dynamic client registration document was=20
>> split into three parts, namely
>> (1) the current working group draft containing only minimal=20
>> functionality,
>> (2) a document describing meta-data, and
>> (3) a document containing management functionality.
>>=20
>> This change was made as outcome of the discussions we had more or=20
>> less over the last 9 months.
>>=20
>> The latter two documents are individual submissions at this point.=20
>> New content is not available with the recent changes. So, it is one=20
>> of those document management issues.
>>=20
>> I had a chat with Stephen about WG adoption of the two individual=20
>> submissions as WG items. It was OK for him given that it is a purely=20
>> document management action. However, before we turn the documents=20
>> into WG items we need your feedback on a number of issues:
>>=20
>> 1) Do you have concerns with the document split? Do you object or=20
>> approve it?
>> 2) Is the separation of the functionality into these three documents=20
>> correct? Should the line be drawn differently?
>> 3) Do you have comments on the documents overall?
>>=20
>> We would like to receive high-level feedback within a week. We are=20
>> also eager to hear from implementers and other projects using the=20
>> dynamic client registration work (such as OpenID Connect, UMA, the=20
>> BlueButton/GreenButton Initiative, etc.)
>>=20
>> For more detailed reviews please wait till we re-do the WGLC (which=20
>> we plan to do soon). We have to restart the WGLC due to discussions=20
>> last years and the resulting changes to these documents.
>>=20
>> Ciao
>> Hannes & Derek
>>=20
>> PS: Derek and I also think that Phil should become co-auhor of these=20
>> documents for his contributions.
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

From Michael.Jones@microsoft.com  Wed Feb  5 18:12:04 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5738B1A0214 for ; Wed,  5 Feb 2014 18:12:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0QsOntZm49T for ; Wed,  5 Feb 2014 18:12:01 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id EC5E11A0207 for ; Wed,  5 Feb 2014 18:12:00 -0800 (PST)
Received: from DM2PR03CA009.namprd03.prod.outlook.com (10.141.52.157) by BY2PR03MB010.namprd03.prod.outlook.com (10.255.240.36) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 02:11:58 +0000
Received: from BN1AFFO11FD026.protection.gbl (2a01:111:f400:7c10::131) by DM2PR03CA009.outlook.office365.com (2a01:111:e400:2414::29) with Microsoft SMTP Server (TLS) id 15.0.868.8 via Frontend Transport; Thu, 6 Feb 2014 02:11:58 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD026.mail.protection.outlook.com (10.58.52.86) with Microsoft SMTP Server (TLS) id 15.0.856.14 via Frontend Transport; Thu, 6 Feb 2014 02:11:57 +0000
Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0174.002; Thu, 6 Feb 2014 02:11:29 +0000
From: Mike Jones 
To: Phil Hunt , Eve Maler 
Thread-Topic: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
Thread-Index: AQHPHZrqEhtxa32Q2EGvHz/lGJszjpqeLykAgAXPnoCAA4FdEIAABdPA
Date: Thu, 6 Feb 2014 02:11:27 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.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.21]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(100?= =?us-ascii?Q?09001)(6009001)(377424004)(53754006)(189002)(199002)(5085400?= =?us-ascii?Q?3)(377454003)(13464003)(24454002)(51704005)(51444003)(660660?= =?us-ascii?Q?01)(93136001)(31966008)(47446002)(92726001)(15202345003)(568?= =?us-ascii?Q?16005)(33656001)(49866001)(50986001)(47776003)(80022001)(935?= =?us-ascii?Q?16002)(74662001)(81342001)(85306002)(51856001)(81686001)(159?= =?us-ascii?Q?74865002)(65816001)(20776003)(15975445006)(63696002)(9014600?= =?us-ascii?Q?1)(47976001)(23726002)(47736001)(76796001)(50466002)(8154200?= =?us-ascii?Q?1)(85852003)(46102001)(74876001)(2656002)(94316002)(87266001?= =?us-ascii?Q?)(53806001)(4396001)(94946001)(6806004)(92566001)(77982001)(?= =?us-ascii?Q?87936001)(59766001)(74366001)(79102001)(86362001)(74706001)(?= =?us-ascii?Q?56776001)(80976001)(54316002)(46406003)(74502001)(77096001)(?= =?us-ascii?Q?76482001)(81816001)(54356001)(55846006)(44976005)(69226001)(?= =?us-ascii?Q?19580395003)(86612001)(19580405001)(83322001)(83072002)(7678?= =?us-ascii?Q?6001)(95416001);DIR:OUT;SFP:1101;SCL:1;SRVR:BY2PR03MB010;H:m?= =?us-ascii?Q?ail.microsoft.com;CLIP:131.107.125.37;FPR:E6FAD1CC.ACF26288.?= =?us-ascii?Q?31D1F10B.8264F941.2069B;InfoDomainNonexistentMX:1;A:1;LANG:e?= =?us-ascii?Q?n;?=
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0114FF88F6
X-OriginatorOrg: microsoft.com
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 02:12:04 -0000

Oh, I should add that I disagree that it's not necessary to return the soft=
ware statement.  It's a key part of the client registration information, an=
d so should be returned like the other client registration information actu=
ally used.

				-- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 05, 2014 6:08 PM
To: Phil Hunt; Eve Maler
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

Thanks for your comments, Phil.  I'm working on addressing them at present.

One comment confuses me.  You wrote "Section 4.1 - It would be good to have=
 an example with a software statement and no initial access token (or both)=
."  Yet the last example in Section 4.1 already is such as an example (take=
n from draft-hunt-oauth-client-association, actually).  Was there something=
 else that you were thinking of?

Also, the "Deployment Organization" definition *does* describe when it and =
the deployment organization are different.  Where I think that the text des=
cribing the choices for the two cases belongs is a subsection of the Use Ca=
ses appendix.  Do you want to write text about the two cases, Phi?

				-- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, February 03, 2014 12:18 PM
To: Eve Maler
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

I am generally in agreement on the new drafts.  Thanks Mike!

Here are some comments:

In the software statement section 3:
> If the authorization server determines that the claims in a software
>    statement uniquely identify a piece of software, the same Client ID
>    value MAY be returned for all dynamic registrations using that
>    software statement.
>=20
>    In some cases, authorization servers MAY choose to accept a software
>    statement value directly as a Client ID in an authorization request,
>    without a prior dynamic client registration having been performed.
>    The circumstances under which an authorization server would do so,
>    and the specific software statement characteristics required in this
>    case, are beyond the scope of this specification.
>=20

We should call out that the server MAY also issue per instance client_id's =
(the opposite of the first quoted paragraph above) if it chooses to use cli=
ent_id as an instance identifier (the software_id identifies what clients a=
re based on the same software).  I think this will be the typical use case.=
 Not sure whether the first paragraph should be re-written, or a new one ad=
ded.

Section 4.1
It would be good to have an example with a software statement and no initia=
l access token (or both).

Section 5.1
Should we also say that is not necessary to return the software statement. =
 Note: the server should return the meta data that was obtained from the st=
atement.

Dyn-Reg-Metadata
The metadata document looks fine.  I would prefer it being included in dyn =
reg, but can live with it as is.

Dyn-Reg-Management
I'd like to discuss this more in London.  I think a SCIM based management A=
PI may be simpler to write up and can leverage the features of SCIM without=
 having to redefine them in a new API.  Still, SCIM is a way off from appro=
val -- so I understand the need to move forward now. Is experimental the ri=
ght way to go?  I am not sure.

Glossary
The terms Software API Publisher and Software API Deployer are defined but =
never used, Specifically the text describing the issue of when these are tw=
o distinct entities is missing. When publisher and deployer are the same (e=
g. as with Facebook), the dynamic registration need is minimal since a clie=
nt_id can be issued from a single domain.  When publisher and deployer are =
different, such as with OpenID Connect, SCIM, then the client developer can=
not pre-register for a client_id at development time. =20

The software statement is an optional mechanism that enables developers to =
pre-registrater to obtain a signed statement (instead of a client_id) so th=
at API deployers can recognize the pre-registration relationship with the p=
ublisher.  Of course, software statements are optional if you don't need to=
 be able to recognize what the client is.  (apologies if I have not phrased=
 the issue optimally)

Maybe if we can put in a couple of paragraphs explaining this distinction? =
=20

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-01-30, at 7:33 PM, Eve Maler  wrote:

> Hi Hannes-- The UMA Core spec currently points directly to the basic dyna=
mic client reg doc with MAY statements, and is agnostic as to usage of the =
higher-order functions. (These turn into optional interop feature tests.) S=
o I think it's fair to say that the split has no structural problems from a=
n UMA perspective.
>=20
> 	Eve
>=20
> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig =
 wrote:
>=20
>> Hi all,
>>=20
>> as you have seen from the meeting minutes of our recent status chat=20
>> it is time to proceed with the dynamic client registration work.
>>=20
>> The earlier version of the dynamic client registration document was=20
>> split into three parts, namely
>> (1) the current working group draft containing only minimal=20
>> functionality,
>> (2) a document describing meta-data, and
>> (3) a document containing management functionality.
>>=20
>> This change was made as outcome of the discussions we had more or=20
>> less over the last 9 months.
>>=20
>> The latter two documents are individual submissions at this point.=20
>> New content is not available with the recent changes. So, it is one=20
>> of those document management issues.
>>=20
>> I had a chat with Stephen about WG adoption of the two individual=20
>> submissions as WG items. It was OK for him given that it is a purely=20
>> document management action. However, before we turn the documents=20
>> into WG items we need your feedback on a number of issues:
>>=20
>> 1) Do you have concerns with the document split? Do you object or=20
>> approve it?
>> 2) Is the separation of the functionality into these three documents=20
>> correct? Should the line be drawn differently?
>> 3) Do you have comments on the documents overall?
>>=20
>> We would like to receive high-level feedback within a week. We are=20
>> also eager to hear from implementers and other projects using the=20
>> dynamic client registration work (such as OpenID Connect, UMA, the=20
>> BlueButton/GreenButton Initiative, etc.)
>>=20
>> For more detailed reviews please wait till we re-do the WGLC (which=20
>> we plan to do soon). We have to restart the WGLC due to discussions=20
>> last years and the resulting changes to these documents.
>>=20
>> Ciao
>> Hannes & Derek
>>=20
>> PS: Derek and I also think that Phil should become co-auhor of these=20
>> documents for his contributions.
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>=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

From Hannes.Tschofenig@gmx.net  Thu Feb  6 02:30:54 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839101A022D for ; Thu,  6 Feb 2014 02:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q2QWmmZftUV for ; Thu,  6 Feb 2014 02:30:52 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 388C71A00C4 for ; Thu,  6 Feb 2014 02:30:52 -0800 (PST)
Received: from 3capp-gmx-bs42.server.lan ([172.19.170.94]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MWvJi-1VhZLJ3RXY-00VysA for ; Thu, 06 Feb 2014 11:30:49 +0100
Received: from [217.140.96.21] by 3capp-gmx-bs42.server.lan with HTTP; Thu Feb 06 11:30:49 CET 2014
MIME-Version: 1.0
Message-ID: 
From: "Hannes Tschofenig" 
To: oauth@ietf.org, "Barry Leiba" , barryleiba@gmail.com
Content-Type: text/plain; charset=UTF-8
Date: Thu, 6 Feb 2014 11:30:49 +0100 (CET)
Importance: normal
Sensitivity: Normal
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-Provags-ID: V03:K0:sEqGVDaPHh/jozHNg1lApqaMz89OrObLmVvxPzoIexQ qfJzWkmYI2HiwyKST4y/1D+oGFKzdsR6pX1rW+PDRcI+JCmP3M WXdo593ZFqogqj+5OigHLaBSMwCjud+FW0S62oRUg1Fbf3X+SG 013wA+9JTG9H0gD1IpT9D2C3ALpCh09Zk4SpyclaIrLQUplR2v ZhP2Va2GOo+PO97qGc/axB95ZZdm8HqSrZ9i2e7uRAOjbIlCIp yKu0w016GnedaQszSi3lobI7I3RHmLLr5cY64/+Yppn1HsgI9o r44vEg=
Subject: [OAUTH-WG] Shepherd Write-Ups for OAuth Assertion Framework and SAML Assertion Profile
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 10:30:54 -0000

Hi Barry,=C2=A0
=C2=A0
here is a new attempt to get the OAuth assertion drafts finalized. The aut=
hors have updated the drafts during the last year (after they returned from=
 the IESG back to the working group). My shepherd write-ups can be found he=
re:=C2=A0
=C2=A0
The shepherd write-ups can be found here:https://github.com/hannestschofen=
ig/tschofenig-ids/tree/master/shepherd-writeups

Please have a look at the most recent drafts and tell me whether they are =
in an acceptable shape.=20
Here are the docs:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/=C2=A0
=C2=A0
Ciao
Hannes
=C2=A0

From phil.hunt@oracle.com  Thu Feb  6 10:27:50 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C021A00FE for ; Thu,  6 Feb 2014 10:27:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.236
X-Spam-Level: 
X-Spam-Status: No, score=-4.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl45cfLdz4Tj for ; Thu,  6 Feb 2014 10:27:47 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 712BA1A01B6 for ; Thu,  6 Feb 2014 10:27:47 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s16IRjZI020671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Feb 2014 18:27:46 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s16IRjFk022291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Feb 2014 18:27:45 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s16IRiH8028521; Thu, 6 Feb 2014 18:27:44 GMT
Received: from [192.168.1.124] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Feb 2014 10:27:44 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Phil Hunt 
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com>
Date: Thu, 6 Feb 2014 10:27:45 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <45B556F5-0D8D-45D5-8FCC-FCE45BBA71D3@oracle.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1510)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 18:27:50 -0000

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-02-05, at 6:08 PM, Mike Jones  =
wrote:

> Thanks for your comments, Phil.  I'm working on addressing them at =
present.
>=20
> One comment confuses me.  You wrote "Section 4.1 - It would be good to =
have an example with a software statement and no initial access token =
(or both)."  Yet the last example in Section 4.1 already is such as an =
example (taken from draft-hunt-oauth-client-association, actually).  Was =
there something else that you were thinking of?
[PH[  My bad. It is the last example on the next page.  Thanks.
>=20
> Also, the "Deployment Organization" definition *does* describe when it =
and the deployment organization are different.  Where I think that the =
text describing the choices for the two cases belongs is a subsection of =
the Use Cases appendix.  Do you want to write text about the two cases, =
Phi?
[PH] In the interest of keeping it short. I think I can live with it. =20=


I notice the term "software assertion" has crept in. While technically =
true, I was avoiding use of the word "assertion" because the purpose is =
to make statements (claims) about the profile of the software rather =
than trying to prove that the client is the software.

>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
> Sent: Monday, February 03, 2014 12:18 PM
> To: Eve Maler
> Cc: oauth@ietf.org list
> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>=20
> I am generally in agreement on the new drafts.  Thanks Mike!
>=20
> Here are some comments:
>=20
> In the software statement section 3:
>> If the authorization server determines that the claims in a software
>>   statement uniquely identify a piece of software, the same Client ID
>>   value MAY be returned for all dynamic registrations using that
>>   software statement.
>>=20
>>   In some cases, authorization servers MAY choose to accept a =
software
>>   statement value directly as a Client ID in an authorization =
request,
>>   without a prior dynamic client registration having been performed.
>>   The circumstances under which an authorization server would do so,
>>   and the specific software statement characteristics required in =
this
>>   case, are beyond the scope of this specification.
>>=20
>=20
> We should call out that the server MAY also issue per instance =
client_id's (the opposite of the first quoted paragraph above) if it =
chooses to use client_id as an instance identifier (the software_id =
identifies what clients are based on the same software).  I think this =
will be the typical use case. Not sure whether the first paragraph =
should be re-written, or a new one added.
>=20
> Section 4.1
> It would be good to have an example with a software statement and no =
initial access token (or both).
>=20
> Section 5.1
> Should we also say that is not necessary to return the software =
statement.  Note: the server should return the meta data that was =
obtained from the statement.
>=20
> Dyn-Reg-Metadata
> The metadata document looks fine.  I would prefer it being included in =
dyn reg, but can live with it as is.
>=20
> Dyn-Reg-Management
> I'd like to discuss this more in London.  I think a SCIM based =
management API may be simpler to write up and can leverage the features =
of SCIM without having to redefine them in a new API.  Still, SCIM is a =
way off from approval -- so I understand the need to move forward now. =
Is experimental the right way to go?  I am not sure.
>=20
> Glossary
> The terms Software API Publisher and Software API Deployer are defined =
but never used, Specifically the text describing the issue of when these =
are two distinct entities is missing. When publisher and deployer are =
the same (eg. as with Facebook), the dynamic registration need is =
minimal since a client_id can be issued from a single domain.  When =
publisher and deployer are different, such as with OpenID Connect, SCIM, =
then the client developer cannot pre-register for a client_id at =
development time. =20
>=20
> The software statement is an optional mechanism that enables =
developers to pre-registrater to obtain a signed statement (instead of a =
client_id) so that API deployers can recognize the pre-registration =
relationship with the publisher.  Of course, software statements are =
optional if you don't need to be able to recognize what the client is.  =
(apologies if I have not phrased the issue optimally)
>=20
> Maybe if we can put in a couple of paragraphs explaining this =
distinction? =20
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>=20
>> Hi Hannes-- The UMA Core spec currently points directly to the basic =
dynamic client reg doc with MAY statements, and is agnostic as to usage =
of the higher-order functions. (These turn into optional interop feature =
tests.) So I think it's fair to say that the split has no structural =
problems from an UMA perspective.
>>=20
>> 	Eve
>>=20
>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig =
 wrote:
>>=20
>>> Hi all,
>>>=20
>>> as you have seen from the meeting minutes of our recent status chat=20=

>>> it is time to proceed with the dynamic client registration work.
>>>=20
>>> The earlier version of the dynamic client registration document was=20=

>>> split into three parts, namely
>>> (1) the current working group draft containing only minimal=20
>>> functionality,
>>> (2) a document describing meta-data, and
>>> (3) a document containing management functionality.
>>>=20
>>> This change was made as outcome of the discussions we had more or=20
>>> less over the last 9 months.
>>>=20
>>> The latter two documents are individual submissions at this point.=20=

>>> New content is not available with the recent changes. So, it is one=20=

>>> of those document management issues.
>>>=20
>>> I had a chat with Stephen about WG adoption of the two individual=20
>>> submissions as WG items. It was OK for him given that it is a purely=20=

>>> document management action. However, before we turn the documents=20
>>> into WG items we need your feedback on a number of issues:
>>>=20
>>> 1) Do you have concerns with the document split? Do you object or=20
>>> approve it?
>>> 2) Is the separation of the functionality into these three documents=20=

>>> correct? Should the line be drawn differently?
>>> 3) Do you have comments on the documents overall?
>>>=20
>>> We would like to receive high-level feedback within a week. We are=20=

>>> also eager to hear from implementers and other projects using the=20
>>> dynamic client registration work (such as OpenID Connect, UMA, the=20=

>>> BlueButton/GreenButton Initiative, etc.)
>>>=20
>>> For more detailed reviews please wait till we re-do the WGLC (which=20=

>>> we plan to do soon). We have to restart the WGLC due to discussions=20=

>>> last years and the resulting changes to these documents.
>>>=20
>>> Ciao
>>> Hannes & Derek
>>>=20
>>> PS: Derek and I also think that Phil should become co-auhor of these=20=

>>> documents for his contributions.
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>=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 phil.hunt@oracle.com  Thu Feb  6 10:34:00 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F941A0420 for ; Thu,  6 Feb 2014 10:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.236
X-Spam-Level: 
X-Spam-Status: No, score=-4.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqI52pMkyKYJ for ; Thu,  6 Feb 2014 10:33:57 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF171A01DE for ; Thu,  6 Feb 2014 10:33:57 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s16IXt00007202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Feb 2014 18:33:56 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s16IXs3F001328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Feb 2014 18:33:55 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s16IXsu2002339; Thu, 6 Feb 2014 18:33:54 GMT
Received: from [192.168.1.124] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Feb 2014 10:33:54 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Phil Hunt 
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com>
Date: Thu, 6 Feb 2014 10:33:54 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <00622740-EA6B-4C4B-9FAB-653B197BE028@oracle.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1510)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 18:34:00 -0000

My thought was the original statement shouldn't be returned because the =
server would return the "processed" information.  IOW reflecting what it =
took from the certificate vs. from the registration request.

If you just echo back the certificate you aren't necessarily reflecting =
the final state of the registration.

I'm pretty open on this. Just want to make clear on what state we are =
returning (if any).

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-02-05, at 6:11 PM, Mike Jones  =
wrote:

> Oh, I should add that I disagree that it's not necessary to return the =
software statement.  It's a key part of the client registration =
information, and so should be returned like the other client =
registration information actually used.
>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 05, 2014 6:08 PM
> To: Phil Hunt; Eve Maler
> Cc: oauth@ietf.org list
> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>=20
> Thanks for your comments, Phil.  I'm working on addressing them at =
present.
>=20
> One comment confuses me.  You wrote "Section 4.1 - It would be good to =
have an example with a software statement and no initial access token =
(or both)."  Yet the last example in Section 4.1 already is such as an =
example (taken from draft-hunt-oauth-client-association, actually).  Was =
there something else that you were thinking of?
>=20
> Also, the "Deployment Organization" definition *does* describe when it =
and the deployment organization are different.  Where I think that the =
text describing the choices for the two cases belongs is a subsection of =
the Use Cases appendix.  Do you want to write text about the two cases, =
Phi?
>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
> Sent: Monday, February 03, 2014 12:18 PM
> To: Eve Maler
> Cc: oauth@ietf.org list
> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>=20
> I am generally in agreement on the new drafts.  Thanks Mike!
>=20
> Here are some comments:
>=20
> In the software statement section 3:
>> If the authorization server determines that the claims in a software
>>   statement uniquely identify a piece of software, the same Client ID
>>   value MAY be returned for all dynamic registrations using that
>>   software statement.
>>=20
>>   In some cases, authorization servers MAY choose to accept a =
software
>>   statement value directly as a Client ID in an authorization =
request,
>>   without a prior dynamic client registration having been performed.
>>   The circumstances under which an authorization server would do so,
>>   and the specific software statement characteristics required in =
this
>>   case, are beyond the scope of this specification.
>>=20
>=20
> We should call out that the server MAY also issue per instance =
client_id's (the opposite of the first quoted paragraph above) if it =
chooses to use client_id as an instance identifier (the software_id =
identifies what clients are based on the same software).  I think this =
will be the typical use case. Not sure whether the first paragraph =
should be re-written, or a new one added.
>=20
> Section 4.1
> It would be good to have an example with a software statement and no =
initial access token (or both).
>=20
> Section 5.1
> Should we also say that is not necessary to return the software =
statement.  Note: the server should return the meta data that was =
obtained from the statement.
>=20
> Dyn-Reg-Metadata
> The metadata document looks fine.  I would prefer it being included in =
dyn reg, but can live with it as is.
>=20
> Dyn-Reg-Management
> I'd like to discuss this more in London.  I think a SCIM based =
management API may be simpler to write up and can leverage the features =
of SCIM without having to redefine them in a new API.  Still, SCIM is a =
way off from approval -- so I understand the need to move forward now. =
Is experimental the right way to go?  I am not sure.
>=20
> Glossary
> The terms Software API Publisher and Software API Deployer are defined =
but never used, Specifically the text describing the issue of when these =
are two distinct entities is missing. When publisher and deployer are =
the same (eg. as with Facebook), the dynamic registration need is =
minimal since a client_id can be issued from a single domain.  When =
publisher and deployer are different, such as with OpenID Connect, SCIM, =
then the client developer cannot pre-register for a client_id at =
development time. =20
>=20
> The software statement is an optional mechanism that enables =
developers to pre-registrater to obtain a signed statement (instead of a =
client_id) so that API deployers can recognize the pre-registration =
relationship with the publisher.  Of course, software statements are =
optional if you don't need to be able to recognize what the client is.  =
(apologies if I have not phrased the issue optimally)
>=20
> Maybe if we can put in a couple of paragraphs explaining this =
distinction? =20
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>=20
>> Hi Hannes-- The UMA Core spec currently points directly to the basic =
dynamic client reg doc with MAY statements, and is agnostic as to usage =
of the higher-order functions. (These turn into optional interop feature =
tests.) So I think it's fair to say that the split has no structural =
problems from an UMA perspective.
>>=20
>> 	Eve
>>=20
>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig =
 wrote:
>>=20
>>> Hi all,
>>>=20
>>> as you have seen from the meeting minutes of our recent status chat=20=

>>> it is time to proceed with the dynamic client registration work.
>>>=20
>>> The earlier version of the dynamic client registration document was=20=

>>> split into three parts, namely
>>> (1) the current working group draft containing only minimal=20
>>> functionality,
>>> (2) a document describing meta-data, and
>>> (3) a document containing management functionality.
>>>=20
>>> This change was made as outcome of the discussions we had more or=20
>>> less over the last 9 months.
>>>=20
>>> The latter two documents are individual submissions at this point.=20=

>>> New content is not available with the recent changes. So, it is one=20=

>>> of those document management issues.
>>>=20
>>> I had a chat with Stephen about WG adoption of the two individual=20
>>> submissions as WG items. It was OK for him given that it is a purely=20=

>>> document management action. However, before we turn the documents=20
>>> into WG items we need your feedback on a number of issues:
>>>=20
>>> 1) Do you have concerns with the document split? Do you object or=20
>>> approve it?
>>> 2) Is the separation of the functionality into these three documents=20=

>>> correct? Should the line be drawn differently?
>>> 3) Do you have comments on the documents overall?
>>>=20
>>> We would like to receive high-level feedback within a week. We are=20=

>>> also eager to hear from implementers and other projects using the=20
>>> dynamic client registration work (such as OpenID Connect, UMA, the=20=

>>> BlueButton/GreenButton Initiative, etc.)
>>>=20
>>> For more detailed reviews please wait till we re-do the WGLC (which=20=

>>> we plan to do soon). We have to restart the WGLC due to discussions=20=

>>> last years and the resulting changes to these documents.
>>>=20
>>> Ciao
>>> Hannes & Derek
>>>=20
>>> PS: Derek and I also think that Phil should become co-auhor of these=20=

>>> documents for his contributions.
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From ve7jtb@ve7jtb.com  Thu Feb  6 10:39:13 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30B51A044E for ; Thu,  6 Feb 2014 10:39:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6jFIZDKn43d for ; Thu,  6 Feb 2014 10:39:10 -0800 (PST)
Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id B057A1A0274 for ; Thu,  6 Feb 2014 10:39:10 -0800 (PST)
Received: by mail-qc0-f175.google.com with SMTP id x13so3905453qcv.34 for ; Thu, 06 Feb 2014 10:39:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=7kbBqsYPNg8PRIXGQE0Uy8PyggPjreU4zERq4H+tfZg=; b=LSnBISnUqpeoz4xHAnk/4ZUOKv+cCnFRfg9xmDwVpXRWPT7wx/hM5qhhFfPSyWeCBn K/XSuw4nPnfRgyxnMRWEYSgAaOoaY+A6C8j8d53EQHOD1gJqbA8tbHLyUS57TVDkNbtJ q9I14iq5hAmWfONiFpj7TIB1OLGCP1+9175JuQoHjrarNAL3YeG1nyMYWhK0qk5hdLHo +6VWtS2j8C/Qx9bsvTSfCciktBKnElBJ8nr+6rmeTTyZb9M6/VSM51hXzYBn8EOQnp6g IDWuMBTUWd9a4GJU9Kj2/MuL6ctQr1kEx0IGTXPkhn1jS/Y09KlzPw/G/r9bsm9y1+Lr mz4w==
X-Gm-Message-State: ALoCoQlaOeJJixulxj48TW6N0y6dTtjRD79aHXGEZTqOfeSFncrCSutTRf2Qf/orjkxEPiZgBZZj
X-Received: by 10.140.40.5 with SMTP id w5mr13955479qgw.65.1391711948741; Thu, 06 Feb 2014 10:39:08 -0800 (PST)
Received: from [192.168.0.200] ([201.189.102.146]) by mx.google.com with ESMTPSA id l40sm3034475qga.13.2014.02.06.10.39.03 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 10:39:07 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_AC1BC919-4E37-42B7-A5CC-623E54C45CB8"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley 
In-Reply-To: <00622740-EA6B-4C4B-9FAB-653B197BE028@oracle.com>
Date: Thu, 6 Feb 2014 15:38:54 -0300
Message-Id: 
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com> <00622740-EA6B-4C4B-9FAB-653B197BE028@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.1827)
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 18:39:13 -0000

--Apple-Mail=_AC1BC919-4E37-42B7-A5CC-623E54C45CB8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I think it would be echoing back the software statement  that was =
processed as part of the request for consistency.   Replying with a =
different software statement is going to be too confusing.  =20
The entirety of the reply represents the configured state for the =
client.

John B.

On Feb 6, 2014, at 3:33 PM, Phil Hunt  wrote:

> My thought was the original statement shouldn't be returned because =
the server would return the "processed" information.  IOW reflecting =
what it took from the certificate vs. from the registration request.
>=20
> If you just echo back the certificate you aren't necessarily =
reflecting the final state of the registration.
>=20
> I'm pretty open on this. Just want to make clear on what state we are =
returning (if any).
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> On 2014-02-05, at 6:11 PM, Mike Jones  =
wrote:
>=20
>> Oh, I should add that I disagree that it's not necessary to return =
the software statement.  It's a key part of the client registration =
information, and so should be returned like the other client =
registration information actually used.
>>=20
>> 				-- Mike
>>=20
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
>> Sent: Wednesday, February 05, 2014 6:08 PM
>> To: Phil Hunt; Eve Maler
>> Cc: oauth@ietf.org list
>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>=20
>> Thanks for your comments, Phil.  I'm working on addressing them at =
present.
>>=20
>> One comment confuses me.  You wrote "Section 4.1 - It would be good =
to have an example with a software statement and no initial access token =
(or both)."  Yet the last example in Section 4.1 already is such as an =
example (taken from draft-hunt-oauth-client-association, actually).  Was =
there something else that you were thinking of?
>>=20
>> Also, the "Deployment Organization" definition *does* describe when =
it and the deployment organization are different.  Where I think that =
the text describing the choices for the two cases belongs is a =
subsection of the Use Cases appendix.  Do you want to write text about =
the two cases, Phi?
>>=20
>> 				-- Mike
>>=20
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
>> Sent: Monday, February 03, 2014 12:18 PM
>> To: Eve Maler
>> Cc: oauth@ietf.org list
>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>=20
>> I am generally in agreement on the new drafts.  Thanks Mike!
>>=20
>> Here are some comments:
>>=20
>> In the software statement section 3:
>>> If the authorization server determines that the claims in a software
>>>  statement uniquely identify a piece of software, the same Client ID
>>>  value MAY be returned for all dynamic registrations using that
>>>  software statement.
>>>=20
>>>  In some cases, authorization servers MAY choose to accept a =
software
>>>  statement value directly as a Client ID in an authorization =
request,
>>>  without a prior dynamic client registration having been performed.
>>>  The circumstances under which an authorization server would do so,
>>>  and the specific software statement characteristics required in =
this
>>>  case, are beyond the scope of this specification.
>>>=20
>>=20
>> We should call out that the server MAY also issue per instance =
client_id's (the opposite of the first quoted paragraph above) if it =
chooses to use client_id as an instance identifier (the software_id =
identifies what clients are based on the same software).  I think this =
will be the typical use case. Not sure whether the first paragraph =
should be re-written, or a new one added.
>>=20
>> Section 4.1
>> It would be good to have an example with a software statement and no =
initial access token (or both).
>>=20
>> Section 5.1
>> Should we also say that is not necessary to return the software =
statement.  Note: the server should return the meta data that was =
obtained from the statement.
>>=20
>> Dyn-Reg-Metadata
>> The metadata document looks fine.  I would prefer it being included =
in dyn reg, but can live with it as is.
>>=20
>> Dyn-Reg-Management
>> I'd like to discuss this more in London.  I think a SCIM based =
management API may be simpler to write up and can leverage the features =
of SCIM without having to redefine them in a new API.  Still, SCIM is a =
way off from approval -- so I understand the need to move forward now. =
Is experimental the right way to go?  I am not sure.
>>=20
>> Glossary
>> The terms Software API Publisher and Software API Deployer are =
defined but never used, Specifically the text describing the issue of =
when these are two distinct entities is missing. When publisher and =
deployer are the same (eg. as with Facebook), the dynamic registration =
need is minimal since a client_id can be issued from a single domain.  =
When publisher and deployer are different, such as with OpenID Connect, =
SCIM, then the client developer cannot pre-register for a client_id at =
development time. =20
>>=20
>> The software statement is an optional mechanism that enables =
developers to pre-registrater to obtain a signed statement (instead of a =
client_id) so that API deployers can recognize the pre-registration =
relationship with the publisher.  Of course, software statements are =
optional if you don't need to be able to recognize what the client is.  =
(apologies if I have not phrased the issue optimally)
>>=20
>> Maybe if we can put in a couple of paragraphs explaining this =
distinction? =20
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>>=20
>>> Hi Hannes-- The UMA Core spec currently points directly to the basic =
dynamic client reg doc with MAY statements, and is agnostic as to usage =
of the higher-order functions. (These turn into optional interop feature =
tests.) So I think it's fair to say that the split has no structural =
problems from an UMA perspective.
>>>=20
>>> 	Eve
>>>=20
>>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig =
 wrote:
>>>=20
>>>> Hi all,
>>>>=20
>>>> as you have seen from the meeting minutes of our recent status chat=20=

>>>> it is time to proceed with the dynamic client registration work.
>>>>=20
>>>> The earlier version of the dynamic client registration document was=20=

>>>> split into three parts, namely
>>>> (1) the current working group draft containing only minimal=20
>>>> functionality,
>>>> (2) a document describing meta-data, and
>>>> (3) a document containing management functionality.
>>>>=20
>>>> This change was made as outcome of the discussions we had more or=20=

>>>> less over the last 9 months.
>>>>=20
>>>> The latter two documents are individual submissions at this point.=20=

>>>> New content is not available with the recent changes. So, it is one=20=

>>>> of those document management issues.
>>>>=20
>>>> I had a chat with Stephen about WG adoption of the two individual=20=

>>>> submissions as WG items. It was OK for him given that it is a =
purely=20
>>>> document management action. However, before we turn the documents=20=

>>>> into WG items we need your feedback on a number of issues:
>>>>=20
>>>> 1) Do you have concerns with the document split? Do you object or=20=

>>>> approve it?
>>>> 2) Is the separation of the functionality into these three =
documents=20
>>>> correct? Should the line be drawn differently?
>>>> 3) Do you have comments on the documents overall?
>>>>=20
>>>> We would like to receive high-level feedback within a week. We are=20=

>>>> also eager to hear from implementers and other projects using the=20=

>>>> dynamic client registration work (such as OpenID Connect, UMA, the=20=

>>>> BlueButton/GreenButton Initiative, etc.)
>>>>=20
>>>> For more detailed reviews please wait till we re-do the WGLC (which=20=

>>>> we plan to do soon). We have to restart the WGLC due to discussions=20=

>>>> last years and the resulting changes to these documents.
>>>>=20
>>>> Ciao
>>>> Hannes & Derek
>>>>=20
>>>> PS: Derek and I also think that Phil should become co-auhor of =
these=20
>>>> documents for his contributions.
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>>=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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_AC1BC919-4E37-42B7-A5CC-623E54C45CB8
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA2MTgzODU1WjAjBgkqhkiG9w0BCQQxFgQULUns4ZsA
rbOEA24hOQvGohncArswgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEANNXT0Szi0aLDNkqA3ltSDErmxNFu1ekSr/IVWu09
apSg/8AjCg22LnfEwiroG0NyggGAsX6Umcj+hdPJRzlNccdYStqsEW+RBWLxv2agMlZdHTH3uL7J
KtMqjEFIyeg/l/5eMdpnZCdhj+KSRNAafQkfgVaVzCMJ8mwKMvmojiXyiUmPzudGtnDpU+2H6De/
hwHtf5bjAYzTOAaj03czJGHt4yw9QrX/zksPqs9+inOpanpvZWb+XsQYmmgDR2vMmKtT/d+7tDlj
tKTDHfWj32FEDMT/56CcBaaScUsg/dwIV/LgQSQ3HhQso9RnOr5ZKjIoO4GZn8uhWk/DHwJOBAAA
AAAAAA==

--Apple-Mail=_AC1BC919-4E37-42B7-A5CC-623E54C45CB8--

From tonynad@microsoft.com  Thu Feb  6 10:41:42 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13981A01E3 for ; Thu,  6 Feb 2014 10:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl8gKli48ZMh for ; Thu,  6 Feb 2014 10:41:37 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id E8FEF1A0455 for ; Thu,  6 Feb 2014 10:41:34 -0800 (PST)
Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB311.namprd03.prod.outlook.com (10.141.48.26) with Microsoft SMTP Server (TLS) id 15.0.873.10; Thu, 6 Feb 2014 18:41:22 +0000
Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0873.009; Thu, 6 Feb 2014 18:41:22 +0000
From: Anthony Nadalin 
To: John Bradley , Phil Hunt 
Thread-Topic: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
Thread-Index: AQHPHZrcj5aIvhL6QUWwHABRilQciJqeLykAgAXPnoCAA4aOgIAAAPCAgAESfwCAAAFlAIAAAEWQ
Date: Thu, 6 Feb 2014 18:41:21 +0000
Message-ID: <356ded516f534bb18f33be2d50736dc4@BLUPR03MB309.namprd03.prod.outlook.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com> <00622740-EA6B-4C4B-9FAB-653B197BE028@oracle.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::3]
x-forefront-prvs: 0114FF88F6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(377454003)(53754006)(51704005)(377424004)(13464003)(24454002)(50854003)(51444003)(189002)(199002)(74706001)(53806001)(85306002)(31966008)(54356001)(76482001)(51856001)(74502001)(90146001)(50986001)(74662001)(47976001)(87936001)(80022001)(87266001)(2656002)(33646001)(49866001)(94946001)(15975445006)(59766001)(81816001)(74876001)(81686001)(54316002)(92566001)(79102001)(77982001)(74366001)(95416001)(47446002)(56776001)(86612001)(65816001)(63696002)(19580405001)(85852003)(83322001)(80976001)(46102001)(94316002)(47736001)(15974865002)(76576001)(15202345003)(83072002)(76796001)(76786001)(93136001)(81342001)(74316001)(93516002)(19580395003)(56816005)(81542001)(86362001)(69226001)(4396001)(42262001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB311; H:BLUPR03MB309.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::3; FPR:E6FAD1CC.ACF26288.31D3F10B.8264F941.20715; InfoNoRecordsMX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 18:41:42 -0000

I would agree with Phil, the server makes right in this case, specific stat=
ement may be sent but the processed statement is returned which may be diff=
erent

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Thursday, February 6, 2014 10:39 AM
To: Phil Hunt
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

I think it would be echoing back the software statement  that was processed=
 as part of the request for consistency.   Replying with a different softwa=
re statement is going to be too confusing.  =20
The entirety of the reply represents the configured state for the client.

John B.

On Feb 6, 2014, at 3:33 PM, Phil Hunt  wrote:

> My thought was the original statement shouldn't be returned because the s=
erver would return the "processed" information.  IOW reflecting what it too=
k from the certificate vs. from the registration request.
>=20
> If you just echo back the certificate you aren't necessarily reflecting t=
he final state of the registration.
>=20
> I'm pretty open on this. Just want to make clear on what state we are ret=
urning (if any).
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> On 2014-02-05, at 6:11 PM, Mike Jones  wrote=
:
>=20
>> Oh, I should add that I disagree that it's not necessary to return the s=
oftware statement.  It's a key part of the client registration information,=
 and so should be returned like the other client registration information a=
ctually used.
>>=20
>> 				-- Mike
>>=20
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
>> Sent: Wednesday, February 05, 2014 6:08 PM
>> To: Phil Hunt; Eve Maler
>> Cc: oauth@ietf.org list
>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
>>=20
>> Thanks for your comments, Phil.  I'm working on addressing them at prese=
nt.
>>=20
>> One comment confuses me.  You wrote "Section 4.1 - It would be good to h=
ave an example with a software statement and no initial access token (or bo=
th)."  Yet the last example in Section 4.1 already is such as an example (t=
aken from draft-hunt-oauth-client-association, actually).  Was there someth=
ing else that you were thinking of?
>>=20
>> Also, the "Deployment Organization" definition *does* describe when it a=
nd the deployment organization are different.  Where I think that the text =
describing the choices for the two cases belongs is a subsection of the Use=
 Cases appendix.  Do you want to write text about the two cases, Phi?
>>=20
>> 				-- Mike
>>=20
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
>> Sent: Monday, February 03, 2014 12:18 PM
>> To: Eve Maler
>> Cc: oauth@ietf.org list
>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
>>=20
>> I am generally in agreement on the new drafts.  Thanks Mike!
>>=20
>> Here are some comments:
>>=20
>> In the software statement section 3:
>>> If the authorization server determines that the claims in a software =20
>>> statement uniquely identify a piece of software, the same Client ID =20
>>> value MAY be returned for all dynamic registrations using that =20
>>> software statement.
>>>=20
>>>  In some cases, authorization servers MAY choose to accept a=20
>>> software  statement value directly as a Client ID in an=20
>>> authorization request,  without a prior dynamic client registration hav=
ing been performed.
>>>  The circumstances under which an authorization server would do so, =20
>>> and the specific software statement characteristics required in this =20
>>> case, are beyond the scope of this specification.
>>>=20
>>=20
>> We should call out that the server MAY also issue per instance client_id=
's (the opposite of the first quoted paragraph above) if it chooses to use =
client_id as an instance identifier (the software_id identifies what client=
s are based on the same software).  I think this will be the typical use ca=
se. Not sure whether the first paragraph should be re-written, or a new one=
 added.
>>=20
>> Section 4.1
>> It would be good to have an example with a software statement and no ini=
tial access token (or both).
>>=20
>> Section 5.1
>> Should we also say that is not necessary to return the software statemen=
t.  Note: the server should return the meta data that was obtained from the=
 statement.
>>=20
>> Dyn-Reg-Metadata
>> The metadata document looks fine.  I would prefer it being included in d=
yn reg, but can live with it as is.
>>=20
>> Dyn-Reg-Management
>> I'd like to discuss this more in London.  I think a SCIM based managemen=
t API may be simpler to write up and can leverage the features of SCIM with=
out having to redefine them in a new API.  Still, SCIM is a way off from ap=
proval -- so I understand the need to move forward now. Is experimental the=
 right way to go?  I am not sure.
>>=20
>> Glossary
>> The terms Software API Publisher and Software API Deployer are defined b=
ut never used, Specifically the text describing the issue of when these are=
 two distinct entities is missing. When publisher and deployer are the same=
 (eg. as with Facebook), the dynamic registration need is minimal since a c=
lient_id can be issued from a single domain.  When publisher and deployer a=
re different, such as with OpenID Connect, SCIM, then the client developer =
cannot pre-register for a client_id at development time. =20
>>=20
>> The software statement is an optional mechanism that enables=20
>> developers to pre-registrater to obtain a signed statement (instead=20
>> of a client_id) so that API deployers can recognize the=20
>> pre-registration relationship with the publisher.  Of course,=20
>> software statements are optional if you don't need to be able to=20
>> recognize what the client is.  (apologies if I have not phrased the=20
>> issue optimally)
>>=20
>> Maybe if we can put in a couple of paragraphs explaining this distinctio=
n? =20
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>>=20
>>> Hi Hannes-- The UMA Core spec currently points directly to the basic dy=
namic client reg doc with MAY statements, and is agnostic as to usage of th=
e higher-order functions. (These turn into optional interop feature tests.)=
 So I think it's fair to say that the split has no structural problems from=
 an UMA perspective.
>>>=20
>>> 	Eve
>>>=20
>>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig  wrote:
>>>=20
>>>> Hi all,
>>>>=20
>>>> as you have seen from the meeting minutes of our recent status chat=20
>>>> it is time to proceed with the dynamic client registration work.
>>>>=20
>>>> The earlier version of the dynamic client registration document was=20
>>>> split into three parts, namely
>>>> (1) the current working group draft containing only minimal=20
>>>> functionality,
>>>> (2) a document describing meta-data, and
>>>> (3) a document containing management functionality.
>>>>=20
>>>> This change was made as outcome of the discussions we had more or=20
>>>> less over the last 9 months.
>>>>=20
>>>> The latter two documents are individual submissions at this point.=20
>>>> New content is not available with the recent changes. So, it is one=20
>>>> of those document management issues.
>>>>=20
>>>> I had a chat with Stephen about WG adoption of the two individual=20
>>>> submissions as WG items. It was OK for him given that it is a=20
>>>> purely document management action. However, before we turn the=20
>>>> documents into WG items we need your feedback on a number of issues:
>>>>=20
>>>> 1) Do you have concerns with the document split? Do you object or=20
>>>> approve it?
>>>> 2) Is the separation of the functionality into these three=20
>>>> documents correct? Should the line be drawn differently?
>>>> 3) Do you have comments on the documents overall?
>>>>=20
>>>> We would like to receive high-level feedback within a week. We are=20
>>>> also eager to hear from implementers and other projects using the=20
>>>> dynamic client registration work (such as OpenID Connect, UMA, the=20
>>>> BlueButton/GreenButton Initiative, etc.)
>>>>=20
>>>> For more detailed reviews please wait till we re-do the WGLC (which=20
>>>> we plan to do soon). We have to restart the WGLC due to discussions=20
>>>> last years and the resulting changes to these documents.
>>>>=20
>>>> Ciao
>>>> Hannes & Derek
>>>>=20
>>>> PS: Derek and I also think that Phil should become co-auhor of=20
>>>> these documents for his contributions.
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>> Eve Maler                                  http://www.xmlgrrl.com/blog
>>> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>>>=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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From phil.hunt@oracle.com  Thu Feb  6 10:52:15 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431211A03C0 for ; Thu,  6 Feb 2014 10:52:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.236
X-Spam-Level: 
X-Spam-Status: No, score=-4.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8Kuqt6lEolO for ; Thu,  6 Feb 2014 10:52:13 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC061A01FD for ; Thu,  6 Feb 2014 10:52:13 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s16IqABn028666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Feb 2014 18:52:11 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s16Iq9Jp026644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 18:52:10 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s16Iq92D014304; Thu, 6 Feb 2014 18:52:09 GMT
Received: from [192.168.1.124] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Feb 2014 10:52:09 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Phil Hunt 
In-Reply-To: 
Date: Thu, 6 Feb 2014 10:52:10 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <79368F1D-94CA-4CE1-98A8-572C47DF0F7C@oracle.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com> <00622740-EA6B-4C4B-9FAB-653B197BE028@oracle.com> 
To: John Bradley 
X-Mailer: Apple Mail (2.1510)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 18:52:15 -0000

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-02-06, at 10:38 AM, John Bradley  wrote:

> I think it would be echoing back the software statement  that was =
processed as part of the request for consistency.  =20

FWIW -- I don't really think anything should be returned other than the =
client_id and client creds and the location of the RESTful object =
created if available (the one accessible via the management api).

Assume you man consistency with REST.  If that is the case, then what =
the server should respond with is the processed registration (the final =
state).  I see the statement as an input to the registration profile =
that gets created. A statement is not the completed registration.  Many =
clients share the same statement, but only one registration exists per =
instance.  A registration would have all of the input values plus any =
generated data like client_id and credentails.=20

But as I said, I'm not sure why the client needs to see anything other =
than the client_id and credentials in the response other than to be =
"RESTful" in some way.


> Replying with a different software statement is going to be too =
confusing.  =20
> The entirety of the reply represents the configured state for the =
client.
>=20
> John B.
>=20
> On Feb 6, 2014, at 3:33 PM, Phil Hunt  wrote:
>=20
>> My thought was the original statement shouldn't be returned because =
the server would return the "processed" information.  IOW reflecting =
what it took from the certificate vs. from the registration request.
>>=20
>> If you just echo back the certificate you aren't necessarily =
reflecting the final state of the registration.
>>=20
>> I'm pretty open on this. Just want to make clear on what state we are =
returning (if any).
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>> On 2014-02-05, at 6:11 PM, Mike Jones  =
wrote:
>>=20
>>> Oh, I should add that I disagree that it's not necessary to return =
the software statement.  It's a key part of the client registration =
information, and so should be returned like the other client =
registration information actually used.
>>>=20
>>> 				-- Mike
>>>=20
>>> -----Original Message-----
>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
>>> Sent: Wednesday, February 05, 2014 6:08 PM
>>> To: Phil Hunt; Eve Maler
>>> Cc: oauth@ietf.org list
>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>>=20
>>> Thanks for your comments, Phil.  I'm working on addressing them at =
present.
>>>=20
>>> One comment confuses me.  You wrote "Section 4.1 - It would be good =
to have an example with a software statement and no initial access token =
(or both)."  Yet the last example in Section 4.1 already is such as an =
example (taken from draft-hunt-oauth-client-association, actually).  Was =
there something else that you were thinking of?
>>>=20
>>> Also, the "Deployment Organization" definition *does* describe when =
it and the deployment organization are different.  Where I think that =
the text describing the choices for the two cases belongs is a =
subsection of the Use Cases appendix.  Do you want to write text about =
the two cases, Phi?
>>>=20
>>> 				-- Mike
>>>=20
>>> -----Original Message-----
>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
>>> Sent: Monday, February 03, 2014 12:18 PM
>>> To: Eve Maler
>>> Cc: oauth@ietf.org list
>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>>=20
>>> I am generally in agreement on the new drafts.  Thanks Mike!
>>>=20
>>> Here are some comments:
>>>=20
>>> In the software statement section 3:
>>>> If the authorization server determines that the claims in a =
software
>>>> statement uniquely identify a piece of software, the same Client ID
>>>> value MAY be returned for all dynamic registrations using that
>>>> software statement.
>>>>=20
>>>> In some cases, authorization servers MAY choose to accept a =
software
>>>> statement value directly as a Client ID in an authorization =
request,
>>>> without a prior dynamic client registration having been performed.
>>>> The circumstances under which an authorization server would do so,
>>>> and the specific software statement characteristics required in =
this
>>>> case, are beyond the scope of this specification.
>>>>=20
>>>=20
>>> We should call out that the server MAY also issue per instance =
client_id's (the opposite of the first quoted paragraph above) if it =
chooses to use client_id as an instance identifier (the software_id =
identifies what clients are based on the same software).  I think this =
will be the typical use case. Not sure whether the first paragraph =
should be re-written, or a new one added.
>>>=20
>>> Section 4.1
>>> It would be good to have an example with a software statement and no =
initial access token (or both).
>>>=20
>>> Section 5.1
>>> Should we also say that is not necessary to return the software =
statement.  Note: the server should return the meta data that was =
obtained from the statement.
>>>=20
>>> Dyn-Reg-Metadata
>>> The metadata document looks fine.  I would prefer it being included =
in dyn reg, but can live with it as is.
>>>=20
>>> Dyn-Reg-Management
>>> I'd like to discuss this more in London.  I think a SCIM based =
management API may be simpler to write up and can leverage the features =
of SCIM without having to redefine them in a new API.  Still, SCIM is a =
way off from approval -- so I understand the need to move forward now. =
Is experimental the right way to go?  I am not sure.
>>>=20
>>> Glossary
>>> The terms Software API Publisher and Software API Deployer are =
defined but never used, Specifically the text describing the issue of =
when these are two distinct entities is missing. When publisher and =
deployer are the same (eg. as with Facebook), the dynamic registration =
need is minimal since a client_id can be issued from a single domain.  =
When publisher and deployer are different, such as with OpenID Connect, =
SCIM, then the client developer cannot pre-register for a client_id at =
development time. =20
>>>=20
>>> The software statement is an optional mechanism that enables =
developers to pre-registrater to obtain a signed statement (instead of a =
client_id) so that API deployers can recognize the pre-registration =
relationship with the publisher.  Of course, software statements are =
optional if you don't need to be able to recognize what the client is.  =
(apologies if I have not phrased the issue optimally)
>>>=20
>>> Maybe if we can put in a couple of paragraphs explaining this =
distinction? =20
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>>>=20
>>>> Hi Hannes-- The UMA Core spec currently points directly to the =
basic dynamic client reg doc with MAY statements, and is agnostic as to =
usage of the higher-order functions. (These turn into optional interop =
feature tests.) So I think it's fair to say that the split has no =
structural problems from an UMA perspective.
>>>>=20
>>>> 	Eve
>>>>=20
>>>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig =
 wrote:
>>>>=20
>>>>> Hi all,
>>>>>=20
>>>>> as you have seen from the meeting minutes of our recent status =
chat=20
>>>>> it is time to proceed with the dynamic client registration work.
>>>>>=20
>>>>> The earlier version of the dynamic client registration document =
was=20
>>>>> split into three parts, namely
>>>>> (1) the current working group draft containing only minimal=20
>>>>> functionality,
>>>>> (2) a document describing meta-data, and
>>>>> (3) a document containing management functionality.
>>>>>=20
>>>>> This change was made as outcome of the discussions we had more or=20=

>>>>> less over the last 9 months.
>>>>>=20
>>>>> The latter two documents are individual submissions at this point.=20=

>>>>> New content is not available with the recent changes. So, it is =
one=20
>>>>> of those document management issues.
>>>>>=20
>>>>> I had a chat with Stephen about WG adoption of the two individual=20=

>>>>> submissions as WG items. It was OK for him given that it is a =
purely=20
>>>>> document management action. However, before we turn the documents=20=

>>>>> into WG items we need your feedback on a number of issues:
>>>>>=20
>>>>> 1) Do you have concerns with the document split? Do you object or=20=

>>>>> approve it?
>>>>> 2) Is the separation of the functionality into these three =
documents=20
>>>>> correct? Should the line be drawn differently?
>>>>> 3) Do you have comments on the documents overall?
>>>>>=20
>>>>> We would like to receive high-level feedback within a week. We are=20=

>>>>> also eager to hear from implementers and other projects using the=20=

>>>>> dynamic client registration work (such as OpenID Connect, UMA, the=20=

>>>>> BlueButton/GreenButton Initiative, etc.)
>>>>>=20
>>>>> For more detailed reviews please wait till we re-do the WGLC =
(which=20
>>>>> we plan to do soon). We have to restart the WGLC due to =
discussions=20
>>>>> last years and the resulting changes to these documents.
>>>>>=20
>>>>> Ciao
>>>>> Hannes & Derek
>>>>>=20
>>>>> PS: Derek and I also think that Phil should become co-auhor of =
these=20
>>>>> documents for his contributions.
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>>=20
>>>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>>>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>>>=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
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


From Michael.Jones@microsoft.com  Thu Feb  6 11:04:02 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101D31A01E3 for ; Thu,  6 Feb 2014 11:04:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2qZkqOKEema for ; Thu,  6 Feb 2014 11:03:59 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id 994BF1A00EA for ; Thu,  6 Feb 2014 11:03:58 -0800 (PST)
Received: from BL2PR03MB163.namprd03.prod.outlook.com (10.255.230.147) by BL2PR03MB338.namprd03.prod.outlook.com (10.141.68.18) with Microsoft SMTP Server (TLS) id 15.0.878.16; Thu, 6 Feb 2014 19:03:56 +0000
Received: from BL2PR03CA021.namprd03.prod.outlook.com (10.141.66.29) by BL2PR03MB163.namprd03.prod.outlook.com (10.255.230.147) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 6 Feb 2014 19:03:55 +0000
Received: from BY2FFO11FD017.protection.gbl (2a01:111:f400:7c0c::187) by BL2PR03CA021.outlook.office365.com (2a01:111:e400:c1b::29) with Microsoft SMTP Server (TLS) id 15.0.868.8 via Frontend Transport; Thu, 6 Feb 2014 19:03:54 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD017.mail.protection.outlook.com (10.1.14.105) with Microsoft SMTP Server (TLS) id 15.0.856.14 via Frontend Transport; Thu, 6 Feb 2014 19:03:53 +0000
Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0174.002; Thu, 6 Feb 2014 19:03:15 +0000
From: Mike Jones 
To: Phil Hunt 
Thread-Topic: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
Thread-Index: AQHPHZrqEhtxa32Q2EGvHz/lGJszjpqeLykAgAXPnoCAA4FdEIABFuiAgAAJtkA=
Date: Thu, 6 Feb 2014 19:03:14 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739438B15A9D9@TK5EX14MBXC288.redmond.corp.microsoft.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com> <45B556F5-0D8D-45D5-8FCC-FCE45BBA71D3@oracle.com>
In-Reply-To: <45B556F5-0D8D-45D5-8FCC-FCE45BBA71D3@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(100?= =?us-ascii?Q?09001)(6009001)(51704005)(377454003)(53754006)(24454002)(377?= =?us-ascii?Q?424004)(13464003)(199002)(189002)(51444003)(53806001)(543160?= =?us-ascii?Q?02)(56776001)(86612001)(94946001)(51856001)(77096001)(498660?= =?us-ascii?Q?01)(50986001)(69226001)(54356001)(76482001)(46102001)(152023?= =?us-ascii?Q?45003)(81342001)(93516002)(50466002)(15974865002)(74366001)(?= =?us-ascii?Q?74662001)(74502001)(94316002)(86362001)(44976005)(80976001)(?= =?us-ascii?Q?6806004)(85306002)(2656002)(87266001)(93136001)(83322001)(19?= =?us-ascii?Q?580395003)(19580405001)(76796001)(47976001)(31966008)(815420?= =?us-ascii?Q?01)(47736001)(76786001)(4396001)(65816001)(80022001)(5681600?= =?us-ascii?Q?5)(63696002)(55846006)(95416001)(74706001)(66066001)(2077600?= =?us-ascii?Q?3)(46406003)(47776003)(87936001)(23726002)(90146001)(4744600?= =?us-ascii?Q?2)(81686001)(92566001)(92726001)(77982001)(59766001)(8585200?= =?us-ascii?Q?3)(74876001)(81816001)(33656001)(79102001)(15975445006)(8307?= =?us-ascii?Q?2002);DIR:OUT;SFP:1101;SCL:1;SRVR:BL2PR03MB163;H:mail.micros?= =?us-ascii?Q?oft.com;CLIP:131.107.125.37;FPR:E6FED1CC.ACF262A8.31D1F10B.8?= =?us-ascii?Q?265F941.206D9;InfoDomainNonexistentA:1;MX:1;LANG:en;?=
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0114FF88F6
X-OriginatorOrg: microsoft.com
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 19:04:02 -0000

I'd actually already noticed that the term "software assertion" was present=
 in some of the text that I inherited and replaced it with "software statem=
ent". :-)

-----Original Message-----
From: Phil Hunt [mailto:phil.hunt@oracle.com]=20
Sent: Thursday, February 06, 2014 10:28 AM
To: Mike Jones
Cc: Eve Maler; oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!


Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-02-05, at 6:08 PM, Mike Jones  wrote:

> Thanks for your comments, Phil.  I'm working on addressing them at presen=
t.
>=20
> One comment confuses me.  You wrote "Section 4.1 - It would be good to ha=
ve an example with a software statement and no initial access token (or bot=
h)."  Yet the last example in Section 4.1 already is such as an example (ta=
ken from draft-hunt-oauth-client-association, actually).  Was there somethi=
ng else that you were thinking of?
[PH[  My bad. It is the last example on the next page.  Thanks.
>=20
> Also, the "Deployment Organization" definition *does* describe when it an=
d the deployment organization are different.  Where I think that the text d=
escribing the choices for the two cases belongs is a subsection of the Use =
Cases appendix.  Do you want to write text about the two cases, Phi?
[PH] In the interest of keeping it short. I think I can live with it. =20

I notice the term "software assertion" has crept in. While technically true=
, I was avoiding use of the word "assertion" because the purpose is to make=
 statements (claims) about the profile of the software rather than trying t=
o prove that the client is the software.

>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
> Sent: Monday, February 03, 2014 12:18 PM
> To: Eve Maler
> Cc: oauth@ietf.org list
> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
>=20
> I am generally in agreement on the new drafts.  Thanks Mike!
>=20
> Here are some comments:
>=20
> In the software statement section 3:
>> If the authorization server determines that the claims in a software
>>   statement uniquely identify a piece of software, the same Client ID
>>   value MAY be returned for all dynamic registrations using that
>>   software statement.
>>=20
>>   In some cases, authorization servers MAY choose to accept a software
>>   statement value directly as a Client ID in an authorization request,
>>   without a prior dynamic client registration having been performed.
>>   The circumstances under which an authorization server would do so,
>>   and the specific software statement characteristics required in this
>>   case, are beyond the scope of this specification.
>>=20
>=20
> We should call out that the server MAY also issue per instance client_id'=
s (the opposite of the first quoted paragraph above) if it chooses to use c=
lient_id as an instance identifier (the software_id identifies what clients=
 are based on the same software).  I think this will be the typical use cas=
e. Not sure whether the first paragraph should be re-written, or a new one =
added.
>=20
> Section 4.1
> It would be good to have an example with a software statement and no init=
ial access token (or both).
>=20
> Section 5.1
> Should we also say that is not necessary to return the software statement=
.  Note: the server should return the meta data that was obtained from the =
statement.
>=20
> Dyn-Reg-Metadata
> The metadata document looks fine.  I would prefer it being included in dy=
n reg, but can live with it as is.
>=20
> Dyn-Reg-Management
> I'd like to discuss this more in London.  I think a SCIM based management=
 API may be simpler to write up and can leverage the features of SCIM witho=
ut having to redefine them in a new API.  Still, SCIM is a way off from app=
roval -- so I understand the need to move forward now. Is experimental the =
right way to go?  I am not sure.
>=20
> Glossary
> The terms Software API Publisher and Software API Deployer are defined bu=
t never used, Specifically the text describing the issue of when these are =
two distinct entities is missing. When publisher and deployer are the same =
(eg. as with Facebook), the dynamic registration need is minimal since a cl=
ient_id can be issued from a single domain.  When publisher and deployer ar=
e different, such as with OpenID Connect, SCIM, then the client developer c=
annot pre-register for a client_id at development time. =20
>=20
> The software statement is an optional mechanism that enables=20
> developers to pre-registrater to obtain a signed statement (instead of=20
> a client_id) so that API deployers can recognize the pre-registration=20
> relationship with the publisher.  Of course, software statements are=20
> optional if you don't need to be able to recognize what the client is. =20
> (apologies if I have not phrased the issue optimally)
>=20
> Maybe if we can put in a couple of paragraphs explaining this distinction=
? =20
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>=20
>> Hi Hannes-- The UMA Core spec currently points directly to the basic dyn=
amic client reg doc with MAY statements, and is agnostic as to usage of the=
 higher-order functions. (These turn into optional interop feature tests.) =
So I think it's fair to say that the split has no structural problems from =
an UMA perspective.
>>=20
>> 	Eve
>>=20
>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig  wrote:
>>=20
>>> Hi all,
>>>=20
>>> as you have seen from the meeting minutes of our recent status chat=20
>>> it is time to proceed with the dynamic client registration work.
>>>=20
>>> The earlier version of the dynamic client registration document was=20
>>> split into three parts, namely
>>> (1) the current working group draft containing only minimal=20
>>> functionality,
>>> (2) a document describing meta-data, and
>>> (3) a document containing management functionality.
>>>=20
>>> This change was made as outcome of the discussions we had more or=20
>>> less over the last 9 months.
>>>=20
>>> The latter two documents are individual submissions at this point.=20
>>> New content is not available with the recent changes. So, it is one=20
>>> of those document management issues.
>>>=20
>>> I had a chat with Stephen about WG adoption of the two individual=20
>>> submissions as WG items. It was OK for him given that it is a purely=20
>>> document management action. However, before we turn the documents=20
>>> into WG items we need your feedback on a number of issues:
>>>=20
>>> 1) Do you have concerns with the document split? Do you object or=20
>>> approve it?
>>> 2) Is the separation of the functionality into these three documents=20
>>> correct? Should the line be drawn differently?
>>> 3) Do you have comments on the documents overall?
>>>=20
>>> We would like to receive high-level feedback within a week. We are=20
>>> also eager to hear from implementers and other projects using the=20
>>> dynamic client registration work (such as OpenID Connect, UMA, the=20
>>> BlueButton/GreenButton Initiative, etc.)
>>>=20
>>> For more detailed reviews please wait till we re-do the WGLC (which=20
>>> we plan to do soon). We have to restart the WGLC due to discussions=20
>>> last years and the resulting changes to these documents.
>>>=20
>>> Ciao
>>> Hannes & Derek
>>>=20
>>> PS: Derek and I also think that Phil should become co-auhor of these=20
>>> documents for his contributions.
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> Eve Maler                                  http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>>=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 ve7jtb@ve7jtb.com  Thu Feb  6 11:08:05 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6241A01E3 for ; Thu,  6 Feb 2014 11:08:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3cHemfMuYb7 for ; Thu,  6 Feb 2014 11:08:02 -0800 (PST)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6521C1A00C9 for ; Thu,  6 Feb 2014 11:08:02 -0800 (PST)
Received: by mail-qc0-f171.google.com with SMTP id n7so3958208qcx.16 for ; Thu, 06 Feb 2014 11:08:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=y14ljJD4X4MidrjSU3v5GD4PLbHliQQ/tQOPxVG1mlo=; b=X0hL/sE0MKln6pfxQf1IEDuMW6GjQ8QigrQwH9z5n8ej9DMwCciRh2oKd18KSY7Phm pEDif2HeHrWQwD1L7krleEOdt+HI7RMoOI7CfzCbzEW0U9RUMl1frbWRRrcIgeDjeRT8 0D/gHhbXr0WC0L7rHwXv6HNXxcEYc7tzPctrpZuANl5gunYNLdgQ1Rkc7Us80ydXRED+ 3sCeql0lZFk+nwMWyWtzbaiwyeaGbffL8ynJfap2TmtvELddD7tcA1lDZdYel7QN9QTR SeyIOaA0KbEk1Un+Oao2N4d5VvuzjC3W3dZojLjcG3BXqXaESmnlPMdGPHklgzUJnq1M 1HAQ==
X-Gm-Message-State: ALoCoQkzVhrgYYmIpccc51PTIqcowdxKczW9VgOgNINnCyIjHnflbSyrlO4dAAMx9PCt9wgLZN+A
X-Received: by 10.140.18.142 with SMTP id 14mr14120682qgf.105.1391713680970; Thu, 06 Feb 2014 11:08:00 -0800 (PST)
Received: from [192.168.0.200] ([201.189.102.146]) by mx.google.com with ESMTPSA id 3sm5059427qan.15.2014.02.06.11.07.57 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 11:07:59 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_4DE5C576-3E8E-407F-8727-7E17ED1769ED"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley 
In-Reply-To: <79368F1D-94CA-4CE1-98A8-572C47DF0F7C@oracle.com>
Date: Thu, 6 Feb 2014 16:07:50 -0300
Message-Id: <48348E60-C9BC-46CC-BB41-DAA51BEDFC0F@ve7jtb.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com> <00622740-EA6B-4C4B-9FAB-653B197BE028@oracle.com>  <79368F1D-94CA-4CE1-98A8-572C47DF0F7C@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.1827)
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 19:08:05 -0000

--Apple-Mail=_4DE5C576-3E8E-407F-8727-7E17ED1769ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Telling the client the state of it's configuration is useful to the =
client if the server "makes right".

I think Tony is arguing for the server putting the entire response into =
the software statement element in the response.  Where at the moment the =
spec provides those elements at the top level of the JSON object along =
with client_id etc.

My question for Tony is if he is thinking that the made right software =
statement in the response would be signed by the AS as opposed to the =
original that was signed by the Software publisher, and if so what is =
the client going to do with it?

John B.

On Feb 6, 2014, at 3:52 PM, Phil Hunt  wrote:

>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> On 2014-02-06, at 10:38 AM, John Bradley  wrote:
>=20
>> I think it would be echoing back the software statement  that was =
processed as part of the request for consistency.  =20
>=20
> FWIW -- I don't really think anything should be returned other than =
the client_id and client creds and the location of the RESTful object =
created if available (the one accessible via the management api).
>=20
> Assume you man consistency with REST.  If that is the case, then what =
the server should respond with is the processed registration (the final =
state).  I see the statement as an input to the registration profile =
that gets created. A statement is not the completed registration.  Many =
clients share the same statement, but only one registration exists per =
instance.  A registration would have all of the input values plus any =
generated data like client_id and credentails.=20
>=20
> But as I said, I'm not sure why the client needs to see anything other =
than the client_id and credentials in the response other than to be =
"RESTful" in some way.
>=20
>=20
>> Replying with a different software statement is going to be too =
confusing.  =20
>> The entirety of the reply represents the configured state for the =
client.
>>=20
>> John B.
>>=20
>> On Feb 6, 2014, at 3:33 PM, Phil Hunt  wrote:
>>=20
>>> My thought was the original statement shouldn't be returned because =
the server would return the "processed" information.  IOW reflecting =
what it took from the certificate vs. from the registration request.
>>>=20
>>> If you just echo back the certificate you aren't necessarily =
reflecting the final state of the registration.
>>>=20
>>> I'm pretty open on this. Just want to make clear on what state we =
are returning (if any).
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>> On 2014-02-05, at 6:11 PM, Mike Jones  =
wrote:
>>>=20
>>>> Oh, I should add that I disagree that it's not necessary to return =
the software statement.  It's a key part of the client registration =
information, and so should be returned like the other client =
registration information actually used.
>>>>=20
>>>> 				-- Mike
>>>>=20
>>>> -----Original Message-----
>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
>>>> Sent: Wednesday, February 05, 2014 6:08 PM
>>>> To: Phil Hunt; Eve Maler
>>>> Cc: oauth@ietf.org list
>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>>>=20
>>>> Thanks for your comments, Phil.  I'm working on addressing them at =
present.
>>>>=20
>>>> One comment confuses me.  You wrote "Section 4.1 - It would be good =
to have an example with a software statement and no initial access token =
(or both)."  Yet the last example in Section 4.1 already is such as an =
example (taken from draft-hunt-oauth-client-association, actually).  Was =
there something else that you were thinking of?
>>>>=20
>>>> Also, the "Deployment Organization" definition *does* describe when =
it and the deployment organization are different.  Where I think that =
the text describing the choices for the two cases belongs is a =
subsection of the Use Cases appendix.  Do you want to write text about =
the two cases, Phi?
>>>>=20
>>>> 				-- Mike
>>>>=20
>>>> -----Original Message-----
>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
>>>> Sent: Monday, February 03, 2014 12:18 PM
>>>> To: Eve Maler
>>>> Cc: oauth@ietf.org list
>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>>>=20
>>>> I am generally in agreement on the new drafts.  Thanks Mike!
>>>>=20
>>>> Here are some comments:
>>>>=20
>>>> In the software statement section 3:
>>>>> If the authorization server determines that the claims in a =
software
>>>>> statement uniquely identify a piece of software, the same Client =
ID
>>>>> value MAY be returned for all dynamic registrations using that
>>>>> software statement.
>>>>>=20
>>>>> In some cases, authorization servers MAY choose to accept a =
software
>>>>> statement value directly as a Client ID in an authorization =
request,
>>>>> without a prior dynamic client registration having been performed.
>>>>> The circumstances under which an authorization server would do so,
>>>>> and the specific software statement characteristics required in =
this
>>>>> case, are beyond the scope of this specification.
>>>>>=20
>>>>=20
>>>> We should call out that the server MAY also issue per instance =
client_id's (the opposite of the first quoted paragraph above) if it =
chooses to use client_id as an instance identifier (the software_id =
identifies what clients are based on the same software).  I think this =
will be the typical use case. Not sure whether the first paragraph =
should be re-written, or a new one added.
>>>>=20
>>>> Section 4.1
>>>> It would be good to have an example with a software statement and =
no initial access token (or both).
>>>>=20
>>>> Section 5.1
>>>> Should we also say that is not necessary to return the software =
statement.  Note: the server should return the meta data that was =
obtained from the statement.
>>>>=20
>>>> Dyn-Reg-Metadata
>>>> The metadata document looks fine.  I would prefer it being included =
in dyn reg, but can live with it as is.
>>>>=20
>>>> Dyn-Reg-Management
>>>> I'd like to discuss this more in London.  I think a SCIM based =
management API may be simpler to write up and can leverage the features =
of SCIM without having to redefine them in a new API.  Still, SCIM is a =
way off from approval -- so I understand the need to move forward now. =
Is experimental the right way to go?  I am not sure.
>>>>=20
>>>> Glossary
>>>> The terms Software API Publisher and Software API Deployer are =
defined but never used, Specifically the text describing the issue of =
when these are two distinct entities is missing. When publisher and =
deployer are the same (eg. as with Facebook), the dynamic registration =
need is minimal since a client_id can be issued from a single domain.  =
When publisher and deployer are different, such as with OpenID Connect, =
SCIM, then the client developer cannot pre-register for a client_id at =
development time. =20
>>>>=20
>>>> The software statement is an optional mechanism that enables =
developers to pre-registrater to obtain a signed statement (instead of a =
client_id) so that API deployers can recognize the pre-registration =
relationship with the publisher.  Of course, software statements are =
optional if you don't need to be able to recognize what the client is.  =
(apologies if I have not phrased the issue optimally)
>>>>=20
>>>> Maybe if we can put in a couple of paragraphs explaining this =
distinction? =20
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>>>>=20
>>>>> Hi Hannes-- The UMA Core spec currently points directly to the =
basic dynamic client reg doc with MAY statements, and is agnostic as to =
usage of the higher-order functions. (These turn into optional interop =
feature tests.) So I think it's fair to say that the split has no =
structural problems from an UMA perspective.
>>>>>=20
>>>>> 	Eve
>>>>>=20
>>>>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig =
 wrote:
>>>>>=20
>>>>>> Hi all,
>>>>>>=20
>>>>>> as you have seen from the meeting minutes of our recent status =
chat=20
>>>>>> it is time to proceed with the dynamic client registration work.
>>>>>>=20
>>>>>> The earlier version of the dynamic client registration document =
was=20
>>>>>> split into three parts, namely
>>>>>> (1) the current working group draft containing only minimal=20
>>>>>> functionality,
>>>>>> (2) a document describing meta-data, and
>>>>>> (3) a document containing management functionality.
>>>>>>=20
>>>>>> This change was made as outcome of the discussions we had more or=20=

>>>>>> less over the last 9 months.
>>>>>>=20
>>>>>> The latter two documents are individual submissions at this =
point.=20
>>>>>> New content is not available with the recent changes. So, it is =
one=20
>>>>>> of those document management issues.
>>>>>>=20
>>>>>> I had a chat with Stephen about WG adoption of the two individual=20=

>>>>>> submissions as WG items. It was OK for him given that it is a =
purely=20
>>>>>> document management action. However, before we turn the documents=20=

>>>>>> into WG items we need your feedback on a number of issues:
>>>>>>=20
>>>>>> 1) Do you have concerns with the document split? Do you object or=20=

>>>>>> approve it?
>>>>>> 2) Is the separation of the functionality into these three =
documents=20
>>>>>> correct? Should the line be drawn differently?
>>>>>> 3) Do you have comments on the documents overall?
>>>>>>=20
>>>>>> We would like to receive high-level feedback within a week. We =
are=20
>>>>>> also eager to hear from implementers and other projects using the=20=

>>>>>> dynamic client registration work (such as OpenID Connect, UMA, =
the=20
>>>>>> BlueButton/GreenButton Initiative, etc.)
>>>>>>=20
>>>>>> For more detailed reviews please wait till we re-do the WGLC =
(which=20
>>>>>> we plan to do soon). We have to restart the WGLC due to =
discussions=20
>>>>>> last years and the resulting changes to these documents.
>>>>>>=20
>>>>>> Ciao
>>>>>> Hannes & Derek
>>>>>>=20
>>>>>> PS: Derek and I also think that Phil should become co-auhor of =
these=20
>>>>>> documents for his contributions.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>>=20
>>>>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>>>>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>>>>=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
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20


--Apple-Mail=_4DE5C576-3E8E-407F-8727-7E17ED1769ED
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA2MTkwNzUxWjAjBgkqhkiG9w0BCQQxFgQUXz+mhmzU
rYUX/SCVq1h1e1xmO5gwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAOfSZOyiu19wXxbljhUVHP7IfV8SP+mDKmCwsufgE
8UyhuTOctqiPO/dsmhtmDMZIRmjbDDzF/lkrKwkQu5c38bLIgORl3sLAHOqrApllhtxWoJx/t8sm
m1/E5wSP/wE9FfkyH7Kdg5C7fSyx+vzOKyB3VDYmXzAusHApdUtbrplj3Pcjq1j4J2QuWGvaGJ/u
caEdqG4bau/qd5dyPp5bOXNJZubxd9zvwzL9oGqsqdi87G+Dd0BtJWQgSCM9ihlCK989PpULFPS1
XjHQAuHW92QZ3qz+Pe4KGdGdJbneMpHuZ0UztzNrZbo6+J0uuk+9NdoBCz15N4oHmw5/CY7OHgAA
AAAAAA==

--Apple-Mail=_4DE5C576-3E8E-407F-8727-7E17ED1769ED--

From Michael.Jones@microsoft.com  Thu Feb  6 11:17:58 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8601A0452 for ; Thu,  6 Feb 2014 11:17:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bftWcdQKEOZa for ; Thu,  6 Feb 2014 11:17:55 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id C2F4B1A0428 for ; Thu,  6 Feb 2014 11:17:54 -0800 (PST)
Received: from BLUPR03CA029.namprd03.prod.outlook.com (10.141.30.22) by BLUPR03MB003.namprd03.prod.outlook.com (10.255.208.37) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 19:17:52 +0000
Received: from BL2FFO11FD053.protection.gbl (2a01:111:f400:7c09::120) by BLUPR03CA029.outlook.office365.com (2a01:111:e400:879::22) with Microsoft SMTP Server (TLS) id 15.0.868.8 via Frontend Transport; Thu, 6 Feb 2014 19:17:50 +0000
Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD053.mail.protection.outlook.com (10.173.161.181) with Microsoft SMTP Server (TLS) id 15.0.856.14 via Frontend Transport; Thu, 6 Feb 2014 19:17:49 +0000
Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0174.002; Thu, 6 Feb 2014 19:17:14 +0000
From: Mike Jones 
To: John Bradley , Phil Hunt 
Thread-Topic: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
Thread-Index: AQHPHZrqEhtxa32Q2EGvHz/lGJszjpqeLykAgAXPnoCAA4FdEIAABdPAgAESzQCAAAFlAIAAA7UAgAAEYQCAAAJbUA==
Date: Thu, 6 Feb 2014 19:17:13 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739438B15AAB2@TK5EX14MBXC288.redmond.corp.microsoft.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com> <00622740-EA6B-4C4B-9FAB-653B197BE028@oracle.com>  <79368F1D-94CA-4CE1-98A8-572C47DF0F7C@oracle.com> <48348E60-C9BC-46CC-BB41-DAA51BEDFC0F@ve7jtb.com>
In-Reply-To: <48348E60-C9BC-46CC-BB41-DAA51BEDFC0F@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(100?= =?us-ascii?Q?09001)(6009001)(51444003)(377454003)(189002)(199002)(5375400?= =?us-ascii?Q?6)(51704005)(24454002)(13464003)(50854003)(377424004)(449760?= =?us-ascii?Q?05)(54316002)(6806004)(79102001)(74876001)(80976001)(8530600?= =?us-ascii?Q?2)(19580405001)(87936001)(92566001)(83322001)(20776003)(1597?= =?us-ascii?Q?4865002)(55846006)(86362001)(59766001)(74706001)(46102001)(4?= =?us-ascii?Q?7776003)(19580395003)(15202345003)(94946001)(47446002)(33656?= =?us-ascii?Q?001)(56776001)(81542001)(93136001)(95416001)(92726001)(43960?= =?us-ascii?Q?01)(93516002)(86612001)(74662001)(47976001)(74502001)(518560?= =?us-ascii?Q?01)(66066001)(77096001)(81342001)(47736001)(56816005)(767860?= =?us-ascii?Q?01)(53806001)(76482001)(31966008)(2656002)(87266001)(9014600?= =?us-ascii?Q?1)(15975445006)(54356001)(46406003)(74366001)(94316002)(7798?= =?us-ascii?Q?2001)(50986001)(49866001)(23726002)(63696002)(69226001)(8585?= =?us-ascii?Q?2003)(65816001)(50466002)(81816001)(83072002)(81686001)(7679?= =?us-ascii?Q?6001)(80022001);DIR:OUT;SFP:1101;SCL:1;SRVR:BLUPR03MB003;H:m?= =?us-ascii?Q?ail.microsoft.com;CLIP:131.107.125.37;FPR:E6FED1CC.ACF26280.?= =?us-ascii?Q?32D3F10B.8264F941.207B2;InfoDomainNonexistentMX:1;A:1;LANG:e?= =?us-ascii?Q?n;?=
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0114FF88F6
X-OriginatorOrg: microsoft.com
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 19:17:58 -0000

I just spoke to Tony about this in person and to Phil about it on the phone=
.  We're all good with having the server return the actual values used in t=
he registration (which is what the spec already does).

				-- Mike

-----Original Message-----
From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
Sent: Thursday, February 06, 2014 11:08 AM
To: Phil Hunt
Cc: Mike Jones; oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

Telling the client the state of it's configuration is useful to the client =
if the server "makes right".

I think Tony is arguing for the server putting the entire response into the=
 software statement element in the response.  Where at the moment the spec =
provides those elements at the top level of the JSON object along with clie=
nt_id etc.

My question for Tony is if he is thinking that the made right software stat=
ement in the response would be signed by the AS as opposed to the original =
that was signed by the Software publisher, and if so what is the client goi=
ng to do with it?

John B.

On Feb 6, 2014, at 3:52 PM, Phil Hunt  wrote:

>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> On 2014-02-06, at 10:38 AM, John Bradley  wrote:
>=20
>> I think it would be echoing back the software statement  that was proces=
sed as part of the request for consistency.  =20
>=20
> FWIW -- I don't really think anything should be returned other than the c=
lient_id and client creds and the location of the RESTful object created if=
 available (the one accessible via the management api).
>=20
> Assume you man consistency with REST.  If that is the case, then what the=
 server should respond with is the processed registration (the final state)=
.  I see the statement as an input to the registration profile that gets cr=
eated. A statement is not the completed registration.  Many clients share t=
he same statement, but only one registration exists per instance.  A regist=
ration would have all of the input values plus any generated data like clie=
nt_id and credentails.=20
>=20
> But as I said, I'm not sure why the client needs to see anything other th=
an the client_id and credentials in the response other than to be "RESTful"=
 in some way.
>=20
>=20
>> Replying with a different software statement is going to be too confusin=
g.  =20
>> The entirety of the reply represents the configured state for the client=
.
>>=20
>> John B.
>>=20
>> On Feb 6, 2014, at 3:33 PM, Phil Hunt  wrote:
>>=20
>>> My thought was the original statement shouldn't be returned because the=
 server would return the "processed" information.  IOW reflecting what it t=
ook from the certificate vs. from the registration request.
>>>=20
>>> If you just echo back the certificate you aren't necessarily reflecting=
 the final state of the registration.
>>>=20
>>> I'm pretty open on this. Just want to make clear on what state we are r=
eturning (if any).
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>> On 2014-02-05, at 6:11 PM, Mike Jones  wro=
te:
>>>=20
>>>> Oh, I should add that I disagree that it's not necessary to return the=
 software statement.  It's a key part of the client registration informatio=
n, and so should be returned like the other client registration information=
 actually used.
>>>>=20
>>>> 				-- Mike
>>>>=20
>>>> -----Original Message-----
>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
>>>> Sent: Wednesday, February 05, 2014 6:08 PM
>>>> To: Phil Hunt; Eve Maler
>>>> Cc: oauth@ietf.org list
>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Neede=
d!
>>>>=20
>>>> Thanks for your comments, Phil.  I'm working on addressing them at pre=
sent.
>>>>=20
>>>> One comment confuses me.  You wrote "Section 4.1 - It would be good to=
 have an example with a software statement and no initial access token (or =
both)."  Yet the last example in Section 4.1 already is such as an example =
(taken from draft-hunt-oauth-client-association, actually).  Was there some=
thing else that you were thinking of?
>>>>=20
>>>> Also, the "Deployment Organization" definition *does* describe when it=
 and the deployment organization are different.  Where I think that the tex=
t describing the choices for the two cases belongs is a subsection of the U=
se Cases appendix.  Do you want to write text about the two cases, Phi?
>>>>=20
>>>> 				-- Mike
>>>>=20
>>>> -----Original Message-----
>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
>>>> Sent: Monday, February 03, 2014 12:18 PM
>>>> To: Eve Maler
>>>> Cc: oauth@ietf.org list
>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Neede=
d!
>>>>=20
>>>> I am generally in agreement on the new drafts.  Thanks Mike!
>>>>=20
>>>> Here are some comments:
>>>>=20
>>>> In the software statement section 3:
>>>>> If the authorization server determines that the claims in a software
>>>>> statement uniquely identify a piece of software, the same Client ID
>>>>> value MAY be returned for all dynamic registrations using that
>>>>> software statement.
>>>>>=20
>>>>> In some cases, authorization servers MAY choose to accept a software
>>>>> statement value directly as a Client ID in an authorization request,
>>>>> without a prior dynamic client registration having been performed.
>>>>> The circumstances under which an authorization server would do so,
>>>>> and the specific software statement characteristics required in this
>>>>> case, are beyond the scope of this specification.
>>>>>=20
>>>>=20
>>>> We should call out that the server MAY also issue per instance client_=
id's (the opposite of the first quoted paragraph above) if it chooses to us=
e client_id as an instance identifier (the software_id identifies what clie=
nts are based on the same software).  I think this will be the typical use =
case. Not sure whether the first paragraph should be re-written, or a new o=
ne added.
>>>>=20
>>>> Section 4.1
>>>> It would be good to have an example with a software statement and no i=
nitial access token (or both).
>>>>=20
>>>> Section 5.1
>>>> Should we also say that is not necessary to return the software statem=
ent.  Note: the server should return the meta data that was obtained from t=
he statement.
>>>>=20
>>>> Dyn-Reg-Metadata
>>>> The metadata document looks fine.  I would prefer it being included in=
 dyn reg, but can live with it as is.
>>>>=20
>>>> Dyn-Reg-Management
>>>> I'd like to discuss this more in London.  I think a SCIM based managem=
ent API may be simpler to write up and can leverage the features of SCIM wi=
thout having to redefine them in a new API.  Still, SCIM is a way off from =
approval -- so I understand the need to move forward now. Is experimental t=
he right way to go?  I am not sure.
>>>>=20
>>>> Glossary
>>>> The terms Software API Publisher and Software API Deployer are defined=
 but never used, Specifically the text describing the issue of when these a=
re two distinct entities is missing. When publisher and deployer are the sa=
me (eg. as with Facebook), the dynamic registration need is minimal since a=
 client_id can be issued from a single domain.  When publisher and deployer=
 are different, such as with OpenID Connect, SCIM, then the client develope=
r cannot pre-register for a client_id at development time. =20
>>>>=20
>>>> The software statement is an optional mechanism that enables developer=
s to pre-registrater to obtain a signed statement (instead of a client_id) =
so that API deployers can recognize the pre-registration relationship with =
the publisher.  Of course, software statements are optional if you don't ne=
ed to be able to recognize what the client is.  (apologies if I have not ph=
rased the issue optimally)
>>>>=20
>>>> Maybe if we can put in a couple of paragraphs explaining this distinct=
ion? =20
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>>>>=20
>>>>> Hi Hannes-- The UMA Core spec currently points directly to the basic =
dynamic client reg doc with MAY statements, and is agnostic as to usage of =
the higher-order functions. (These turn into optional interop feature tests=
.) So I think it's fair to say that the split has no structural problems fr=
om an UMA perspective.
>>>>>=20
>>>>> 	Eve
>>>>>=20
>>>>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig  wrote:
>>>>>=20
>>>>>> Hi all,
>>>>>>=20
>>>>>> as you have seen from the meeting minutes of our recent status chat=
=20
>>>>>> it is time to proceed with the dynamic client registration work.
>>>>>>=20
>>>>>> The earlier version of the dynamic client registration document was=
=20
>>>>>> split into three parts, namely
>>>>>> (1) the current working group draft containing only minimal=20
>>>>>> functionality,
>>>>>> (2) a document describing meta-data, and
>>>>>> (3) a document containing management functionality.
>>>>>>=20
>>>>>> This change was made as outcome of the discussions we had more or=20
>>>>>> less over the last 9 months.
>>>>>>=20
>>>>>> The latter two documents are individual submissions at this point.=20
>>>>>> New content is not available with the recent changes. So, it is one=
=20
>>>>>> of those document management issues.
>>>>>>=20
>>>>>> I had a chat with Stephen about WG adoption of the two individual=20
>>>>>> submissions as WG items. It was OK for him given that it is a purely=
=20
>>>>>> document management action. However, before we turn the documents=20
>>>>>> into WG items we need your feedback on a number of issues:
>>>>>>=20
>>>>>> 1) Do you have concerns with the document split? Do you object or=20
>>>>>> approve it?
>>>>>> 2) Is the separation of the functionality into these three documents=
=20
>>>>>> correct? Should the line be drawn differently?
>>>>>> 3) Do you have comments on the documents overall?
>>>>>>=20
>>>>>> We would like to receive high-level feedback within a week. We are=20
>>>>>> also eager to hear from implementers and other projects using the=20
>>>>>> dynamic client registration work (such as OpenID Connect, UMA, the=20
>>>>>> BlueButton/GreenButton Initiative, etc.)
>>>>>>=20
>>>>>> For more detailed reviews please wait till we re-do the WGLC (which=
=20
>>>>>> we plan to do soon). We have to restart the WGLC due to discussions=
=20
>>>>>> last years and the resulting changes to these documents.
>>>>>>=20
>>>>>> Ciao
>>>>>> Hannes & Derek
>>>>>>=20
>>>>>> PS: Derek and I also think that Phil should become co-auhor of these=
=20
>>>>>> documents for his contributions.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>>=20
>>>>> Eve Maler                                  http://www.xmlgrrl.com/blo=
g
>>>>> +1 425 345 6756                         http://www.twitter.com/xmlgrr=
l
>>>>>=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
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20


From ve7jtb@ve7jtb.com  Thu Feb  6 11:34:38 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E1B1A03F9 for ; Thu,  6 Feb 2014 11:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bWE5TBiQqI3 for ; Thu,  6 Feb 2014 11:34:34 -0800 (PST)
Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 88C5C1A0473 for ; Thu,  6 Feb 2014 11:34:34 -0800 (PST)
Received: by mail-qa0-f43.google.com with SMTP id o15so3614435qap.30 for ; Thu, 06 Feb 2014 11:34:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Hc/iYLq6o7IxKXEVrjX8e6H9GAMrlcccbbZxqLa6B54=; b=BM9gXBFFJaDlQPGpe62Ka8vcunavxAK55IJso3mZU30+2I16XZ1lAqMctA5zGB77zd 0quLhOdjyhBhYMJDgbfvzv9Rvtcr3hTZVknTkb2Er+kUGL37ne5KkXzdCzYzrU1ApMW+ BAPyVF449M4kxWPVxpEXr5BW7t5yaasqmZu6XKmW6LJ1KMbwjbXajQDCeJ+gaftS0KdR +U4IEelzOKJMljrq6kKiAI273scL9bSVdIPNc8tgk7CfU2GAEZequathtwBoG/3GFFht s8JhUsk36ue1BrsAx7Ndc8Tv0R1kykFEbACte9bDWKmCDOBb5cVgKEzzpT+h9FZeDq9n p4vg==
X-Gm-Message-State: ALoCoQlHoszaYQHwKZ7ASb+2EJjmFI/MnXW1S9n0NgoRszrFkR1aCO7sO1G9mH8qSGGe0b9Kg4uj
X-Received: by 10.224.134.196 with SMTP id k4mr15137295qat.22.1391715273023; Thu, 06 Feb 2014 11:34:33 -0800 (PST)
Received: from [192.168.0.200] ([201.189.102.146]) by mx.google.com with ESMTPSA id v3sm5301477qap.4.2014.02.06.11.34.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 11:34:31 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_FEB30C5B-2085-4B3B-879D-CBFF4F74CD6F"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley 
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B15AAB2@TK5EX14MBXC288.redmond.corp.microsoft.com>
Date: Thu, 6 Feb 2014 16:34:25 -0300
Message-Id: <6C55A411-C8C5-4680-8B73-02B3B5F65798@ve7jtb.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com> <00622740-EA6B-4C4B-9FAB-653B197BE028@oracle.com>  <79368F1D-94CA-4CE1-98A8-572C47DF0F7C@oracle.com> <48348E60-C9BC-46CC-BB41-DAA51BEDFC0F@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739438B15AAB2@TK5EX14MBXC288.redmond.corp.microsoft.com>
To: Michael Jones 
X-Mailer: Apple Mail (2.1827)
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 19:34:38 -0000

--Apple-Mail=_FEB30C5B-2085-4B3B-879D-CBFF4F74CD6F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

OK

On Feb 6, 2014, at 4:17 PM, Mike Jones  =
wrote:

> I just spoke to Tony about this in person and to Phil about it on the =
phone.  We're all good with having the server return the actual values =
used in the registration (which is what the spec already does).
>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Thursday, February 06, 2014 11:08 AM
> To: Phil Hunt
> Cc: Mike Jones; oauth@ietf.org list
> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>=20
> Telling the client the state of it's configuration is useful to the =
client if the server "makes right".
>=20
> I think Tony is arguing for the server putting the entire response =
into the software statement element in the response.  Where at the =
moment the spec provides those elements at the top level of the JSON =
object along with client_id etc.
>=20
> My question for Tony is if he is thinking that the made right software =
statement in the response would be signed by the AS as opposed to the =
original that was signed by the Software publisher, and if so what is =
the client going to do with it?
>=20
> John B.
>=20
> On Feb 6, 2014, at 3:52 PM, Phil Hunt  wrote:
>=20
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>> On 2014-02-06, at 10:38 AM, John Bradley  wrote:
>>=20
>>> I think it would be echoing back the software statement  that was =
processed as part of the request for consistency.  =20
>>=20
>> FWIW -- I don't really think anything should be returned other than =
the client_id and client creds and the location of the RESTful object =
created if available (the one accessible via the management api).
>>=20
>> Assume you man consistency with REST.  If that is the case, then what =
the server should respond with is the processed registration (the final =
state).  I see the statement as an input to the registration profile =
that gets created. A statement is not the completed registration.  Many =
clients share the same statement, but only one registration exists per =
instance.  A registration would have all of the input values plus any =
generated data like client_id and credentails.=20
>>=20
>> But as I said, I'm not sure why the client needs to see anything =
other than the client_id and credentials in the response other than to =
be "RESTful" in some way.
>>=20
>>=20
>>> Replying with a different software statement is going to be too =
confusing.  =20
>>> The entirety of the reply represents the configured state for the =
client.
>>>=20
>>> John B.
>>>=20
>>> On Feb 6, 2014, at 3:33 PM, Phil Hunt  wrote:
>>>=20
>>>> My thought was the original statement shouldn't be returned because =
the server would return the "processed" information.  IOW reflecting =
what it took from the certificate vs. from the registration request.
>>>>=20
>>>> If you just echo back the certificate you aren't necessarily =
reflecting the final state of the registration.
>>>>=20
>>>> I'm pretty open on this. Just want to make clear on what state we =
are returning (if any).
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>> On 2014-02-05, at 6:11 PM, Mike Jones  =
wrote:
>>>>=20
>>>>> Oh, I should add that I disagree that it's not necessary to return =
the software statement.  It's a key part of the client registration =
information, and so should be returned like the other client =
registration information actually used.
>>>>>=20
>>>>> 				-- Mike
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike =
Jones
>>>>> Sent: Wednesday, February 05, 2014 6:08 PM
>>>>> To: Phil Hunt; Eve Maler
>>>>> Cc: oauth@ietf.org list
>>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>>>>=20
>>>>> Thanks for your comments, Phil.  I'm working on addressing them at =
present.
>>>>>=20
>>>>> One comment confuses me.  You wrote "Section 4.1 - It would be =
good to have an example with a software statement and no initial access =
token (or both)."  Yet the last example in Section 4.1 already is such =
as an example (taken from draft-hunt-oauth-client-association, =
actually).  Was there something else that you were thinking of?
>>>>>=20
>>>>> Also, the "Deployment Organization" definition *does* describe =
when it and the deployment organization are different.  Where I think =
that the text describing the choices for the two cases belongs is a =
subsection of the Use Cases appendix.  Do you want to write text about =
the two cases, Phi?
>>>>>=20
>>>>> 				-- Mike
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
>>>>> Sent: Monday, February 03, 2014 12:18 PM
>>>>> To: Eve Maler
>>>>> Cc: oauth@ietf.org list
>>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>>>>=20
>>>>> I am generally in agreement on the new drafts.  Thanks Mike!
>>>>>=20
>>>>> Here are some comments:
>>>>>=20
>>>>> In the software statement section 3:
>>>>>> If the authorization server determines that the claims in a =
software
>>>>>> statement uniquely identify a piece of software, the same Client =
ID
>>>>>> value MAY be returned for all dynamic registrations using that
>>>>>> software statement.
>>>>>>=20
>>>>>> In some cases, authorization servers MAY choose to accept a =
software
>>>>>> statement value directly as a Client ID in an authorization =
request,
>>>>>> without a prior dynamic client registration having been =
performed.
>>>>>> The circumstances under which an authorization server would do =
so,
>>>>>> and the specific software statement characteristics required in =
this
>>>>>> case, are beyond the scope of this specification.
>>>>>>=20
>>>>>=20
>>>>> We should call out that the server MAY also issue per instance =
client_id's (the opposite of the first quoted paragraph above) if it =
chooses to use client_id as an instance identifier (the software_id =
identifies what clients are based on the same software).  I think this =
will be the typical use case. Not sure whether the first paragraph =
should be re-written, or a new one added.
>>>>>=20
>>>>> Section 4.1
>>>>> It would be good to have an example with a software statement and =
no initial access token (or both).
>>>>>=20
>>>>> Section 5.1
>>>>> Should we also say that is not necessary to return the software =
statement.  Note: the server should return the meta data that was =
obtained from the statement.
>>>>>=20
>>>>> Dyn-Reg-Metadata
>>>>> The metadata document looks fine.  I would prefer it being =
included in dyn reg, but can live with it as is.
>>>>>=20
>>>>> Dyn-Reg-Management
>>>>> I'd like to discuss this more in London.  I think a SCIM based =
management API may be simpler to write up and can leverage the features =
of SCIM without having to redefine them in a new API.  Still, SCIM is a =
way off from approval -- so I understand the need to move forward now. =
Is experimental the right way to go?  I am not sure.
>>>>>=20
>>>>> Glossary
>>>>> The terms Software API Publisher and Software API Deployer are =
defined but never used, Specifically the text describing the issue of =
when these are two distinct entities is missing. When publisher and =
deployer are the same (eg. as with Facebook), the dynamic registration =
need is minimal since a client_id can be issued from a single domain.  =
When publisher and deployer are different, such as with OpenID Connect, =
SCIM, then the client developer cannot pre-register for a client_id at =
development time. =20
>>>>>=20
>>>>> The software statement is an optional mechanism that enables =
developers to pre-registrater to obtain a signed statement (instead of a =
client_id) so that API deployers can recognize the pre-registration =
relationship with the publisher.  Of course, software statements are =
optional if you don't need to be able to recognize what the client is.  =
(apologies if I have not phrased the issue optimally)
>>>>>=20
>>>>> Maybe if we can put in a couple of paragraphs explaining this =
distinction? =20
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>>>>>=20
>>>>>> Hi Hannes-- The UMA Core spec currently points directly to the =
basic dynamic client reg doc with MAY statements, and is agnostic as to =
usage of the higher-order functions. (These turn into optional interop =
feature tests.) So I think it's fair to say that the split has no =
structural problems from an UMA perspective.
>>>>>>=20
>>>>>> 	Eve
>>>>>>=20
>>>>>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig =
 wrote:
>>>>>>=20
>>>>>>> Hi all,
>>>>>>>=20
>>>>>>> as you have seen from the meeting minutes of our recent status =
chat=20
>>>>>>> it is time to proceed with the dynamic client registration work.
>>>>>>>=20
>>>>>>> The earlier version of the dynamic client registration document =
was=20
>>>>>>> split into three parts, namely
>>>>>>> (1) the current working group draft containing only minimal=20
>>>>>>> functionality,
>>>>>>> (2) a document describing meta-data, and
>>>>>>> (3) a document containing management functionality.
>>>>>>>=20
>>>>>>> This change was made as outcome of the discussions we had more =
or=20
>>>>>>> less over the last 9 months.
>>>>>>>=20
>>>>>>> The latter two documents are individual submissions at this =
point.=20
>>>>>>> New content is not available with the recent changes. So, it is =
one=20
>>>>>>> of those document management issues.
>>>>>>>=20
>>>>>>> I had a chat with Stephen about WG adoption of the two =
individual=20
>>>>>>> submissions as WG items. It was OK for him given that it is a =
purely=20
>>>>>>> document management action. However, before we turn the =
documents=20
>>>>>>> into WG items we need your feedback on a number of issues:
>>>>>>>=20
>>>>>>> 1) Do you have concerns with the document split? Do you object =
or=20
>>>>>>> approve it?
>>>>>>> 2) Is the separation of the functionality into these three =
documents=20
>>>>>>> correct? Should the line be drawn differently?
>>>>>>> 3) Do you have comments on the documents overall?
>>>>>>>=20
>>>>>>> We would like to receive high-level feedback within a week. We =
are=20
>>>>>>> also eager to hear from implementers and other projects using =
the=20
>>>>>>> dynamic client registration work (such as OpenID Connect, UMA, =
the=20
>>>>>>> BlueButton/GreenButton Initiative, etc.)
>>>>>>>=20
>>>>>>> For more detailed reviews please wait till we re-do the WGLC =
(which=20
>>>>>>> we plan to do soon). We have to restart the WGLC due to =
discussions=20
>>>>>>> last years and the resulting changes to these documents.
>>>>>>>=20
>>>>>>> Ciao
>>>>>>> Hannes & Derek
>>>>>>>=20
>>>>>>> PS: Derek and I also think that Phil should become co-auhor of =
these=20
>>>>>>> documents for his contributions.
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>>=20
>>>>>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>>>>>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>>>>>=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
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>=20
>=20


--Apple-Mail=_FEB30C5B-2085-4B3B-879D-CBFF4F74CD6F
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA2MTkzNDI2WjAjBgkqhkiG9w0BCQQxFgQUWEnk2HGZ
3q6u4JA2nLaxG3tBSGcwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAob+uL6BNo17PgAi2+Oe8GEcEhq70FsdS9L3lCQfD
89qnyK1SrIzulrIop9tX1xnoYOnIQpgiZH/UNICol0BhP0DQ7qQY0tNS+GE3H25i7D8naQ1vj/eV
2n+0bf/CwdQwcAh7Rn5J1GVm1PIJ/lecni1AGSFZ3TWDgArCHwX3bm126xxMP082j+jdN1ZLJz7I
8aJOratSOcfKeHzGMJXDddTIwj450Q5ERj8l0LF85xxkpJNvIfKXxOahYVwxPK3nirlzrB6SQNgX
S62VIGCkgMYVRNn7621pwWopLo5GtXqcP5HXslnJ9zacGfN75b4sJC4euStix4GWEYELZC+KUwAA
AAAAAA==

--Apple-Mail=_FEB30C5B-2085-4B3B-879D-CBFF4F74CD6F--

From phil.hunt@oracle.com  Thu Feb  6 11:54:35 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E391A03ED for ; Thu,  6 Feb 2014 11:54:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.636
X-Spam-Level: 
X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yySAJ5_6ucO6 for ; Thu,  6 Feb 2014 11:54:33 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E05111A045C for ; Thu,  6 Feb 2014 11:54:32 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s16JsUlE005878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Feb 2014 19:54:31 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s16JsTCZ025944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Feb 2014 19:54:30 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s16JsT9K001979; Thu, 6 Feb 2014 19:54:29 GMT
Received: from [192.168.1.124] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Feb 2014 11:54:29 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Phil Hunt 
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B15AAB2@TK5EX14MBXC288.redmond.corp.microsoft.com>
Date: Thu, 6 Feb 2014 11:54:30 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <694B99A6-04A6-486A-BB91-A1D7C6205536@oracle.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com> <00622740-EA6B-4C4B-9FAB-653B197BE028@oracle.com>  <79368F1D-94CA-4CE1-98A8-572C47DF0F7C@oracle.com> <48348E60-C9BC-46CC-BB41-DAA51BEDFC0F@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739438B15AAB2@TK5EX14MBXC288.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1510)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 19:54:35 -0000

Yes.  Mike and I did agree on this. =20

To confirm I have understood it,I thought I would send this so that we =
have a record of why we went with returning the statement (cause I know =
I'll forget in the future) :-)

I was concerned that returning the software statement (which was an =
input value) does not necessarily reflect the final registration state =
selected by the service provider.  For example, the AS may have selected =
a particular authentication mode. I was worried that returning the =
statement then might present some confusion compared to the registration =
profile the server has created.  It is not that I was advocating to not =
return the statement, it was that I was advocating the values from the =
statement that were accepted be included in the main registration =
profile returned (the statement would then be redundant).

=3D=3D> However, Mike made an excellent point that the statement could =
also be considered in part to be an authorization. Thus it is useful to =
retain the statement as a record of authorization (not just of the =
metadata values requested).

So in the case where values in the statement appear to duplicate values =
in a request or resonse here is the logic:
* in the request, metadata in the statement overrides metadata in the =
request itself,
* in the response, metadata in the response reflects what the server =
accepted and thus overrides any conflicting metadata in the original =
statement which is also returned.

Have I got that right?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-02-06, at 11:17 AM, Mike Jones  =
wrote:

> I just spoke to Tony about this in person and to Phil about it on the =
phone.  We're all good with having the server return the actual values =
used in the registration (which is what the spec already does).
>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Thursday, February 06, 2014 11:08 AM
> To: Phil Hunt
> Cc: Mike Jones; oauth@ietf.org list
> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>=20
> Telling the client the state of it's configuration is useful to the =
client if the server "makes right".
>=20
> I think Tony is arguing for the server putting the entire response =
into the software statement element in the response.  Where at the =
moment the spec provides those elements at the top level of the JSON =
object along with client_id etc.
>=20
> My question for Tony is if he is thinking that the made right software =
statement in the response would be signed by the AS as opposed to the =
original that was signed by the Software publisher, and if so what is =
the client going to do with it?
>=20
> John B.
>=20
> On Feb 6, 2014, at 3:52 PM, Phil Hunt  wrote:
>=20
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>> On 2014-02-06, at 10:38 AM, John Bradley  wrote:
>>=20
>>> I think it would be echoing back the software statement  that was =
processed as part of the request for consistency.  =20
>>=20
>> FWIW -- I don't really think anything should be returned other than =
the client_id and client creds and the location of the RESTful object =
created if available (the one accessible via the management api).
>>=20
>> Assume you man consistency with REST.  If that is the case, then what =
the server should respond with is the processed registration (the final =
state).  I see the statement as an input to the registration profile =
that gets created. A statement is not the completed registration.  Many =
clients share the same statement, but only one registration exists per =
instance.  A registration would have all of the input values plus any =
generated data like client_id and credentails.=20
>>=20
>> But as I said, I'm not sure why the client needs to see anything =
other than the client_id and credentials in the response other than to =
be "RESTful" in some way.
>>=20
>>=20
>>> Replying with a different software statement is going to be too =
confusing.  =20
>>> The entirety of the reply represents the configured state for the =
client.
>>>=20
>>> John B.
>>>=20
>>> On Feb 6, 2014, at 3:33 PM, Phil Hunt  wrote:
>>>=20
>>>> My thought was the original statement shouldn't be returned because =
the server would return the "processed" information.  IOW reflecting =
what it took from the certificate vs. from the registration request.
>>>>=20
>>>> If you just echo back the certificate you aren't necessarily =
reflecting the final state of the registration.
>>>>=20
>>>> I'm pretty open on this. Just want to make clear on what state we =
are returning (if any).
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>> On 2014-02-05, at 6:11 PM, Mike Jones  =
wrote:
>>>>=20
>>>>> Oh, I should add that I disagree that it's not necessary to return =
the software statement.  It's a key part of the client registration =
information, and so should be returned like the other client =
registration information actually used.
>>>>>=20
>>>>> 				-- Mike
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike =
Jones
>>>>> Sent: Wednesday, February 05, 2014 6:08 PM
>>>>> To: Phil Hunt; Eve Maler
>>>>> Cc: oauth@ietf.org list
>>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>>>>=20
>>>>> Thanks for your comments, Phil.  I'm working on addressing them at =
present.
>>>>>=20
>>>>> One comment confuses me.  You wrote "Section 4.1 - It would be =
good to have an example with a software statement and no initial access =
token (or both)."  Yet the last example in Section 4.1 already is such =
as an example (taken from draft-hunt-oauth-client-association, =
actually).  Was there something else that you were thinking of?
>>>>>=20
>>>>> Also, the "Deployment Organization" definition *does* describe =
when it and the deployment organization are different.  Where I think =
that the text describing the choices for the two cases belongs is a =
subsection of the Use Cases appendix.  Do you want to write text about =
the two cases, Phi?
>>>>>=20
>>>>> 				-- Mike
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
>>>>> Sent: Monday, February 03, 2014 12:18 PM
>>>>> To: Eve Maler
>>>>> Cc: oauth@ietf.org list
>>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>>>>=20
>>>>> I am generally in agreement on the new drafts.  Thanks Mike!
>>>>>=20
>>>>> Here are some comments:
>>>>>=20
>>>>> In the software statement section 3:
>>>>>> If the authorization server determines that the claims in a =
software
>>>>>> statement uniquely identify a piece of software, the same Client =
ID
>>>>>> value MAY be returned for all dynamic registrations using that
>>>>>> software statement.
>>>>>>=20
>>>>>> In some cases, authorization servers MAY choose to accept a =
software
>>>>>> statement value directly as a Client ID in an authorization =
request,
>>>>>> without a prior dynamic client registration having been =
performed.
>>>>>> The circumstances under which an authorization server would do =
so,
>>>>>> and the specific software statement characteristics required in =
this
>>>>>> case, are beyond the scope of this specification.
>>>>>>=20
>>>>>=20
>>>>> We should call out that the server MAY also issue per instance =
client_id's (the opposite of the first quoted paragraph above) if it =
chooses to use client_id as an instance identifier (the software_id =
identifies what clients are based on the same software).  I think this =
will be the typical use case. Not sure whether the first paragraph =
should be re-written, or a new one added.
>>>>>=20
>>>>> Section 4.1
>>>>> It would be good to have an example with a software statement and =
no initial access token (or both).
>>>>>=20
>>>>> Section 5.1
>>>>> Should we also say that is not necessary to return the software =
statement.  Note: the server should return the meta data that was =
obtained from the statement.
>>>>>=20
>>>>> Dyn-Reg-Metadata
>>>>> The metadata document looks fine.  I would prefer it being =
included in dyn reg, but can live with it as is.
>>>>>=20
>>>>> Dyn-Reg-Management
>>>>> I'd like to discuss this more in London.  I think a SCIM based =
management API may be simpler to write up and can leverage the features =
of SCIM without having to redefine them in a new API.  Still, SCIM is a =
way off from approval -- so I understand the need to move forward now. =
Is experimental the right way to go?  I am not sure.
>>>>>=20
>>>>> Glossary
>>>>> The terms Software API Publisher and Software API Deployer are =
defined but never used, Specifically the text describing the issue of =
when these are two distinct entities is missing. When publisher and =
deployer are the same (eg. as with Facebook), the dynamic registration =
need is minimal since a client_id can be issued from a single domain.  =
When publisher and deployer are different, such as with OpenID Connect, =
SCIM, then the client developer cannot pre-register for a client_id at =
development time. =20
>>>>>=20
>>>>> The software statement is an optional mechanism that enables =
developers to pre-registrater to obtain a signed statement (instead of a =
client_id) so that API deployers can recognize the pre-registration =
relationship with the publisher.  Of course, software statements are =
optional if you don't need to be able to recognize what the client is.  =
(apologies if I have not phrased the issue optimally)
>>>>>=20
>>>>> Maybe if we can put in a couple of paragraphs explaining this =
distinction? =20
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>>>>>=20
>>>>>> Hi Hannes-- The UMA Core spec currently points directly to the =
basic dynamic client reg doc with MAY statements, and is agnostic as to =
usage of the higher-order functions. (These turn into optional interop =
feature tests.) So I think it's fair to say that the split has no =
structural problems from an UMA perspective.
>>>>>>=20
>>>>>> 	Eve
>>>>>>=20
>>>>>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig =
 wrote:
>>>>>>=20
>>>>>>> Hi all,
>>>>>>>=20
>>>>>>> as you have seen from the meeting minutes of our recent status =
chat=20
>>>>>>> it is time to proceed with the dynamic client registration work.
>>>>>>>=20
>>>>>>> The earlier version of the dynamic client registration document =
was=20
>>>>>>> split into three parts, namely
>>>>>>> (1) the current working group draft containing only minimal=20
>>>>>>> functionality,
>>>>>>> (2) a document describing meta-data, and
>>>>>>> (3) a document containing management functionality.
>>>>>>>=20
>>>>>>> This change was made as outcome of the discussions we had more =
or=20
>>>>>>> less over the last 9 months.
>>>>>>>=20
>>>>>>> The latter two documents are individual submissions at this =
point.=20
>>>>>>> New content is not available with the recent changes. So, it is =
one=20
>>>>>>> of those document management issues.
>>>>>>>=20
>>>>>>> I had a chat with Stephen about WG adoption of the two =
individual=20
>>>>>>> submissions as WG items. It was OK for him given that it is a =
purely=20
>>>>>>> document management action. However, before we turn the =
documents=20
>>>>>>> into WG items we need your feedback on a number of issues:
>>>>>>>=20
>>>>>>> 1) Do you have concerns with the document split? Do you object =
or=20
>>>>>>> approve it?
>>>>>>> 2) Is the separation of the functionality into these three =
documents=20
>>>>>>> correct? Should the line be drawn differently?
>>>>>>> 3) Do you have comments on the documents overall?
>>>>>>>=20
>>>>>>> We would like to receive high-level feedback within a week. We =
are=20
>>>>>>> also eager to hear from implementers and other projects using =
the=20
>>>>>>> dynamic client registration work (such as OpenID Connect, UMA, =
the=20
>>>>>>> BlueButton/GreenButton Initiative, etc.)
>>>>>>>=20
>>>>>>> For more detailed reviews please wait till we re-do the WGLC =
(which=20
>>>>>>> we plan to do soon). We have to restart the WGLC due to =
discussions=20
>>>>>>> last years and the resulting changes to these documents.
>>>>>>>=20
>>>>>>> Ciao
>>>>>>> Hannes & Derek
>>>>>>>=20
>>>>>>> PS: Derek and I also think that Phil should become co-auhor of =
these=20
>>>>>>> documents for his contributions.
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>>=20
>>>>>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>>>>>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>>>>>=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
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>=20
>=20


From Michael.Jones@microsoft.com  Thu Feb  6 11:56:26 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C921A03F9 for ; Thu,  6 Feb 2014 11:56:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.502
X-Spam-Level: 
X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgGs9kz9lbOb for ; Thu,  6 Feb 2014 11:56:24 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 910681A03ED for ; Thu,  6 Feb 2014 11:56:23 -0800 (PST)
Received: from BY2PR03CA033.namprd03.prod.outlook.com (10.242.234.154) by BY2PR03MB608.namprd03.prod.outlook.com (10.255.93.39) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 19:56:20 +0000
Received: from BN1AFFO11FD015.protection.gbl (2a01:111:f400:7c10::152) by BY2PR03CA033.outlook.office365.com (2a01:111:e400:2c2c::26) with Microsoft SMTP Server (TLS) id 15.0.868.8 via Frontend Transport; Thu, 6 Feb 2014 19:56:20 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD015.mail.protection.outlook.com (10.58.52.75) with Microsoft SMTP Server (TLS) id 15.0.856.14 via Frontend Transport; Thu, 6 Feb 2014 19:56:20 +0000
Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0158.001; Thu, 6 Feb 2014 19:55:37 +0000
From: Mike Jones 
To: Phil Hunt 
Thread-Topic: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
Thread-Index: AQHPHZrqEhtxa32Q2EGvHz/lGJszjpqeLykAgAXPnoCAA4FdEIAABdPAgAESzQCAAAFlAIAAA7UAgAAEYQCAAAJbUIAACq8AgAAASkA=
Date: Thu, 6 Feb 2014 19:55:36 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739438B15ACCF@TK5EX14MBXC288.redmond.corp.microsoft.com>
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com> <00622740-EA6B-4C4B-9FAB-653B197BE028@oracle.com>  <79368F1D-94CA-4CE1-98A8-572C47DF0F7C@oracle.com> <48348E60-C9BC-46CC-BB41-DAA51BEDFC0F@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739438B15AAB2@TK5EX14MBXC288.redmond.corp.microsoft.com> <694B99A6-04A6-486A-BB91-A1D7C6205536@oracle.com>
In-Reply-To: <694B99A6-04A6-486A-BB91-A1D7C6205536@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(100?= =?us-ascii?Q?09001)(6009001)(51444003)(53754006)(199002)(189002)(37742400?= =?us-ascii?Q?4)(377454003)(50854003)(24454002)(13464003)(51704005)(813420?= =?us-ascii?Q?01)(81686001)(81816001)(81542001)(74366001)(6806004)(9431600?= =?us-ascii?Q?2)(83072002)(74502001)(47736001)(49866001)(47976001)(9014600?= =?us-ascii?Q?1)(56816005)(95416001)(50986001)(69226001)(93516002)(5584600?= =?us-ascii?Q?6)(93136001)(87266001)(92566001)(77982001)(80976001)(8661200?= =?us-ascii?Q?1)(46406003)(65816001)(4396001)(51856001)(63696002)(15975445?= =?us-ascii?Q?006)(53806001)(2656002)(47776003)(87936001)(15974865002)(800?= =?us-ascii?Q?22001)(19580395003)(85306002)(76482001)(23726002)(33656001)(?= =?us-ascii?Q?74662001)(85852003)(79102001)(86362001)(54356001)(66066001)(?= =?us-ascii?Q?59766001)(20776003)(94946001)(15202345003)(83322001)(5677600?= =?us-ascii?Q?1)(19580405001)(74706001)(50466002)(31966008)(92726001)(5431?= =?us-ascii?Q?6002)(77096001)(76786001)(46102001)(44976005)(76796001)(4744?= =?us-ascii?Q?6002)(74876001);DIR:OUT;SFP:1101;SCL:1;SRVR:BY2PR03MB608;H:m?= =?us-ascii?Q?ail.microsoft.com;CLIP:131.107.125.37;FPR:E6FED1C4.ACEA6180.?= =?us-ascii?Q?32D1F10B.8264E941.2081F;InfoDomainNonexistentA:1;MX:1;LANG:e?= =?us-ascii?Q?n;?=
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0114FF88F6
X-OriginatorOrg: microsoft.com
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 19:56:26 -0000

Yes

-----Original Message-----
From: Phil Hunt [mailto:phil.hunt@oracle.com]=20
Sent: Thursday, February 06, 2014 11:55 AM
To: Mike Jones
Cc: John Bradley; oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

Yes.  Mike and I did agree on this. =20

To confirm I have understood it,I thought I would send this so that we have=
 a record of why we went with returning the statement (cause I know I'll fo=
rget in the future) :-)

I was concerned that returning the software statement (which was an input v=
alue) does not necessarily reflect the final registration state selected by=
 the service provider.  For example, the AS may have selected a particular =
authentication mode. I was worried that returning the statement then might =
present some confusion compared to the registration profile the server has =
created.  It is not that I was advocating to not return the statement, it w=
as that I was advocating the values from the statement that were accepted b=
e included in the main registration profile returned (the statement would t=
hen be redundant).

=3D=3D> However, Mike made an excellent point that the statement could also=
 be considered in part to be an authorization. Thus it is useful to retain =
the statement as a record of authorization (not just of the metadata values=
 requested).

So in the case where values in the statement appear to duplicate values in =
a request or resonse here is the logic:
* in the request, metadata in the statement overrides metadata in the reque=
st itself,
* in the response, metadata in the response reflects what the server accept=
ed and thus overrides any conflicting metadata in the original statement wh=
ich is also returned.

Have I got that right?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-02-06, at 11:17 AM, Mike Jones  wrote:

> I just spoke to Tony about this in person and to Phil about it on the pho=
ne.  We're all good with having the server return the actual values used in=
 the registration (which is what the spec already does).
>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Thursday, February 06, 2014 11:08 AM
> To: Phil Hunt
> Cc: Mike Jones; oauth@ietf.org list
> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
>=20
> Telling the client the state of it's configuration is useful to the clien=
t if the server "makes right".
>=20
> I think Tony is arguing for the server putting the entire response into t=
he software statement element in the response.  Where at the moment the spe=
c provides those elements at the top level of the JSON object along with cl=
ient_id etc.
>=20
> My question for Tony is if he is thinking that the made right software st=
atement in the response would be signed by the AS as opposed to the origina=
l that was signed by the Software publisher, and if so what is the client g=
oing to do with it?
>=20
> John B.
>=20
> On Feb 6, 2014, at 3:52 PM, Phil Hunt  wrote:
>=20
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>> On 2014-02-06, at 10:38 AM, John Bradley  wrote:
>>=20
>>> I think it would be echoing back the software statement  that was proce=
ssed as part of the request for consistency.  =20
>>=20
>> FWIW -- I don't really think anything should be returned other than the =
client_id and client creds and the location of the RESTful object created i=
f available (the one accessible via the management api).
>>=20
>> Assume you man consistency with REST.  If that is the case, then what th=
e server should respond with is the processed registration (the final state=
).  I see the statement as an input to the registration profile that gets c=
reated. A statement is not the completed registration.  Many clients share =
the same statement, but only one registration exists per instance.  A regis=
tration would have all of the input values plus any generated data like cli=
ent_id and credentails.=20
>>=20
>> But as I said, I'm not sure why the client needs to see anything other t=
han the client_id and credentials in the response other than to be "RESTful=
" in some way.
>>=20
>>=20
>>> Replying with a different software statement is going to be too confusi=
ng.  =20
>>> The entirety of the reply represents the configured state for the clien=
t.
>>>=20
>>> John B.
>>>=20
>>> On Feb 6, 2014, at 3:33 PM, Phil Hunt  wrote:
>>>=20
>>>> My thought was the original statement shouldn't be returned because th=
e server would return the "processed" information.  IOW reflecting what it =
took from the certificate vs. from the registration request.
>>>>=20
>>>> If you just echo back the certificate you aren't necessarily reflectin=
g the final state of the registration.
>>>>=20
>>>> I'm pretty open on this. Just want to make clear on what state we are =
returning (if any).
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>> On 2014-02-05, at 6:11 PM, Mike Jones  wr=
ote:
>>>>=20
>>>>> Oh, I should add that I disagree that it's not necessary to return th=
e software statement.  It's a key part of the client registration informati=
on, and so should be returned like the other client registration informatio=
n actually used.
>>>>>=20
>>>>> 				-- Mike
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike=20
>>>>> Jones
>>>>> Sent: Wednesday, February 05, 2014 6:08 PM
>>>>> To: Phil Hunt; Eve Maler
>>>>> Cc: oauth@ietf.org list
>>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Need=
ed!
>>>>>=20
>>>>> Thanks for your comments, Phil.  I'm working on addressing them at pr=
esent.
>>>>>=20
>>>>> One comment confuses me.  You wrote "Section 4.1 - It would be good t=
o have an example with a software statement and no initial access token (or=
 both)."  Yet the last example in Section 4.1 already is such as an example=
 (taken from draft-hunt-oauth-client-association, actually).  Was there som=
ething else that you were thinking of?
>>>>>=20
>>>>> Also, the "Deployment Organization" definition *does* describe when i=
t and the deployment organization are different.  Where I think that the te=
xt describing the choices for the two cases belongs is a subsection of the =
Use Cases appendix.  Do you want to write text about the two cases, Phi?
>>>>>=20
>>>>> 				-- Mike
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
>>>>> Sent: Monday, February 03, 2014 12:18 PM
>>>>> To: Eve Maler
>>>>> Cc: oauth@ietf.org list
>>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Need=
ed!
>>>>>=20
>>>>> I am generally in agreement on the new drafts.  Thanks Mike!
>>>>>=20
>>>>> Here are some comments:
>>>>>=20
>>>>> In the software statement section 3:
>>>>>> If the authorization server determines that the claims in a=20
>>>>>> software statement uniquely identify a piece of software, the=20
>>>>>> same Client ID value MAY be returned for all dynamic=20
>>>>>> registrations using that software statement.
>>>>>>=20
>>>>>> In some cases, authorization servers MAY choose to accept a=20
>>>>>> software statement value directly as a Client ID in an=20
>>>>>> authorization request, without a prior dynamic client registration h=
aving been performed.
>>>>>> The circumstances under which an authorization server would do=20
>>>>>> so, and the specific software statement characteristics required=20
>>>>>> in this case, are beyond the scope of this specification.
>>>>>>=20
>>>>>=20
>>>>> We should call out that the server MAY also issue per instance client=
_id's (the opposite of the first quoted paragraph above) if it chooses to u=
se client_id as an instance identifier (the software_id identifies what cli=
ents are based on the same software).  I think this will be the typical use=
 case. Not sure whether the first paragraph should be re-written, or a new =
one added.
>>>>>=20
>>>>> Section 4.1
>>>>> It would be good to have an example with a software statement and no =
initial access token (or both).
>>>>>=20
>>>>> Section 5.1
>>>>> Should we also say that is not necessary to return the software state=
ment.  Note: the server should return the meta data that was obtained from =
the statement.
>>>>>=20
>>>>> Dyn-Reg-Metadata
>>>>> The metadata document looks fine.  I would prefer it being included i=
n dyn reg, but can live with it as is.
>>>>>=20
>>>>> Dyn-Reg-Management
>>>>> I'd like to discuss this more in London.  I think a SCIM based manage=
ment API may be simpler to write up and can leverage the features of SCIM w=
ithout having to redefine them in a new API.  Still, SCIM is a way off from=
 approval -- so I understand the need to move forward now. Is experimental =
the right way to go?  I am not sure.
>>>>>=20
>>>>> Glossary
>>>>> The terms Software API Publisher and Software API Deployer are define=
d but never used, Specifically the text describing the issue of when these =
are two distinct entities is missing. When publisher and deployer are the s=
ame (eg. as with Facebook), the dynamic registration need is minimal since =
a client_id can be issued from a single domain.  When publisher and deploye=
r are different, such as with OpenID Connect, SCIM, then the client develop=
er cannot pre-register for a client_id at development time. =20
>>>>>=20
>>>>> The software statement is an optional mechanism that enables=20
>>>>> developers to pre-registrater to obtain a signed statement=20
>>>>> (instead of a client_id) so that API deployers can recognize the=20
>>>>> pre-registration relationship with the publisher.  Of course,=20
>>>>> software statements are optional if you don't need to be able to=20
>>>>> recognize what the client is.  (apologies if I have not phrased=20
>>>>> the issue optimally)
>>>>>=20
>>>>> Maybe if we can put in a couple of paragraphs explaining this distinc=
tion? =20
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>>>>>=20
>>>>>> Hi Hannes-- The UMA Core spec currently points directly to the basic=
 dynamic client reg doc with MAY statements, and is agnostic as to usage of=
 the higher-order functions. (These turn into optional interop feature test=
s.) So I think it's fair to say that the split has no structural problems f=
rom an UMA perspective.
>>>>>>=20
>>>>>> 	Eve
>>>>>>=20
>>>>>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig  wrote:
>>>>>>=20
>>>>>>> Hi all,
>>>>>>>=20
>>>>>>> as you have seen from the meeting minutes of our recent status=20
>>>>>>> chat it is time to proceed with the dynamic client registration wor=
k.
>>>>>>>=20
>>>>>>> The earlier version of the dynamic client registration document=20
>>>>>>> was split into three parts, namely
>>>>>>> (1) the current working group draft containing only minimal=20
>>>>>>> functionality,
>>>>>>> (2) a document describing meta-data, and
>>>>>>> (3) a document containing management functionality.
>>>>>>>=20
>>>>>>> This change was made as outcome of the discussions we had more=20
>>>>>>> or less over the last 9 months.
>>>>>>>=20
>>>>>>> The latter two documents are individual submissions at this point.=
=20
>>>>>>> New content is not available with the recent changes. So, it is=20
>>>>>>> one of those document management issues.
>>>>>>>=20
>>>>>>> I had a chat with Stephen about WG adoption of the two=20
>>>>>>> individual submissions as WG items. It was OK for him given that=20
>>>>>>> it is a purely document management action. However, before we=20
>>>>>>> turn the documents into WG items we need your feedback on a number =
of issues:
>>>>>>>=20
>>>>>>> 1) Do you have concerns with the document split? Do you object=20
>>>>>>> or approve it?
>>>>>>> 2) Is the separation of the functionality into these three=20
>>>>>>> documents correct? Should the line be drawn differently?
>>>>>>> 3) Do you have comments on the documents overall?
>>>>>>>=20
>>>>>>> We would like to receive high-level feedback within a week. We=20
>>>>>>> are also eager to hear from implementers and other projects=20
>>>>>>> using the dynamic client registration work (such as OpenID=20
>>>>>>> Connect, UMA, the BlueButton/GreenButton Initiative, etc.)
>>>>>>>=20
>>>>>>> For more detailed reviews please wait till we re-do the WGLC=20
>>>>>>> (which we plan to do soon). We have to restart the WGLC due to=20
>>>>>>> discussions last years and the resulting changes to these documents=
.
>>>>>>>=20
>>>>>>> Ciao
>>>>>>> Hannes & Derek
>>>>>>>=20
>>>>>>> PS: Derek and I also think that Phil should become co-auhor of=20
>>>>>>> these documents for his contributions.
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>>=20
>>>>>> Eve Maler                                  http://www.xmlgrrl.com/bl=
og
>>>>>> +1 425 345 6756                         http://www.twitter.com/xmlgr=
rl
>>>>>>=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
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>=20
>=20


From ve7jtb@ve7jtb.com  Thu Feb  6 12:10:03 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377361A048F for ; Thu,  6 Feb 2014 12:10:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level: 
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY8zoulGJrYy for ; Thu,  6 Feb 2014 12:09:59 -0800 (PST)
Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 57A151A048B for ; Thu,  6 Feb 2014 12:09:56 -0800 (PST)
Received: by mail-qa0-f49.google.com with SMTP id w8so3589500qac.36 for ; Thu, 06 Feb 2014 12:09:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=l6R/oKU0DWmKm+xT/Jtc0DFZ3v2seFCjO6fDLCXffII=; b=MAQbFAA437SS/M0XS7oPbUlPusVSRFHBLyEQSypTvXbM+izAog0lw8oUTZf+ggfj2K ikWGumA7AHPBtfDuYKgynjlDZUwKFRLcmz+IDktXfIiX2aNDEyaNbMN0aI5N1gdrMuK+ EO9hZGesp8nhO3NozLiRSIL4rxyd+xUtnkJVBzHbaHEaL+KP1JIQ4NqbsDBEMhXpxM0d 3wsO7KFDY+VQbq8uMYkVZBMBZI8f2VdwLjsmWPc8QJqQGk9GTx0lEVZ3hpNrN1eycDtM KCWWWZ6T/t9yW7d1nQ5/OJETxLsKzo7Jen03Q4adKNQxjpb9N6X0E2GkDqYFLImH3P/q WEfA==
X-Gm-Message-State: ALoCoQnRYC22nKw+ZAQ1H5aa0Gj0spJfCAJiSdosLeBIgP/gysiKNCX13LMtNWvP77KXr0kilq+p
X-Received: by 10.224.16.72 with SMTP id n8mr15589013qaa.76.1391717394887; Thu, 06 Feb 2014 12:09:54 -0800 (PST)
Received: from [192.168.0.200] ([201.189.102.146]) by mx.google.com with ESMTPSA id o68sm3647000qge.8.2014.02.06.12.09.50 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 12:09:53 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_0BAB99A5-EB6A-4187-91B7-6688A7B1631F"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley 
In-Reply-To: <694B99A6-04A6-486A-BB91-A1D7C6205536@oracle.com>
Date: Thu, 6 Feb 2014 17:09:47 -0300
Message-Id: 
References: <52E87DE4.1070000@gmx.net> <7C4FBCAA-9B5E-4EFD-A2DD-D68F1F75EA7C@xmlgrrl.com>  <4E1F6AAD24975D4BA5B16804296739438B157B13@TK5EX14MBXC288.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739438B157B4E@TK5EX14MBXC288.redmond.corp.microsoft.com> <00622740-EA6B-4C4B-9FAB-653B197BE028@oracle.com>  <79368F1D-94CA-4CE1-98A8-572C47DF0F7C@oracle.com> <48348E60-C9BC-46CC-BB41-DAA51BEDFC0F@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739438B15AAB2@TK5EX14MBXC288.redmond.corp.microsoft.com> <694B99A6-04A6-486A-BB91-A1D7C6205536@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.1827)
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Feb 2014 20:10:03 -0000

--Apple-Mail=_0BAB99A5-EB6A-4187-91B7-6688A7B1631F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Yes that is what I confirmed with Mike. =20

On Feb 6, 2014, at 4:54 PM, Phil Hunt  wrote:

> Yes.  Mike and I did agree on this. =20
>=20
> To confirm I have understood it,I thought I would send this so that we =
have a record of why we went with returning the statement (cause I know =
I'll forget in the future) :-)
>=20
> I was concerned that returning the software statement (which was an =
input value) does not necessarily reflect the final registration state =
selected by the service provider.  For example, the AS may have selected =
a particular authentication mode. I was worried that returning the =
statement then might present some confusion compared to the registration =
profile the server has created.  It is not that I was advocating to not =
return the statement, it was that I was advocating the values from the =
statement that were accepted be included in the main registration =
profile returned (the statement would then be redundant).
>=20
> =3D=3D> However, Mike made an excellent point that the statement could =
also be considered in part to be an authorization. Thus it is useful to =
retain the statement as a record of authorization (not just of the =
metadata values requested).
>=20
> So in the case where values in the statement appear to duplicate =
values in a request or resonse here is the logic:
> * in the request, metadata in the statement overrides metadata in the =
request itself,
> * in the response, metadata in the response reflects what the server =
accepted and thus overrides any conflicting metadata in the original =
statement which is also returned.
>=20
> Have I got that right?
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> On 2014-02-06, at 11:17 AM, Mike Jones  =
wrote:
>=20
>> I just spoke to Tony about this in person and to Phil about it on the =
phone.  We're all good with having the server return the actual values =
used in the registration (which is what the spec already does).
>>=20
>> 				-- Mike
>>=20
>> -----Original Message-----
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
>> Sent: Thursday, February 06, 2014 11:08 AM
>> To: Phil Hunt
>> Cc: Mike Jones; oauth@ietf.org list
>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>=20
>> Telling the client the state of it's configuration is useful to the =
client if the server "makes right".
>>=20
>> I think Tony is arguing for the server putting the entire response =
into the software statement element in the response.  Where at the =
moment the spec provides those elements at the top level of the JSON =
object along with client_id etc.
>>=20
>> My question for Tony is if he is thinking that the made right =
software statement in the response would be signed by the AS as opposed =
to the original that was signed by the Software publisher, and if so =
what is the client going to do with it?
>>=20
>> John B.
>>=20
>> On Feb 6, 2014, at 3:52 PM, Phil Hunt  wrote:
>>=20
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>> On 2014-02-06, at 10:38 AM, John Bradley  wrote:
>>>=20
>>>> I think it would be echoing back the software statement  that was =
processed as part of the request for consistency.  =20
>>>=20
>>> FWIW -- I don't really think anything should be returned other than =
the client_id and client creds and the location of the RESTful object =
created if available (the one accessible via the management api).
>>>=20
>>> Assume you man consistency with REST.  If that is the case, then =
what the server should respond with is the processed registration (the =
final state).  I see the statement as an input to the registration =
profile that gets created. A statement is not the completed =
registration.  Many clients share the same statement, but only one =
registration exists per instance.  A registration would have all of the =
input values plus any generated data like client_id and credentails.=20
>>>=20
>>> But as I said, I'm not sure why the client needs to see anything =
other than the client_id and credentials in the response other than to =
be "RESTful" in some way.
>>>=20
>>>=20
>>>> Replying with a different software statement is going to be too =
confusing.  =20
>>>> The entirety of the reply represents the configured state for the =
client.
>>>>=20
>>>> John B.
>>>>=20
>>>> On Feb 6, 2014, at 3:33 PM, Phil Hunt  wrote:
>>>>=20
>>>>> My thought was the original statement shouldn't be returned =
because the server would return the "processed" information.  IOW =
reflecting what it took from the certificate vs. from the registration =
request.
>>>>>=20
>>>>> If you just echo back the certificate you aren't necessarily =
reflecting the final state of the registration.
>>>>>=20
>>>>> I'm pretty open on this. Just want to make clear on what state we =
are returning (if any).
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>> On 2014-02-05, at 6:11 PM, Mike Jones =
 wrote:
>>>>>=20
>>>>>> Oh, I should add that I disagree that it's not necessary to =
return the software statement.  It's a key part of the client =
registration information, and so should be returned like the other =
client registration information actually used.
>>>>>>=20
>>>>>> 				-- Mike
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike =
Jones
>>>>>> Sent: Wednesday, February 05, 2014 6:08 PM
>>>>>> To: Phil Hunt; Eve Maler
>>>>>> Cc: oauth@ietf.org list
>>>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>>>>>=20
>>>>>> Thanks for your comments, Phil.  I'm working on addressing them =
at present.
>>>>>>=20
>>>>>> One comment confuses me.  You wrote "Section 4.1 - It would be =
good to have an example with a software statement and no initial access =
token (or both)."  Yet the last example in Section 4.1 already is such =
as an example (taken from draft-hunt-oauth-client-association, =
actually).  Was there something else that you were thinking of?
>>>>>>=20
>>>>>> Also, the "Deployment Organization" definition *does* describe =
when it and the deployment organization are different.  Where I think =
that the text describing the choices for the two cases belongs is a =
subsection of the Use Cases appendix.  Do you want to write text about =
the two cases, Phi?
>>>>>>=20
>>>>>> 				-- Mike
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil =
Hunt
>>>>>> Sent: Monday, February 03, 2014 12:18 PM
>>>>>> To: Eve Maler
>>>>>> Cc: oauth@ietf.org list
>>>>>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback =
Needed!
>>>>>>=20
>>>>>> I am generally in agreement on the new drafts.  Thanks Mike!
>>>>>>=20
>>>>>> Here are some comments:
>>>>>>=20
>>>>>> In the software statement section 3:
>>>>>>> If the authorization server determines that the claims in a =
software
>>>>>>> statement uniquely identify a piece of software, the same Client =
ID
>>>>>>> value MAY be returned for all dynamic registrations using that
>>>>>>> software statement.
>>>>>>>=20
>>>>>>> In some cases, authorization servers MAY choose to accept a =
software
>>>>>>> statement value directly as a Client ID in an authorization =
request,
>>>>>>> without a prior dynamic client registration having been =
performed.
>>>>>>> The circumstances under which an authorization server would do =
so,
>>>>>>> and the specific software statement characteristics required in =
this
>>>>>>> case, are beyond the scope of this specification.
>>>>>>>=20
>>>>>>=20
>>>>>> We should call out that the server MAY also issue per instance =
client_id's (the opposite of the first quoted paragraph above) if it =
chooses to use client_id as an instance identifier (the software_id =
identifies what clients are based on the same software).  I think this =
will be the typical use case. Not sure whether the first paragraph =
should be re-written, or a new one added.
>>>>>>=20
>>>>>> Section 4.1
>>>>>> It would be good to have an example with a software statement and =
no initial access token (or both).
>>>>>>=20
>>>>>> Section 5.1
>>>>>> Should we also say that is not necessary to return the software =
statement.  Note: the server should return the meta data that was =
obtained from the statement.
>>>>>>=20
>>>>>> Dyn-Reg-Metadata
>>>>>> The metadata document looks fine.  I would prefer it being =
included in dyn reg, but can live with it as is.
>>>>>>=20
>>>>>> Dyn-Reg-Management
>>>>>> I'd like to discuss this more in London.  I think a SCIM based =
management API may be simpler to write up and can leverage the features =
of SCIM without having to redefine them in a new API.  Still, SCIM is a =
way off from approval -- so I understand the need to move forward now. =
Is experimental the right way to go?  I am not sure.
>>>>>>=20
>>>>>> Glossary
>>>>>> The terms Software API Publisher and Software API Deployer are =
defined but never used, Specifically the text describing the issue of =
when these are two distinct entities is missing. When publisher and =
deployer are the same (eg. as with Facebook), the dynamic registration =
need is minimal since a client_id can be issued from a single domain.  =
When publisher and deployer are different, such as with OpenID Connect, =
SCIM, then the client developer cannot pre-register for a client_id at =
development time. =20
>>>>>>=20
>>>>>> The software statement is an optional mechanism that enables =
developers to pre-registrater to obtain a signed statement (instead of a =
client_id) so that API deployers can recognize the pre-registration =
relationship with the publisher.  Of course, software statements are =
optional if you don't need to be able to recognize what the client is.  =
(apologies if I have not phrased the issue optimally)
>>>>>>=20
>>>>>> Maybe if we can put in a couple of paragraphs explaining this =
distinction? =20
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> @independentid
>>>>>> www.independentid.com
>>>>>> phil.hunt@oracle.com
>>>>>>=20
>>>>>> On 2014-01-30, at 7:33 PM, Eve Maler  wrote:
>>>>>>=20
>>>>>>> Hi Hannes-- The UMA Core spec currently points directly to the =
basic dynamic client reg doc with MAY statements, and is agnostic as to =
usage of the higher-order functions. (These turn into optional interop =
feature tests.) So I think it's fair to say that the split has no =
structural problems from an UMA perspective.
>>>>>>>=20
>>>>>>> 	Eve
>>>>>>>=20
>>>>>>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig =
 wrote:
>>>>>>>=20
>>>>>>>> Hi all,
>>>>>>>>=20
>>>>>>>> as you have seen from the meeting minutes of our recent status =
chat=20
>>>>>>>> it is time to proceed with the dynamic client registration =
work.
>>>>>>>>=20
>>>>>>>> The earlier version of the dynamic client registration document =
was=20
>>>>>>>> split into three parts, namely
>>>>>>>> (1) the current working group draft containing only minimal=20
>>>>>>>> functionality,
>>>>>>>> (2) a document describing meta-data, and
>>>>>>>> (3) a document containing management functionality.
>>>>>>>>=20
>>>>>>>> This change was made as outcome of the discussions we had more =
or=20
>>>>>>>> less over the last 9 months.
>>>>>>>>=20
>>>>>>>> The latter two documents are individual submissions at this =
point.=20
>>>>>>>> New content is not available with the recent changes. So, it is =
one=20
>>>>>>>> of those document management issues.
>>>>>>>>=20
>>>>>>>> I had a chat with Stephen about WG adoption of the two =
individual=20
>>>>>>>> submissions as WG items. It was OK for him given that it is a =
purely=20
>>>>>>>> document management action. However, before we turn the =
documents=20
>>>>>>>> into WG items we need your feedback on a number of issues:
>>>>>>>>=20
>>>>>>>> 1) Do you have concerns with the document split? Do you object =
or=20
>>>>>>>> approve it?
>>>>>>>> 2) Is the separation of the functionality into these three =
documents=20
>>>>>>>> correct? Should the line be drawn differently?
>>>>>>>> 3) Do you have comments on the documents overall?
>>>>>>>>=20
>>>>>>>> We would like to receive high-level feedback within a week. We =
are=20
>>>>>>>> also eager to hear from implementers and other projects using =
the=20
>>>>>>>> dynamic client registration work (such as OpenID Connect, UMA, =
the=20
>>>>>>>> BlueButton/GreenButton Initiative, etc.)
>>>>>>>>=20
>>>>>>>> For more detailed reviews please wait till we re-do the WGLC =
(which=20
>>>>>>>> we plan to do soon). We have to restart the WGLC due to =
discussions=20
>>>>>>>> last years and the resulting changes to these documents.
>>>>>>>>=20
>>>>>>>> Ciao
>>>>>>>> Hannes & Derek
>>>>>>>>=20
>>>>>>>> PS: Derek and I also think that Phil should become co-auhor of =
these=20
>>>>>>>> documents for his contributions.
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>=20
>>>>>>>=20
>>>>>>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>>>>>>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>>>>>>=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
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_0BAB99A5-EB6A-4187-91B7-6688A7B1631F
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA2MjAwOTQ3WjAjBgkqhkiG9w0BCQQxFgQU7hWu9N33
cj9Nu8IRk/FZhnLJbCQwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAGcPK5JNiejNzoBXbCsDeDnMBcSuMHP9oQ+N8Wz9F
dwjvpiCKVaoEIKfDD2avLf6QpXwxSeyNukAVZjU0YOWrqYU8FixesR9QxFnAvUaAcRaXrt+17gKo
BHzldMajtkxkYOhJQ3v9JYoRAlFyiscbOJyCym0GUKHIjsj/+9qgm1hDIKG1VOr4xdN6UV07cGY7
CdWKOQYo41y9lSjt6sBZkaPnjZFQdSzlTx0d6O1yjTw6Mwc8xIWSyrM7MV9C4wBTEcLo9SoCE/R4
V65Fe9AKDe97qYTB7pOxEzHeVZzw9ILvrOW+nU+4iKUo4e7wS6FCQsvlqt+vPp/XNHoO8iLt5wAA
AAAAAA==

--Apple-Mail=_0BAB99A5-EB6A-4187-91B7-6688A7B1631F--

From internet-drafts@ietf.org  Fri Feb  7 10:12:55 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3B61A00F0; Fri,  7 Feb 2014 10:12:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm07z1SwfcYv; Fri,  7 Feb 2014 10:12:53 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 291661ACCE6; Fri,  7 Feb 2014 10:12:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140207181249.1631.7931.idtracker@ietfa.amsl.com>
Date: Fri, 07 Feb 2014 10:12:49 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-metadata-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Feb 2014 18:12:55 -0000

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

        Title           : OAuth 2.0 Dynamic Client Registration Metadata
        Authors         : Justin Richer
                          Michael B. Jones
                          John Bradley
                          Maciej Machulak
                          Phil Hunt
	Filename        : draft-ietf-oauth-dyn-reg-metadata-00.txt
	Pages           : 10
	Date            : 2014-02-06

Abstract:
   This specification defines client metadata values used to describe
   attributes of dynamically registered OAuth 2.0 clients.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-metadata/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00


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

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


From internet-drafts@ietf.org  Fri Feb  7 10:13:27 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16F71A0203; Fri,  7 Feb 2014 10:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i-oxh3u5uDH; Fri,  7 Feb 2014 10:13:26 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3DF1A00F0; Fri,  7 Feb 2014 10:13:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140207181326.27145.97643.idtracker@ietfa.amsl.com>
Date: Fri, 07 Feb 2014 10:13:26 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Feb 2014 18:13:27 -0000

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

        Title           : OAuth 2.0 Dynamic Client Registration Management Protocol
        Authors         : Justin Richer
                          Michael B. Jones
                          John Bradley
                          Maciej Machulak
                          Phil Hunt
	Filename        : draft-ietf-oauth-dyn-reg-management-00.txt
	Pages           : 16
	Date            : 2014-02-06

Abstract:
   This specification defines methods for management of dynamic OAuth
   2.0 client registrations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-00


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

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


From internet-drafts@ietf.org  Fri Feb  7 10:38:44 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194351A01B0; Fri,  7 Feb 2014 10:38:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpRNd2JShp-u; Fri,  7 Feb 2014 10:38:42 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F011A1A0416; Fri,  7 Feb 2014 10:38:41 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140207183841.14709.80714.idtracker@ietfa.amsl.com>
Date: Fri, 07 Feb 2014 10:38:41 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-16.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Feb 2014 18:38:44 -0000

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

        Title           : OAuth 2.0 Dynamic Client Registration Core Protocol
        Authors         : Justin Richer
                          Michael B. Jones
                          John Bradley
                          Maciej Machulak
                          Phil Hunt
	Filename        : draft-ietf-oauth-dyn-reg-16.txt
	Pages           : 30
	Date            : 2014-02-07

Abstract:
   This specification defines mechanisms used to dynamically register
   OAuth 2.0 clients at authorization servers.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-16


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

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


From Michael.Jones@microsoft.com  Fri Feb  7 10:58:26 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BEE1A03E1 for ; Fri,  7 Feb 2014 10:58:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw6OMMI1zmM5 for ; Fri,  7 Feb 2014 10:58:24 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id C4D181A00FE for ; Fri,  7 Feb 2014 10:58:23 -0800 (PST)
Received: from BY2PR03CA031.namprd03.prod.outlook.com (10.242.234.152) by BY2PR03MB287.namprd03.prod.outlook.com (10.242.37.26) with Microsoft SMTP Server (TLS) id 15.0.868.8; Fri, 7 Feb 2014 18:58:21 +0000
Received: from BN1BFFO11FD033.protection.gbl (2a01:111:f400:7c10::1:116) by BY2PR03CA031.outlook.office365.com (2a01:111:e400:2c2c::24) with Microsoft SMTP Server (TLS) id 15.0.868.8 via Frontend Transport; Fri, 7 Feb 2014 18:58:22 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD033.mail.protection.outlook.com (10.58.144.96) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Fri, 7 Feb 2014 18:58:21 +0000
Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0174.002; Fri, 7 Feb 2014 18:57:45 +0000
From: Mike Jones 
To: "oauth@ietf.org list" 
Thread-Topic: Working Group Versions of Refactored OAuth Dynamic Client Registration Specs
Thread-Index: Ac8kNnz3PF/lDi5zTKOXOi6a7z33lw==
Date: Fri, 7 Feb 2014 18:57:45 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739438B1882D3@TK5EX14MBXC288.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.32]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B1882D3TK5EX14MBXC288r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(199002)(189002)(44976005)(49866001)(4396001)(47736001)(94946001)(79102001)(74876001)(92726001)(20776003)(63696002)(93516002)(47976001)(16236675002)(46102001)(74706001)(50986001)(51856001)(71186001)(56776001)(54316002)(15202345003)(81816001)(77096001)(76786001)(76176001)(86362001)(87266001)(85306002)(33656001)(81342001)(2656002)(84326002)(87936001)(93136001)(74366001)(19300405004)(65816001)(59766001)(69226001)(31966008)(81542001)(81686001)(6806004)(76482001)(77982001)(54356001)(74502001)(80022001)(92566001)(85852003)(83072002)(90146001)(86612001)(76796001)(15975445006)(94316002)(53806001)(16297215004)(74662001)(19580395003)(47446002)(55846006)(80976001)(56816005)(95416001)(83322001)(66066001)(512954002)(6606295002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB287; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:BD00F8BD.80F2AFD8.AEE02EC7.44D435D0.2014C; InfoDomainNonexistentA:1; MX:1; LANG:en; 
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 011579F31F
X-OriginatorOrg: microsoft.com
Subject: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic Client Registration Specs
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Feb 2014 18:58:26 -0000

--_000_4E1F6AAD24975D4BA5B16804296739438B1882D3TK5EX14MBXC288r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

There are now OAuth working group ve=
rsions of the refactored OAuth Dynamic Client Registration specifications:

*        OAuth 2.0 Dynamic Client Registration Core Protocol

*        OAuth 2.0 Dynamic Client Registration Metadata

*        OAuth 2.0 Dynamic Client Registration Management Protocol

These versions address review comments by Phil Hunt and Tony Nadalin.  Phil=
 is now also an author.  The data structures and messages used are the same=
 as the previous versions.

The drafts are available at:

*        http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

*        http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

*        http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-00

HTML formatted versions are also available at:

*        https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-16.html

*        https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-metadata-00=
.html

*        https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-management-=
00.html

                                                            -- Mike

P.S.  I also posted this notice at http://self-issued.info/?p=3D1180 and as=
 @selfissued.


--_000_4E1F6AAD24975D4BA5B16804296739438B1882D3TK5EX14MBXC288r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











There are now 
OAuth working group versions of the refactored OAuth Dynamic Client Reg=
istration specifications:


·       
OAuth 2.0 Dynamic Client Registration Core P=
rotocol


·       
OAuth 2.0 Dynamic Client R=
egistration Metadata


·       
OAuth 2.0 Dynamic Client Registration Manage=
ment Protocol


 


These versions address review comments by Phil Hunt =
and Tony Nadalin.  Phil is now also an author.  The data structur=
es and messages used are the same as the
previous versions.


 


The drafts are available at:


·       
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-=
16


·       
http://tools.ietf.org/html/draft-ietf-oauth=
-dyn-reg-metadata-00


·       
http://tools.ietf.org/html/draft-ietf-oau=
th-dyn-reg-management-00


 


HTML formatted versions are also available at:<=
/o:p>


·       
https://self-issued.info/docs/draft-ietf-oau=
th-dyn-reg-16.html


·       
https://self-issued.info/docs/draft=
-ietf-oauth-dyn-reg-metadata-00.html


·       
https://self-issued.info/docs/dra=
ft-ietf-oauth-dyn-reg-management-00.html


 


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


 


P.S.  I also posted this notice at 
http://self-issued.info/?p=3D1180 and as @selfissued.


 






--_000_4E1F6AAD24975D4BA5B16804296739438B1882D3TK5EX14MBXC288r_--

From eriksencosta@gmail.com  Tue Feb  4 11:02:32 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC42E1A01A5 for ; Tue,  4 Feb 2014 11:02:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXWQ9Ao_jfIg for ; Tue,  4 Feb 2014 11:02:26 -0800 (PST)
Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 393241A01AB for ; Tue,  4 Feb 2014 11:02:26 -0800 (PST)
Received: by mail-vb0-f54.google.com with SMTP id w20so6212954vbb.27 for ; Tue, 04 Feb 2014 11:02:25 -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=m6aYYer3yc4gdQNmclms7nf46+zHmTzmjEBCq4mJz6Y=; b=Vbvy8gcTh52hwCpeEYyoQ1LVmtvy1/T3kRV8oXn5booeaH8ab80/wJ2TGCSUK8AoLi eyqGj+34yd78qHPDAsyy3U5rZqPK86GBuo5bpOlKUl1B8Vmed4MCw0sx6JEn/EYDD1tF gktoRjxU/8pdw8jHRFnulh9+hduoliyQtkmomV5AxXFwH74qYGLGVmmV/xKWPSVQs72P H2C5MBWkOiOH5JzVQsfsuJ7looFp5Ja4liE0AnPmy6icH8Z9X9msWp3lBhCXUQ4zGrBP EzqsedVg1BgZCb4g6RNw/NHiGu0As/w2f6R+sEsNk57YOYFDxjrx7376ZrehflWkIGLN 7upw==
MIME-Version: 1.0
X-Received: by 10.58.90.202 with SMTP id by10mr32746983veb.6.1391540545512; Tue, 04 Feb 2014 11:02:25 -0800 (PST)
Received: by 10.58.215.168 with HTTP; Tue, 4 Feb 2014 11:02:25 -0800 (PST)
In-Reply-To: <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com>
References: <20140204161338.9A4007FC168@rfc-editor.org>  <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com>
Date: Tue, 4 Feb 2014 17:02:25 -0200
Message-ID: 
From: Eriksen Costa 
To: Bill Mills 
Content-Type: multipart/alternative; boundary=001a1136a478e7ed9304f1994767
X-Mailman-Approved-At: Fri, 07 Feb 2014 11:10:25 -0800
Cc: "turners@ieca.com" , RFC Errata System , "derek@ihtfp.com" , OAuth WG 
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Feb 2014 19:05:09 -0000

--001a1136a478e7ed9304f1994767
Content-Type: text/plain; charset=UTF-8

Could we make Mishra's suggestion simpler? Example:

For public clients using implicit flows, this specification does not
provide any method for the client to determine that an access token was
issued to its current instance.

I'm not sure if it is explicit enough, neither convinced about "instance"
(maybe "session"?) but it seems more in line with the rest of the
specification's wording.

Thank you for the clarification,
Eriksen


On Tue, Feb 4, 2014 at 4:56 PM, Bill Mills  wrote:

> Agreed.
>
>
>   On Tuesday, February 4, 2014 8:17 AM, Dick Hardt 
> wrote:
>  This change is appropriate and reflects the intent of the statement.
>
>
> On Tue, Feb 4, 2014 at 8:13 AM, RFC Errata System <
> rfc-editor@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880
>
> --------------------------------------
> Type: Technical
> Reported by: Eriksen Costa 
>
> Section: 10.16
>
> Original Text
> -------------
> For public clients using implicit flows, this specification does not
> provide any method for the client to determine what client an access
> token was issued to.
>
> Corrected Text
> --------------
> For public clients using implicit flows, this specification does not
> provide any method for the authorization server to determine what
> client an access token was issued to.
>
> Notes
> -----
> A client can only know about tokens issued to it and not for other clients.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6749 (draft-ietf-oauth-v2-31)
> --------------------------------------
> Title               : The OAuth 2.0 Authorization Framework
> Publication Date    : October 2012
> Author(s)           : D. Hardt, Ed.
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>


-- 
Blog: http://blog.eriksen.com.br
Twitter: @eriksencosta

--001a1136a478e7ed9304f1994767
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Could we make Mishra's suggestion simpler? Example:
For public clie=
nts using implicit flows, this specification does not
provide any method for the client to dete=
rmine that an access token was


issued to its current instance.<=
/font>

I'm not sure if it =
is explicit enough, neither convinced about "instance" (maybe &qu=
ot;session"?) but it seems more in line with the rest of the specifica=
tion's wording.



Thank you for the clarification,
Eriksen



On Tue,=
 Feb 4, 2014 at 4:56 PM, Bill Mills <wmills_92105@yahoo.com> wrote:



Agreed.
 
 
 
 


 
  On Tuesday,=
 February 4, 2014 8:17 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
    


This change is=
 appropriate and reflects the intent of the statement.


On Tue, Feb 4, 2014 at 8:13 AM, RFC =
Errata System <rfc-editor@rfc-edit=
or.org> wrote:




The following errata report has been submitted for RFC6749,

"The OAuth 2.0 Authorization Framework".



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

You may review the report below and at:

http://www.rfc-edi=
tor.org/errata_search.php?rfc=3D6749&eid=3D3880



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

Type: Technical

Reported by: Eriksen Costa <eriksencosta@gmail.com&=
gt;



Section: 10.16



Original Text

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

For public clients using implicit flows, this specification does not

provide any method for the client to determine what client an access

token was issued to.



Corrected Text

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

For public clients using implicit flows, this specification does not

provide any method for the authorization server to determine what

client an access token was issued to.



Notes

-----

A client can only know about tokens issued to it and not for other clients.=




Instructions:

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

This errata is currently posted as "Reported". If necessary, plea=
se

use "Reply All" to discuss whether it should be verified or

rejected. When a decision is reached, the verifying party (IESG)

can log in to change the status and edit the report, if necessary.



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

RFC6749 (draft-ietf-oauth-v2-31)

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

Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : The OAuth 2.0 Auth=
orization Framework

Publication Date =C2=A0 =C2=A0: October 2012

Author(s) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : D. Hardt, Ed.

Category =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: PROPOSED STANDARD

Source =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Web Authorization =
Protocol

Area =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Security

Stream =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IETF

Verifying Party =C2=A0 =C2=A0 : IESG




_______________________________________________OAuth mailing list
OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


  
 
  
 





-- 
Blog: http://blog.eriksen.com.br
Twi=
tter: @eriksencosta



--001a1136a478e7ed9304f1994767--

From bcampbell@pingidentity.com  Fri Feb  7 11:44:32 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4961A04F5 for ; Fri,  7 Feb 2014 11:44:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.912
X-Spam-Level: 
X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hC4mxejk_cwA for ; Fri,  7 Feb 2014 11:44:30 -0800 (PST)
Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFDE1A0420 for ; Fri,  7 Feb 2014 11:44:30 -0800 (PST)
Received: from mail-ig0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKUvU3nqIwKw6F5ihVo9MivEONUxMWPDAd@postini.com; Fri, 07 Feb 2014 11:44:30 PST
Received: by mail-ig0-f180.google.com with SMTP id m12so2508475iga.1 for ; Fri, 07 Feb 2014 11:44:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zw6nqzaCk/xFS0vgJ1yBsDLlLbcEhsMEsOTaAGw4V5o=; b=CpftfQyErictVyPoZKgdBG5WfTFDUcQ4IpNvRXwHJn3NhS4iUGuw4x0M9AsunyNXZb kawCYT24ZBj6iWRQLBL8yhw59I7xqWkH3ED4eqpBU29f//URPWf0qtYwg4uMHehmfCBh 7knvYDXV32ciZ8/Y+xY0WMdOcHE5+faxNRR4SPuMhxmpmK0ejAM44fDTJMaNbpD+hHrl yGagZH27wRN0kbsuH0YjE8bP6uywCB2G1tnFQIMmZDb4MY5M9Jceyn6osDpkEM+egiDf +05keimpWnY3GJTtQ+t9dGI+s8R/a4O+UiyBULXp9uV8CDuH9M0Cy7gtzjrEw3OuCBn4 4HMA==
X-Gm-Message-State: ALoCoQnqZBAFfoef+z6I+Byohu+1/EmZ9huKz92TBnPXMmakT7K1B5mBGIz8HEQV08txpoJDLmTR3ryCRBR/hRzBZE35Z3oC/e+IWjhSEDZG2M04R6X8k39fUD3ZJwffKFf5u3cFywlLAJFRE4NisbLJatlxaktNFA==
X-Received: by 10.50.194.131 with SMTP id hw3mr1909920igc.4.1391802270173; Fri, 07 Feb 2014 11:44:30 -0800 (PST)
X-Received: by 10.50.194.131 with SMTP id hw3mr1909908igc.4.1391802270037; Fri, 07 Feb 2014 11:44:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.65.4 with HTTP; Fri, 7 Feb 2014 11:43:59 -0800 (PST)
In-Reply-To: 
References:   
From: Brian Campbell 
Date: Fri, 7 Feb 2014 12:43:59 -0700
Message-ID: 
To: Thomas Broyer 
Content-Type: multipart/alternative; boundary=14dae9340f79e7792204f1d63709
Cc: "" , OAuth 
Subject: Re: [OAUTH-WG] Another question on RFC 7009
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Feb 2014 19:44:33 -0000

--14dae9340f79e7792204f1d63709
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks, Todd and Thomas, for the responses. After some internal debate, I
think we are going to treat it as an invalid token (which it is in that
context) and return a 200.


On Fri, Jan 31, 2014 at 11:19 AM, Thomas Broyer  wrote:

> FWIW, we return unauthorized_client.
> Le 31 janv. 2014 18:06, "Todd W Lainhart"  a =E9crit=
 :
>
> > ...what's the intended way that the "request is refused and the client
>> is informed of the error" when the the token was not issued to the clien=
t
>> making the revocation request?
>>
>> We return an error_code of "invalid_request" and an appropriate error
>> message.
>>
>>
>>
>>
>>
>>
>>
>> * Todd Lainhart Rational software IBM Corporation 550 King Street,
>> Littleton, MA 01460-1250*
>>
>>
>> * 1-978-899-4705 <1-978-899-4705> 2-276-4705 (T/L) lainhart@us.ibm.com
>> *
>>
>>
>>
>>
>> From:        Brian Campbell 
>> To:        oauth ,
>> Date:        01/31/2014 11:58 AM
>> Subject:        [OAUTH-WG] Another question on RFC 7009
>> Sent by:        "OAuth" 
>> ------------------------------
>>
>>
>>
>> Greetings WG,
>>
>> In section 2.1 of RFC 7009, it says:
>>
>>    "The authorization server first validates the client credentials (in
>>    case of a confidential client) and then verifies whether the token
>>    was issued to the client making the revocation request.  If this
>>    validation fails, the request is refused and the client is informed
>>    of the error by the authorization server as described below."
>>
>> The only error described below is "unsupported_token_type" which doesn't
>> seem appropriate here. The errors in
>> *http://tools.ietf.org/html/rfc6749#section-5.2*are referenced too and, while "invalid_client" seem=
s right for failed
>> client authentication, what's the intended way that the "request is refu=
sed
>> and the client is informed of the error" when the the token was not issu=
ed
>> to the client making the revocation request? None of the defined error
>> codes seem to fit.
>>
>> Furthermore, wouldn't it be better to go ahead and just revoke a token i=
n
>> the case it's presented by the wrong client? I seem to recall some
>> discussion around this when 7009 was just a baby
>> draft-ietf-oauth-revocation and, while I don't recall the outcome, I was
>> surprised to look at the RFC again and see the text that is there.
>>
>> These questions came to me by way of a developer working on implementing
>> the RFC. I didn't have good answers, beyond the prognostication herein, =
so
>> I thought I'd take the questions to the WG list and the document authors=
.
>>
>> Thanks for any clarification,
>> Brian
>>
>> _______________________________________________
>> 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
>>
>>

--14dae9340f79e7792204f1d63709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Thanks, Todd and Thomas, for the responses. After some int=
ernal debate, I think we are going to treat it as an invalid token (which i=
t is in that context) and return a 200. 




On Fri, Jan 31, 2014 at 11:19 AM, Thomas=
 Broyer <t.broyer@gmail.com> wrote:



FWIW, we return unauthorized_client. 


Le 31 janv. 2014 18:06, "Todd W Lainhart&qu=
ot; <lainhart@u=
s.ibm.com> a =E9crit :




> ...what's the
intended way that the "request is refused and the client is informed
of the error" when the the token was not issued to the client making
the revocation request?



We return an error_code of "invalid_requ=
est"
and an appropriate error message.














Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-9=
78-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.co=
m










From: =A0 =A0 =
=A0
=A0Brian Campbell <bcampbell@pingiden=
tity.com>

To: =A0 =A0 =A0
=A0oauth <oauth@ietf.org>,


Date: =A0 =A0 =
=A0
=A001/31/2014 11:58 AM

Subject: =A0 =A0
=A0 =A0[OAUTH-WG] Another
question on RFC 7009

Sent by: =A0 =A0
=A0 =A0"OAuth"
<oauth-bounc=
es@ietf.org>









Greetings WG,



In section 2.1 of RFC 7009, it says:



=A0=A0 "The authorization server first validates the client
credentials (in

=A0=A0 case of a confidential client) and then verifies whether the
token

=A0=A0 was issued to the client making the revocation request.=A0
If this

=A0=A0 validation fails, the request is refused and the client is
informed

=A0=A0 of the error by the authorization server as described below."


The only error described below is "unsupported_to=
ken_type"
which doesn't seem appropriate here. The errors in http://tools.ietf.org/html/rfc6749#section-5.2<=
/font>
are referenced too and, while "invalid_client" seems right for
failed client authentication, what's the intended way that the "re=
quest
is refused and the client is informed of the error" when the the token
was not issued to the client making the revocation request? None of the
defined error codes seem to fit.



Furthermore, wouldn't it be better to go ahead and=
 just
revoke a token in the case it's presented by the wrong client? I seem t=
o
recall some discussion around this when 7009 was just a baby draft-ietf-oau=
th-revocation
and, while I don't recall the outcome, I was surprised to look at the R=
FC
again and see the text that is there.



These questions came to me by way of a developer worki=
ng
on implementing the RFC. I didn't have good answers, beyond the prognos=
tication
herein, so I thought I'd take the questions to the WG list and the docu=
ment
authors.



Thanks for any clarification,

Brian



_______________________________________________

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







--14dae9340f79e7792204f1d63709--

From gffletch@aol.com  Fri Feb  7 11:55:58 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789B91ACCDF for ; Fri,  7 Feb 2014 11:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.324
X-Spam-Level: 
X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMvpgtM1yP9p for ; Fri,  7 Feb 2014 11:55:56 -0800 (PST)
Received: from omr-m03.mx.aol.com (omr-m03.mx.aol.com [64.12.143.77]) by ietfa.amsl.com (Postfix) with ESMTP id 779C11A01D2 for ; Fri,  7 Feb 2014 11:55:55 -0800 (PST)
Received: from mtaout-mbd01.mx.aol.com (mtaout-mbd01.mx.aol.com [172.26.252.13]) by omr-m03.mx.aol.com (Outbound Mail Relay) with ESMTP id 3D6DE7003623F; Fri,  7 Feb 2014 14:55:55 -0500 (EST)
Received: from [10.181.176.251] (unknown [10.181.176.251]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mbd01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id E3AC2380000BE; Fri,  7 Feb 2014 14:55:54 -0500 (EST)
Message-ID: <52F53A4A.7090600@aol.com>
Date: Fri, 07 Feb 2014 14:55:54 -0500
From: George Fletcher 
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Brian Campbell ,  Thomas Broyer 
References:    
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010108040302090304020507"
x-aol-global-disposition: G
X-AOL-VSS-INFO: 5600.1067/96458
X-AOL-VSS-CODE: clean
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1391802955; bh=ukTRjLDz4SOMfl2KibOpXzUSvK6+qclc4fEQHVGntQY=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=vpPQazdczNDk6v1NQPYl/IhodweBsmn1OEpfdwYb5GIICV54IetsLrAdsjas8xJPw 889NfW+Y6zAcrQbFeMu86dnnJOv1aQ1J14mRArk+iNNOiDe9RiO+lryH7kIaUI2TgR 0Wxm9LmW/kpkdKO9uw1J9/2MJqTnb5CRPeyhzlTU=
x-aol-sid: 3039ac1afc0d52f53a4a3f6a
X-AOL-IP: 10.181.176.251
Cc: "" , OAuth 
Subject: Re: [OAUTH-WG] Another question on RFC 7009
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Feb 2014 19:55:58 -0000

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

+1 for this solution

Is this something that could be clarified in errata as it appears we 
have three different providers with three different solutions:)

Thanks,
George

On 2/7/14 2:43 PM, Brian Campbell wrote:
> Thanks, Todd and Thomas, for the responses. After some internal 
> debate, I think we are going to treat it as an invalid token (which it 
> is in that context) and return a 200.
>
>
> On Fri, Jan 31, 2014 at 11:19 AM, Thomas Broyer  > wrote:
>
>     FWIW, we return unauthorized_client.
>
>     Le 31 janv. 2014 18:06, "Todd W Lainhart"      > a écrit :
>
>         > ...what's the intended way that the "request is refused and
>         the client is informed of the error" when the the token was
>         not issued to the client making the revocation request?
>
>         We return an error_code of "invalid_request" and an
>         appropriate error message.
>
>         *
>
>
>         Todd Lainhart
>         Rational software
>         IBM Corporation
>         550 King Street, Littleton, MA 01460-1250**
>         1-978-899-4705 
>         2-276-4705 (T/L)
>         lainhart@us.ibm.com *
>
>
>
>
>
>
>         From: Brian Campbell          >
>         To: oauth >,
>         Date: 01/31/2014 11:58 AM
>         Subject: [OAUTH-WG] Another question on RFC 7009
>         Sent by: "OAuth"          >
>         ------------------------------------------------------------------------
>
>
>
>         Greetings WG,
>
>         In section 2.1 of RFC 7009, it says:
>
>            "The authorization server first validates the client
>         credentials (in
>            case of a confidential client) and then verifies whether
>         the token
>            was issued to the client making the revocation request. If this
>            validation fails, the request is refused and the client is
>         informed
>            of the error by the authorization server as described below."
>
>         The only error described below is "unsupported_token_type"
>         which doesn't seem appropriate here. The errors in
>         _http://tools.ietf.org/html/rfc6749#section-5.2_are referenced
>         too and, while "invalid_client" seems right for failed client
>         authentication, what's the intended way that the "request is
>         refused and the client is informed of the error" when the the
>         token was not issued to the client making the revocation
>         request? None of the defined error codes seem to fit.
>
>         Furthermore, wouldn't it be better to go ahead and just revoke
>         a token in the case it's presented by the wrong client? I seem
>         to recall some discussion around this when 7009 was just a
>         baby draft-ietf-oauth-revocation and, while I don't recall the
>         outcome, I was surprised to look at the RFC again and see the
>         text that is there.
>
>         These questions came to me by way of a developer working on
>         implementing the RFC. I didn't have good answers, beyond the
>         prognostication herein, so I thought I'd take the questions to
>         the WG list and the document authors.
>
>         Thanks for any clarification,
>         Brian
>
>         _______________________________________________
>         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

-- 
George Fletcher 

--------------010108040302090304020507
Content-Type: multipart/related;
 boundary="------------050503040205070603090907"


--------------050503040205070603090907
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1 for this solution

      

      Is this something that could be clarified in errata as it appears
      we have three different providers with three different solutions:)

      

      Thanks,

      George

      

    
    
On 2/7/14 2:43 PM, Brian Campbell
      wrote:

    

    

      
Thanks, Todd and Thomas, for the responses. After
        some internal debate, I think we are going to treat it as an
        invalid token (which it is in that context) and return a 200. 

      

      

        

        

        
On Fri, Jan 31, 2014 at 11:19 AM,
          Thomas Broyer <t.broyer@gmail.com>
          wrote:

          

            
FWIW, we return unauthorized_client. 

            
Le 31 janv. 2014 18:06, "Todd W
              Lainhart" <lainhart@us.ibm.com>
              a écrit :
              

                


                  

                    > ...what's
                      the
                      intended way that the "request is refused and the
                      client is informed
                      of the error" when the the token was not issued to
                      the client making
                      the revocation request?
                    

                    

                    We return an error_code of
                      "invalid_request"
                      and an appropriate error message.

                    
                    

                    

                      
                        

                          

                                

                                

                                Todd Lainhart

                                Rational software

                                IBM Corporation

                                550 King Street, Littleton, MA
                                01460-1250

                                1-978-899-4705

                                2-276-4705 (T/L)

                                lainhart@us.ibm.com		
                        

                      
                    

                    

                    

                    

                    

                    

                    From:
                           
                       Brian
                      Campbell <bcampbell@pingidentity.com>
                    

                    To:
                           
                       oauth
                      <oauth@ietf.org>,
                    
                    

                    Date:
                           
                       01/31/2014
                      11:58 AM
                    

                    Subject:
                         
                         [OAUTH-WG]
                      Another
                      question on RFC 7009
                    

                    Sent
                      by:    
                         "OAuth"
                      <oauth-bounces@ietf.org>
                    

                    

                    

                    

                    

                    Greetings WG,

                      

                      In section 2.1 of RFC 7009, it says:

                      

                         "The authorization server first validates the
                      client
                      credentials (in

                         case of a confidential client) and then
                      verifies whether the
                      token

                         was issued to the client making the revocation
                      request. 
                      If this

                         validation fails, the request is refused and
                      the client is
                      informed

                         of the error by the authorization server as
                      described below."

                    
                    

                    The only error described below is
                      "unsupported_token_type"
                      which doesn't seem appropriate here. The errors in
                    http://tools.ietf.org/html/rfc6749#section-5.2
                      are referenced too and, while "invalid_client"
                      seems right for
                      failed client authentication, what's the intended
                      way that the "request
                      is refused and the client is informed of the
                      error" when the the token
                      was not issued to the client making the revocation
                      request? None of the
                      defined error codes seem to fit.

                    
                    

                    Furthermore, wouldn't it be better to
                      go ahead and just
                      revoke a token in the case it's presented by the
                      wrong client? I seem to
                      recall some discussion around this when 7009 was
                      just a baby draft-ietf-oauth-revocation
                      and, while I don't recall the outcome, I was
                      surprised to look at the RFC
                      again and see the text that is there.

                    
                    

                    These questions came to me by way of
                      a developer working
                      on implementing the RFC. I didn't have good
                      answers, beyond the prognostication
                      herein, so I thought I'd take the questions to the
                      WG list and the document
                      authors.

                    
                    

                    Thanks for any clarification,
                    

                    Brian
                    

                    

                    _______________________________________________

                        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


    

    

    
-- 

      George Fletcher

  


--------------050503040205070603090907
Content-Type: image/png;
 name="XeC"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="XeC"

iVBORw0KGgoAAAANSUhEUgAAAWcAAABxEAYAAABZ0L78AAAABmJLR0TIyMjIyMhnRJJpAAAA
CXBIWXMAAABIAAAASABGyWs+AACAAElEQVR42uzddYAUV77w/W9VtY67MoO7u7u7BQ0SHEIg
BBJcQkKAQPAkaAIJrgkOwd01yOAMzDDDuLV31Xn/uJedfXZvns1u2Jv73Lc//wxdXfWrc6rr
NL86deq0dPHixYsXLwqBh4eHh4eHh4eHh8dv0r35R82aNWvWrPlnF8fDw8PDw8PDw8Pjf5ZL
ly5dunQJ5D+7IB4eHh4eHh4eHh7/L/Akzh4eHh4eHh4eHh6/gydx9vDw8PDw8PDw8PgdPImz
h4eHh4eHh4eHx+/gSZw9PDw8PDw8PDw8fgfdHw1gszkcdvt/vpABJzpSQApnu9QQxBgpQgoA
ba+rhDMCiLMUs60FUcbSLb0C2Gu9TnnhA/rVQYEBh8FoDbkSPQPcncwHzedB+ZhzxiMgfUsm
W0FdKBfXvwTpgPXnrC/B1cmWkTMUjGdCr8T+AGKsPd6SAs73n+y/NRPESrmhshe44/5GHQLa
y9zlWYtB3S+NVjqBZlXvmwuB7b3sua54sA7PLZO9D6zF8qJzh4E1xd5fzQGLrzPTfgEsT20x
uevAMcgx2dYL9E981wbYQRrvGxaQAZakrBPZ2ZD3TTZpPcHdWVotVwRRjc66aqDN8P4+KAbs
+6xW62FQAk1FzHcge2KmV+bX4HUy7FZUNmiJyo8+z8Hs4x3ruw2EicfGSqBfZtwg7wP1c3cD
7ReoObj2u+UbQ02pUvHIp6CVdi9w3wFprWhHNIhAKVRcAKkJZkJAWHHjBkD6Pz5Ihf+YkvAO
EjIQxCd8ArovpEXKIHh5Jfl++jrYv+5Ux4trQRj1T92joffkpjMbNQHXRHmRFA3aTjETb/B/
6v21sQDIi6VAeRforph6mI/CsenHU/Y3hKwCNrvaHh4lpSy8sBh8XofOzOsNjvtJXsqvcD/u
VZmna0C6omtv3wA5zdKmicuQMyhvrN8n4HtD96XhNoQuCUwpeBVKbC+cW2Yt2Lo7xusWQHpk
SrA1HGIbh38jhoHtYzXXMgkKHfSyRteAgP4FP42eDtZmtsfpn0FAoFen4D1woUncp3u3g+0b
tVtaExgY1XLQ9C/A+YPcXXkfym0s8X74Bnj46ZNluRVg/5gLx5bMhBw/m+VqD/DpII/yD4DU
uymV/Hxh7p1Jsctn/NnN3MPDw8PDw+NteHs9zjICDciWTAQAddDEOZAWi1dCBWmEuCH7A3b9
JnEeXPfTFyW3AGOQXwGfc6AFau9r1YCmulLmr0B/TlZ9ToMWIOLUpSAsYrorGJSrUpSoA5z1
eRnYBQyf+yYGvwfaJPd7zvPAMVFPqwZCdm93NAGXX0pA/C5Q37e+l9kJ1BGu5vaPQMzNTsmd
CM7h2QczroF0XnmizgSRpLsq9wBlleG2YRgYGpiy9fPA2+V91XwAzIfNK72qgeF93Xj9C1C8
3RnOD0DvEoprBJhWmy7oS4LyjhQhh4C83n3cHQRaJVdlezFQuqgfOOqBPpkJ7hAw9dZ31SaC
Md3L7rMWpFHOuo7u4DvM+5B5Eoi9anlXcwhZGdYt6BR4L/E7GGECnY9ep78JD0fE5T0/BJYp
lip2DeR3lXHiV9AGSp9JYSDNZTsRIJKlYCwAiL9Jmf+DCgigmBSOAKkWdaV14GojXrifQIGZ
kb4B9aG/pUP3Zvuhwb6KqWW/g5CfQggywoUh1/S3P4X7w5+2uVMNcmIyB1kCgGvyArkLGDoz
VloG5sa+r6JGgxKhlHboIOx1wFc2C9iVHKH3hmp9S25p3xoC8qSkosch+1D6nuAM8B/mVT24
AhTuENy96Epw5TqLFZMg52yulcdwt8gz5ZYeCs+PrOvTFoo4oyzlKsD1SfcOZI2C147MjVnT
QbdHGvmyHvhslWu4voFXNVP2P/4ebpS/W+unmaB9Y2kTWBgiIr0add4MuhbGvrrB4HPSPFoX
CymulG+ynsOvHz3xP3IJsptn931wDNxtcjPy8iDjdtLorMJgHW1/7j72ZzdvDw8PDw8Pj7fp
D/c4/4ULCQFSYWGXQkBc4JFYBFo96bb4HOTK+sXKGVC3WRJtlYHL8neGWSDPNnTQzQFlgjJM
vQjittxH1AJtkNxfKwNShFihGwMiUBMuPUhjXPMtQ0EqrZ/kNRjUz8XHbhto5RIbPqgBWrLj
pmszSL/K83RrwHDae1jgFHDtt5yxpIJ0yl1ISQB3oKuvazy4P3I0dHwKapTSQtQDw3x9K70X
GDb7mH3rgRxrH+GcDiiOW/a24DNPai2dAOmsbJOMoM5xT3SUBv0D+SJB4Nwij9EGgHmMl9kc
B4zLLWD5GdTK2hRtOojFdnNub5DWayHKUnCpFlPOJ+Bd1DDQezmg4HB/ANpx2/qMzwGDfFkf
C7ahefLrGqBf5HUgNAj8U4KKBs6E7NuZ9syF8Gzsi08zQ6DS0TItw/3B/dw9WAPoL3/AXEAT
6dJCQEIW8fxHkvx/JtASBkAT8VwG8UAqx08g3RXLFAtoeWojbRbYHlFLewHF7YVGx5ghqXv6
gZSyULNn+R3FukJEr6D08BSwa+p+92nI+iXnjvMruDc6vfCTHyDjS/tPL0vDzcvx0Xc7QdrX
lqQ0X1Dv5s7NTQe/cH2xm5mgTwtY71oDjRcX7lShBrjLa4XkJDj94e3Tj0wgb9Z9H1YZpDKk
GBOh0abKZZv8DJXnFPKt+gpybkcfTjoPDT6vLXXvBXc/i3v9+BU8bHzPsvUlPA12rHVegKzn
+uCnQ8F3DqppBlQvXu5co+oQ+FF0WmA8BLYJDvTtDBmLXg/L/hjSVmcbxTJ4surh+8lVQTTU
Dpkngr1udlbMF+BOUv1ykyCrNNdffgRAgz+7kXt4eHh4eHi8HW8vcZb5j2QsgBxMwD6pGU9B
11KMpCe4Q7WrLgMoy8VpcQ2UG0UrFM8D9Ssxz3UTlBOuXtnvgvhYP8DkD/JTLU10AVFbbqvr
C1J/OZFZoCXkTc5UQLtg7ZjSCXS79ZW98sD+Qo0XI0Hrmzo8sTm482zz7FnAFGmZcg3kfkpT
jgIxhrG+t0F3TzqiLwu+u3w+VIqAs51zl9QdXIW1EWpncC9Qi+ELhjVimzEd3H21QeIGaA5C
pcngU8ynqq4POHJsy3O+Bfmqa7s7DbxLKXvlpyDfNl82RoNcSM2USoK0ylHT1Qhsu1wt7UWB
jVIfpSU4JuXpLbdAn6pXcw8At7zOhJQHY3d379yh4DrqeMETyHbnvpveHbyrBA9I/xz0ZSK0
UgfBd47/+oCf4d6Sh4mJraHUsiJbQ0qC7nOdj+gA6iTxgWwEua7kLX4BcVtYUQAFCe3/+AQF
LkDgT2FguqgnXoDcTFYYBHnxeZPsNeHS5BuVb3SFpDJZpxLuQF6dvFdaJ6jyuuL7JSeBqadX
w5BweL4oqffT3vCdbf8P23aDrppuv3ULuCfrv07rC0V/De4TkwJ3v3h6128hOHe7C9tegO+1
5Bp3KkFUaGCb0p9C1lFHi3Q/KDwuaGnDb+DlyNe1DkyFd9c0d7foDX5pjk2GsVA2trR3kZUQ
VyIx/aEfvExO3BOfCZab9u8sveCZ7XWRw5fAvVbMVY5BYDlbWtIFEBtt6yI/h9J1y8SUXw4h
wSEj/U6D9y86zfYQktclXk3TQfLmrGUvjsELOSnqyRcQEh9xkV8he8XTiIxVwH69QzoI2aWz
Thi7gHzbr7P3BKAGY/7sRu7h4eHh4eHxdrzdxFkG8Ri3eAVSOaJJA2FnmhwG8gf0kuaCqOLT
07wNpIsc0k8EeZBsk5wgPzS0jQoGKQi9LgfELPzZBpJbHBG7QRtnTUhdADzRhfgGgHzR62LQ
l6AG5nR7OQwki1RdrQuKGlQ+cgZoPyRZnmeD1szdWJ0Eyh1vW1g8cMOkel0HkWH9Vh0Porz6
qbwQDDbphRYHUpSWqyWDlOco5LaAu4A8zLUUlIZKBTkTdAc1qzIFpOfikZgNQlJm6EcAp6gt
WoM5U3TW2oCaRDe5FMi9zQ9Nd0Ceq3yr8wHctghRB2zt3O3UGaClSuuVT8GeZAm1zwXDSdzZ
q0FZp/uYZ2B+Ynhs7goZMZmrLEVA9z3PtXWQY5O6GKPBLzj0cawEecNsbd2X4KU+Qc6YDcXb
FB8QWgnUNMcvajiIJ9J8AgE78F/9wLoEaICKJhUGaRefi5UgDms9xXdgPmpaaDRBi9C6j2qt
gUPNz+29NRJ2HDy7aus+OMydxae6Q81rxUaU3gi65pLqb4OYkf6FI45B2Z1FaldaCqnFrF+8
uASv5PTQX2pBaIPAl64i4DwvNbItgcA65lHm90Hxzb2TnQZxJ14Pc/cBi7etzKmbUHZpgYKR
dyBhd8alu+kw6GS79/uGwapjm/Q/h0FaL/uaBwOhTnzJUp1Hw6OPn6XfvQd5FcU+78MQPdin
n+4S2JvmVPV+CaW9ix2p9gtUXlbQVHIVmH8w6ryt8HpJcs3Mp/C8ZPLu6zth/7VrE3fth7D7
/jpXOWh4omhIy2kQlRL4SR0LGH8xlZZqQPbLwB6WlfC6ovVMQq1/Q4utQhWqwKHZh2Yfmg3b
ArcFbguER40fNX7UGNTl6nJ1ORT9suiXRb+EDvs67OuwD7qkdUnrkgZKDaWGUuPfUC6P/6tq
1apVq1btn99uUotJLSa1gK6zu87uOvvv4xw9evTo0aMQEBAQEBDwx8v5ZNuTbU+25b8uVKhQ
oUKF3v558++uh4eHh8e/y9tLnAUCGTBKYaSBSBAPpY+AI8wWn4DUVzkn1wAmSJP8QkG7onbJ
2whKnlRXqQ2MkuqZRoJ4JtKkGUBz6TSrQNyWNmhnQYowHPGuDnygbDEVB+2S8/Ocn4A5Wqj4
AOSC/iLYG2RLpLc5HeSVerd8ClhvmuG9BqSz8kZzKXB/mfW5ZSGIQQ4fRyOQBhjjlSSQVMcR
dxgovzhs6gZwRDpjXL6guhxXnR8CC9RNogLoJkmlFDNIn+smSL1A6muy+vQBkSY6aM/A3VAN
d2eDeaV6VLaC+6a+sDIflPm6C+o9kA9LTSQ9aOWt3Rx9QH3k3MVOMH6syzNPADXOVcUxEnK3
5o5IbwZm1WdwQEPwn+vv8t4KedNyOmV+BpRIC38+GhzTjFWMvmB47h8TvRker3oRnf4dFDlZ
ZHdoBEg/SFdFVeCyiJPLA+WQxAvACx0BgB0nNkCgYQIpStKjgTggbiOAGPrL90CpqntfzALX
TlcB568QPMhfUitDY5+KjWLXguVDw/Inx0BXWzsaNwqkJtmplTKh6oBy22pWgh8ifmnx0xUI
/zB8gKk61BxZ5oN6Q6DN5+VOFZgND4tkT3yVAjvfO3zh+2pgGKfcSCkOtiZqsP8MuJn00Dvo
HgT0NKT7r4Q476fSpT2wrMfmDQYnhPQwdJKngK1/1vPgHaCWUkT6CYh6FbS66DHIG2Q5G3sI
LLKlwbkWYOrgJUt14Xqhhy0uroVHdeMNcSVAbmnO8jJD4vXXN5PWQWS695Pg+1A+LehAs6vg
XzSkckI/CHQV6FBqEWjNdKVSnoG1vbraEgD6MLH7/mZIK5eWmHwegOJvs8HOOzHvxLwTsK3p
tqbbmuYv17v1br2bvyTW973ue933gvvd73e/3x2uNbvW7FozmDt87vC5w4HrXOf6W/428fjd
wqaFTQubBsoIZYQy4rfX8xrjNcZrzH9fuXrM6zGvx7z8139JaAkg4M86WB4eHh7/g7y9xBn+
oydTLwQ+QCZPuQk8xyJWAuWJkMwgwrUMbQxoC9y+1lEgTZAPmC0gzTDu5yuQForF6jwQGYSK
YBAGubKuCkjVbL1z8sAt09JqBGWW1yj/fiC1Cbjo3xt01+Rucn8QG9wztM0g7SxaJaIsSKV1
pXSFgZ7qOrcFlOoyiXXBcdg1K+0dcEVm98+NA3ea5aA7GGzVbNfsfcG6zPaN9QW4A9wZIhek
ZdI2XUtQlshn5PlgrG+oZBwAoqyhjzQQHONdqa61IB1W57jrgFpBK6GEgVRb6yQagOyUHrgb
g3uoc4QigbefyW50gHuLY5NjJ2iH3IVcv4K8XTdTPx/s8fbv1CPg0Iuw3FJgOu6XqXsFxrL6
X3WTQPF1KY4t4BiSOSHxCfhc8Z8btBVsJ201TGUg54vc8/YM8Mv2TTTcAnWnOlO8BBrhpC6I
ImK69j1IVmmj9Bw4Li2R8kBkESnuABq3KA6cpZl7BGinRbxyAuRzrDYWhfTOrzOzLeBfQp7l
NID6jtQwKxcyIrJUKoKqzx55NxMO5F45+fAcmF6a5LS6YHigz4goBJklcueYJ8KpNin7bBmQ
vDj9y5s7IDXX1T7NDGrHvE+FD5juazUyaoN23j44+QaIW6G9wipChbTogbXmgvOEbad7PWR3
kd2ujlDoUNSgOsPhYfDD3Yk/QkR48JLAppAyMHd+xlhIrW6JSGsFhm7WI85pUL1dmR5NTOB4
lJsU7AOv47Jbx/WAKQ17mgb6g66tfqL5A3jpSm2VUwHiDM+PHDkFv5y/OHHzRWj2RbWu7wwH
v68dx8IewdF6V6ZfrwW5C7WX3t8Bu/jqbTStkydPnjx5ErZ9vO3jbR+DsY6xjrEOzEickTgj
EZp+2/Tbpt+CdFY6K52FU9mnsk9lw7TwaeHTwvMToDO2M7YzNqhPfer/93zHePwXNjXc1HBT
Qwh4FfAq4NWfXRoPDw8Pj9/rbc7jLP3nrX6LVBDwksqJ7oCZu9IXIL2gtDIA1HDn9PQ6wDCL
Ked9kAWZuqOg9aOVHAnSKTGMrwAvab9yGChi751zH0jQ2cxPQFnp7RvYCaR6usnGPiAdpqmi
glZAy3NdBvWJ/Np5D+QN2mk2AOucs5zjQVQl0PU9uMIcL6xxINUQ99QpoIvR3TY0A/uVvF6W
XMiul56TNR8cmmWMUwNxT80Rt0E3Xs5UKoCXn+FXcyp4v28Y4lUc9K2kXnIiaBfFDeYB/ZUN
+l9AF2aIMBUB2knvyfPAPcud5XoH9B/oz8q/gLGx0aQ0A5/x5iTvu6D/RSlsCAKxUp2nNgT9
HmWVHADaFrfDoQeHj8UrzQ6yS77hNoO2X2qsHQb7+pxemQch43ZC8Xu7QM1xbrbtgrzPLfed
z0DaKGVLrUBbIs6pF0D3k5KobACzwTDaqwYoc2STcSmwSYRIXiCVF3OlvcBJ2mEFBolw+SNg
kTRMGgDZVXP3ZSaA+Zy5Bn6QW0gvUoyQNcxpyjgPzzNeHU5cDO458iRrX8j8wlU8+SwUXB8w
NGY3uKdaK/lLcO/d+F+vhcKhp9dbr/8IXkxP3fqkMDQtW3xd4/fBEC2Z/TuD9KthutYITFn+
LfVG8K3B2GqHwX2aqtlJkDvFNfXRaXj+dVKrlGhoVLWSJeIylDwXUDRUBt0h5Z2bUyE6POiy
4RgYxzm8g0dBu5J1slp6wVjfwYWHLIbgV2Hf+ayEppNrFqqyDySnz2oxFg70u3h0/0b4+cSx
5t/8CA+KvDC9XAVFZodXDz4Mj7Y/fH7qFCTbk7++2Rhq3CoxuXRrKHQ0aOOLJ2+vcW3ZsmXL
li35r4cPHz58+HBosbPFzhY782+lyyPkEfIIaPyo8aPGj2DCtgnbJmyD1mGtw1qHQd6pvFN5
p/4+fuKexD2Je2DcpnGbxm2C+vfr369/H+p71feq7wWfNPmkySdNIKl9Uvuk9v9FAf+zp/tN
T3inTp06deoEtWrVqlWrFnT8rONnHT+DreO3jt86Pn/9N7KysrKysvJv4b/5e7/+/fr360O3
zG6Z3TJh/b3199bf+/v9btiwYcOGDfnHo3lQ86DmQXCi+IniJ4r/fdw3+3tr9f8f4p+th3pZ
vaxe/u2hJM2aNWvWrBncMdwx3DH8/XHfPX339N3ToVuRbkW6Fcn/vJs/a/6s+TOYf3z+8fnH
wV7GXsZe5rfLfUO+Id+Q/z7OwEsDLw28BM+aP2v+rPkfr+8fPt88PDz+f+/t9Ti/GSObA4SB
VA8H24Fh9BSdQe0itZIXgAyPWQTqrZSnj1+C9tycHdYNZG/TF1I50OpTiTLAAHFdGgBSNX0n
b0DyNuyTeoL0UPtMew44tCB1O4im8gldQcBLOyf1A6kDVZX7QLJcRcoCRohRuiHAh6pLGw7S
Zp/+QTtAPzggK9wB4j3RX90EgeND24ZtA/OM9FZZMaAdtC23dQI5WZpMFlDCmWjfDbq2cjFl
Ddi93bHCB/LGOTq4GgPXXVXdgeDeqI11xoHLqV5SqwGPxSb1GCjlmco7IH2p/GhoDIY9tNFW
ABZzKFHg7uk8py8C9KGhKQuclV3fO+eCNleMdpYH903nYlsYaD+4Lrn9QTquK2EoA8Zu5iy/
M2B/lFkypR9YXmYUT/SC7K9zEqP6QqHCBZoHjwTlJpP0n8GLW1kBCVvA2tnaJuEJBFz2uuQ/
F0Km+lYo9jO4u7PHHQZSOZEoFwWENJJ+INXTQlkChhomnSEQYpdHJBXzAcs34oh4D5Kvxf3y
YgiEFgpYaSsEhsbe/VI1yAnJmGgPgAsLHw5K3Q7Gocaa2U/Au4TS1vsVmM9oU/RfQUhr0+kq
74L4QJkt6SFor1evoK/Aa7eSFXMY1OvuHOMyqLKwSpnSD0GJkjYUOgdnBp4rfW4SdPapltyi
O5RtWe1wqZ/hmeXl+ZxhkGZ9UUH4Q8Dp8F+iJ4JfuNfhh04wDDcN9Vbhhwc7XPtPwp0N8bUv
HYSslOx5AVtgbbv9WdsKQmBAYGff3lA8O7aN/0jQhufV1Jxgbua1L+Ip6Pbrrzoy4JfYy62O
VgZzcoDsvxjMNXVrAxv+8WYlhoghYgjc+uHWD7d+ACpQgQr5ieE/0j6qfVT7KGh/oP2B9gf+
/n3rIusi6yIYdmzYsWHHIDk5OTk5GeqOrju67mhwlnOWc5aDEzknck7k5A8B2ZK3JW9LHvj4
+Pj4+MD2Hdt3bN8B87rP6z6vO+gX6xfrF0MVrYpWRctPjOYPmD9g/gCQd8g75B3QjW50+7+U
f/y28dvGb4Ok5knNk5oDP/IjP+a/vzdpb9LeJFi8ePHixYvzLyCKxBeJLxIPM/bM2DNjD7CI
RSz699X/n/Xee++99957vz12uFSpUqVKlYIvunzR5Ysu/zjev1qPjcU2FttYDAp2KdilYBeI
3xW/K35XftwCBQoUKFAADA0NDQ1/dT7/9PNPP//0c375DDMMMwwzoKpaVa2qwtOaT2s+rQlb
Y7fGbo2F3CO5R3KPwGd8xmf/RfmnTp06depUiCKKKPIvAG+PvD3y9kj4zPmZ8zMnrGUta9/C
5/avnm8eHh4eb6/HWQMkkArgJg/EtxSkLYgazJe2gPwuYe6LIK+Vd5tvgHO+tbB1EohrqskV
BHJP6bFUFcRmkjgIREtVxVSQjsrPlEcgHovK4mfQmmrfaXuB+aRJeSBZuEoGUFeuoysMUlFp
qSEKtERtkKSBVF6U0MJBCZKijWNAmRm4xrsNUMYrUH0P5Cp+dQ0OMGthJ0zRYJ5nXuteDr6j
g/sqqWB86POVVhzsDV2jLUMhc2JmhdTDYHmaPfF1N1BfisKugqCtYLM6AlxLHENdX4L7M/Wm
6A/OQcIklQPxqVxM7gbKDXmlbimYvzJuNbSDgM982nuPA//Tful+48HU0ljd7AuGEX6Fg34C
bY22QnoN8g5RinjQrZbv4gViubuHUwdqZcf3uXnAJ8qHpvqQ9WuS/tEgSN+VXi+jBjxLebk6
eTEcmfLru9+1hA0nD/dfshGWfL/l8PeX4Ydjx6ZsrQgvBqaMSU4B/T6xUfctqHmiv/QpaG20
FIqBqb7usq48nAm9lX2lL9yomtDrYVtgmjtT+Rm8w5TRASvB7Otd1PgxGArrIxUbpE/NXJ92
DJQdyjTDIfCerG9UoCtYp1qmeQ+HyCyTFLMJArf4TdHHg/Erc+e8U9B2SY3x1fqBGsZ16w0o
e6hY34AOcLzB2bBrR+DQkcvvnz0JdWdU+LHnFTgz8Fbh1x/Dms/XHTg4Dp4Hxk+MGw/GUGND
H19Qy8rfODZD1cUlR7WeAmkZzxfkqXAh70bbs82gQXqVvKIHIWh0sLv4IjD3N+50zgJLRVuv
zEHwZPqz0YlTIM6W1u1BKJy7dv/6zpNwceRz96654IgWpdTT4BpgK5x5FZ4vSNYrv/zxZmVZ
ZFlkWQSuCq4Krgr5y0NCQkJCQv5+/YWWhZaFlvyHyf7279dff/3111/nr38w9WDqwdT8xOOd
d9555513YEm/Jf2W9IPll5dfXn45f/mb9fZ/tv+z/X+VAa2/v/7++vv5r98MIfm24rcVv60I
08Onh08Pz39/U6NNjTY1+sf1r/dhvQ/rfQh72u5pu6ctdD3c9XDXw/nv/3jvx3s//lWP4JsE
bLPvZt/NvjBUDBVDxW/Hf1v1/2clJCQkJCTkJ6p/+/fNfn6vf7Ueh+YemntoLuycvHPyzsl/
H3fdunXr1q2DEgtKLCix4K+Oe70f6/1YL//1zPYz289sD98M/GbgNwPz7wDob+tv62/D4S8O
f3H4C7Db7fa//GDWX3nzEOT2p9ufbn8KS8suLbu0bP779+rdq3fvr/b37/rc/tH55uHh4fF2
xzjLgBtFPAVCyMQOKOwmE8Qz7Yi6BMQ0Md3ZEQyz/GaEDQLlU6WtXB7EQtFXfAxSipQhVwEG
iTvCDuKpeCC6A1dpKp8GOUSxEwzMYZ0YDNjFE60SEI1QBoNUVNQXLYH78nvqWNC6UF7eBtJy
eoqRQIOsEokaWLWnPe/eB6c1c312fbDUf9ku7QPQWusivX1B+9KU6X0OrO/mtlWXgTinjTEU
BNmg62FMANdwtZrzJZAlXbP7gOsUYUpdkE4F6H36Qdr5XMmaB7mROVnpg8H+Re7ynKPg+5lp
oNdYkKrIC+WSYApUlujeAbm77pTSGPSy+ot7Gth76p36wuDeytfiOhjXu2c5WwG1lLJEg4hx
v5A7g+O284F1PJg+0s83xoISr2UYd0LeqKxjuZth64r9z84fhztXMq6uqQVeJw01iv4KSk91
bmxruNH7bvlLn4B1rD3P8Q1M2Ndj8MyiYGgnj1G6gtJC11NbB/dKJaY8mgW6ccaSGYkguzXf
rO1wZ/bz9TduQOpFu3fqAghvpfMNjAP7xLzJ1mNg/NbntnEVBOR67XLNBK/a6n79ZnCc0x2w
fwKmk2EOaQAYZpkmqgmQ7G05nFgFchLcqa9eQA2fYmrr3eC9XrfX6xzU7li+293DcLXLrwds
N6DqxBoFDQ3A2Y/JJUMgwNe0J8Ufis8vV6JmJux5duzp+qag+4TotATIft/wuIkRXD1tv4rX
UOhCeP0i1SDeN/G4tTecSXpY6roX+IeYTxungeOqrXDqdNAOqDMN08C/p88hS0Nwl8uc4f4Q
0pe5jKbp4Lqom6odhazOjvOZ5SCvoLW8sRUAWX+kSZnvme+Z74G0Wlotrc7vgc7sltktsxuE
/hT6U+hP+eunxabFpsVCfOH4wvGF/z5eWru0dmnt8l/f/eHuD3d/ACKJJBJ27NixY8eO/L+/
5c12tiRbki0JXt1/df/VXyXOjcY2GttoLNCKVrSChhsbbmy4Mf/9l2Evw16G/XYi9cbI70d+
P/L7v+/ZfbPd397Cbzah2YRmE4D1rGd9fo/7Yhaz+P9Sj3+1/sxjHvP4p73tWST+u+rxZsjF
m8/vjdqG2obafzWUI7hFcIvgFnDBecF5wfmP49b5tc6vdX4F2tGOdlCse7HuxboDQQQRlD+k
5G3Vt+XklpNb/hcXCr91vnl4eHi88TanoxPIIJ5JESSC9Kn4VuoBoqDUXmwGLYomcgJIn2vF
rUkgjwy6Gx0Iak/RUt0HuuFsZSGIU2TjAg6QKh6CtIMJUhqI9ySj0IGIooEcDBQTA7XZIK2i
Gg+AOBaL/UBleRkLQZSyz8vdDlzXv/AuDLKqDJH7Qm6RJ8GPykCK7kSvC/5gW+80iWVgX2n4
2TwW3L/IP9oagUFVfC0xYDro/VGgP8h19KOlOSAFSDrtOSguqZnuErjXqN8bvgFTYb9vzV9D
ZowtMasX6ErnDc0eABELjdfNZ8FWwf2BKADSD0ph3SXQnotQEsA6yOKdVxXs3bMbZE+F3FG5
X6Y9AdtCr42+7cDxjru7+zmIwS5dXk/wOmuM8n8OIlaUVweCbjY+fArG0Y5HVkBpLS9xBYKu
iL1f3hcQXNivcGgt0I1+9bBcMyBd65b6FUS8G2p0jwfXdePHLz+EZ5sf1LXHwNfr18/7oTkM
Ot5lV5eykNwq6X7OKrgWkRR+MwqOfffMZ84j8NsilgUVhsx7aU0cQ0FpqNyV50FCqDRQaQ2m
NF1NcycodbrkV+bLkNUoda/rZzBeCJ2eGwel64iCqi+8eiepzqv5YEyS9uqDwXeYj7nAM3Cq
tqvKHWi2pH5Wo50QMMMnOLAwvLqZsT70GZScX6Cdbie80r88ZxkJTc/WTi20CR5EPegnn4eK
Y2vMLvUZWFc7vnq3PlztHjfh5TQIrBxy2W82PNbiZl2NglZbm63ptxQONrgy8E44NKxUtJTe
Dg8/Tyh5vz94TTOP890Pyn5d+kMZQjvoN1saQUo3XUnfa6ANE5O9w0FapV7P2w2yW1nCFghu
Z9oq6gBn/lizenMrv/S50udKn4N73OMesG/mvpn7ZsIABjDgr9afnT47fXY6zGY2s4F9+/bt
27cPPv30008//fTv49vP28/bzwNd6UpXCJoUNCloEvg+8H3g++C3y2VaaVppWvn76yFdl65L
/9UsHm/GOp/nPOf//u3fSmC05dpybfl/sXyINkQb8lfHb7gyXBkO+OGH359X/3+3/656iKqi
qqgK3Oc+f3WhpNPpdLo/8L/Jm6EZf/Fm1pdmNKPZf199PQmzh4fHP/I2p6OTEECgSCcI+BmZ
OOC2iJbagRTEV1pxkFuaKwZ/D2K3XDjvOLBIVGAvoNdmEAk8ZBIHQYwmQEhASyLkxSB9r83R
DoE4JYzaUKCjMlbuCyJJtJUSQVrIKW0IiA+UGOMzEBOsiVnXQOuf1zu+Pkg/+A7zfQ7Wx9fu
3wgFscO3kl8/cKao2/X7wXo6vVW2FSSH1DevGTiXCsWyA7J0WTVSd4Fuhfy9NBF0D5QbBm+Q
AuX5us/Ba5bv84BNoMy0tgyQwbQiLzpnIAR/Zy5hHA7uMF0L/UZQQuROyiGgr2uSqycYhsux
0iwIPmS45V8S3FHep429wXra+X3gL5C+yl5GfwNSvnHNtkWDvXha/9wjoH3jdjjqgylZumy6
CIY10jmxHbxuy+WU8mBs6nI7okFdcq/P1cHg6yg1vcQp8NscOdX1HqTMz57t8Abnqew+eVGQ
2yxJX/QylOkRU6/5YAj/zrdcgQ2wb+Wx1cc6Q+pV6Svbd/AsMWn6hTkQdNNviHEZFPoyqIGv
BZ67tVdSLDgtbo1tUJzQs1VOwoUVcQsv+EHCs4x71nkQsUBfL+ArCBsZtdr8ERgXyA3qfQN8
oqxJrgMJ47NrPGoCBQO8jkVPhvIzI4y1zkPC+le1Eq/ArUlZS19Ug2cfJtVJXQsFpxSODOkK
JX6IORVyDQKLB8oBGyGwatBa6wcgWsnddClQqGvpHwv1h7QPLB/JydDxZZvWFWbDoQn7CiqP
wJhsmmkbAfUCqw0qvga8LiubXT9BmQqlLoZ2A4fkOG8IhuPiUsvns8GxQm5j7g36r4x9pEeg
K+0clzsYwp/7NQqS4GWsvWLiNSi0zO+s/38MTWj5NppXj2M9jvU4BjOYwQxgVbVV1VZVg8Bt
gdsCt0G76e2mt5uen4BccF1wXXDB4j2L9yze89txC3Up1KVQF0BCQoLOMZ1jOsfAiK4juo7o
mr/ew3EPxz0cB8+fP3/+/DkUnFNwTsE5YO5t7m3uDZFJkUmRSfkPYZ1ceHLhyYV/6XDm5IKT
C04uANrQhjYQ3SG6Q3QHME03TTdNB3uWPcue9fuPh9d6r/Ve6yE0ITQhNAFSY1NjU2PheI/j
PY73gPZJ7ZPaJ8HBQwcPHTwEdKc73d9+/f+n+HfV480dDrazne1gvmu+a74LEVERURFR+UMg
3sz60qpVq1atWuXf+ejYqWOnjp3y4x3vebzn8Z7/c+vr4eHh8Y+83aEaABIqEuCSwtADu4RE
IZDtfKdrA2KoNNKrPiibDYuUlSAeCh/1c1D7kqveBemRtELbCnItsUP5CNgsMqRsEKWUrVpt
kD8UNdyzQJuv9pbtIDeTP5b0oJ0TE3RrQZmurXGdAVcD0VwNgDz/qzUvfQyijpjjOgHKlKgx
oT6QUzD+Zno5SL2Skpd5CdR+7qeOXyBvQtqx1Cnw9MPUPTmvIWe/bqWhEyj7jY28C0LIM/l9
YzwUCDEX9eoBunJmKWcmyKd0iS/bg392wAQ5BOzjxTD3GpAa6if41gZDReNKn13geKj1ohuo
reSGxo1g6GQ8aZwK8gW9QW8CKVxncn4NhgS/B4ZyYGokfRw8AZJy1KWWbqBVdUiZ88H7sqGa
SAdzTVFZqg7m1/IitR8oH8hz9NtAqnmnaNx5CDoQUMY1FPzejX2QcB7iE5LuvfoIcucY62V8
BuULlz7QqTb4T7UFFrsHv/omDr3/NaRkZ3W8Oh4M/qFq8m6QT0kfO3dDYG3fo74B4Hxg2yA9
A//Bhm3+6ZCb5pwrnBCSbT5pKAqRI7x3RauQ/CjeELMaDFVDVtg2QPbcxDOPf4bYIaHBIXHQ
q1ezZ71aweHHVxdsLgrPJ+Usf3QOki84SmctgrsDcuIv/Qi5uTlfG3dDUGW/b63V4dQHxycn
9IXsHyvvcKdDJ//m3SP1ELIu+J7vp3Bq4IUf7z+Hlg+aSOX94Nmsp51ed4G0+RkXc6aArqwh
QtsGAT0Cy/ilg9fx4EWKN2Q8Sc60BcI1x9WJtxvDs++y2z0WEDhKfzz0A7AcdG18ooDPQV2K
fRI4G4kvFBnydjq7ZlUG3wJax9B3IPeiMkhEAZXeTrNq+3Pbn9v+DJf2Xtp7aS8c6Hig44GO
MGvWrFmzZsFcr7lec71A9pK9ZC9wLnMucy7Lf8jsLz2xf9NT2GF/h/0d9sOGYxuObTgG3+u/
13+vh0fej7wfeef3JL6Zxo5rXOMarK25tubamkBvetMb+pXpV6ZfGfiy6JdFvywKM6NnRs+M
hj239tzacyv/4cA3+tn72fvZ/7lj8H/4zx7Jrmu6rum6BlasWLFixQqY1XlW51mdYVOJTSU2
lYBnQc+Cnv1fHqJ8W/X/s72teryZ5tBx3nHecR4+n/X5rM9nwdiEsQljE6DA9QLXC1yHvuP7
ju87HuYnz0+en5x/R2NP5J7IPZHwtMzTMk/L5Md5M8b+Tfw/vb6veIVnGkAPD49/wdtNnP9j
OjoXJsCEt3gOwC4tCdgqDacWUE7U0TQQ3lKclAqijLRGlwc0lyJFL5B2i4WcB3bJ8fIUUH/O
GfJoMjg6PNtz0xvk8UGBhd8DfbbpsUEF9y2bzv4u6L6PKFeqI2iy/lLwCdB1pJ5SGZxRrxdZ
G0HGw/RhL04A7pgn4d9Cwp6E5JTu4PjOcUXbD2KsOOoOAfu3tmWYwK+yd/WA6VCofeHqRdMg
OD7gUnQaeHc0fuVnAilel0MLcF3VTllPg83XdjxLADcs4bnRkLs541gyYNT79TLGgTHBdFhu
C7oHumJyC5BuyhN1P4J0hCJSS5BaipNSVdD1VTeqx4BY7ZJ1DHg/9x4oTwHvIL9UP29wn8k7
zjUwjBcRzqagX6DG2Y+A+bHjgHof9FO9OgQdBRRlfuZB0C4/6Z9+HdJiXAXkJqBPNrT17gHK
EktL90ZI6Gdac648EBp0yboavLZbqhTfDD5N/D/yiYJijUxHG5yEJn7VblSbAy/LWxs/2Agb
yx8vsW4DBHj5OEPPgb1S6lbpO7jdxOHy+Qq8C2jXa4yC2q3qpj1IhZQCyceye0HewNyx7lx4
uiNXf/4YqM2dx4xRUG9T6WeN+0Pk0kRHgfrgZ/RLCHkX0k0ptsRB4HO+zIRoL8hpkjc8vgSY
+puuWx6Be4EjPn0nbPl2d/Wj70EBQ0xMpC8UbxcVUGgBuBc4flZHQTm1zJyoMfC09PPDr8+A
92LfLw3FwVjQ3NI3EvRr3e1Fd8gW0gtnfTA8DChWZjS0kUuOq78ecrtm1UuoBC+mpaq2b+C5
nLMqzxdkbwbpp4LJkVfK8QNI/j4DcnPA7EWOKeIttq3/TBRnDpk5ZOYQqBxfOb5yPOyYtGPS
jknwtPnT5k+bg9FkNBlN0HJny50td8KYgWMGjhkIY+PGxo2N+/uwERERERERsHLFyhUrV8CS
skvKLikLF7+9+O3Fb0G6Jl2TrkGVSlUqVakEI6QR0ggJSllLWUtZ8+N0K9ytcLfCoH6sfqx+
DJtebHqx6QVc239t/7X9+fvp86TPkz5PoOuhroe6HiJ/TMm/aECFARUGVIC8Pnl98vrkT4+W
fC35WvI1mOI9xXuKN8zsMLPDzA7/vvr/2d5WPYYylKHAmvVr1q9ZDxcvXrx48SJYb1tvW28D
C1jAAuhxtMfRHkdBfiY/k5/B5i2bt2zeAtdWXlt5bSUEVAmoElAF+s3oN6PfDBgxfMTwEcOB
FrSgxZ9f37+djtDDw8Pj95L+44tRiJo1a9asWfOfD2CzORx2O3+ZVQMvwA3cwoIEYjFe0mmQ
z/Gj9A7QhZnuSNC+Vjc4MkCKl5vJLUEqJHsbewA3tEClPmjf6faJZqAuS71z6wRYR5waeuAl
iERdpH8vMJSOfBGWBaJYzv20uSAP9F/j2wCM06q07uIDSn3pfV0HyI4/Pe1SC0jt82Jo/FJ4
HJCge5QC2XMyX2gx4PxJ/U5LBsWuBtsfguFH2WBoABGNgzYEfQGRI2PnRX8KbFU+1llB+1ke
JY0Cd0vynJFAZUew6xOQu+gb63tCwKHYSwWLQuKhx6eefw3SJXmqPATETXmqaAX2Co4b9sUg
Yt0WdQlIHUU3uRZg1EzaDFDXO/bafgJtjvoVT8DxSJ6BBV4/t36SPRBsN7Pnp38O/uGGx1JJ
ME9wdGUzmMZoZQxFQW/3v+8vQJDUKzcMTDZ1qToEjo4u0/hlJsR9LW+/Vwn8BjjK+3wCWbvF
8SwNMt9Xd6qnoPAUn6SaZ6Ckd7hS4RjIY/WTrb+ArYYjQ78egtqb3hM94epPTyOuLofYRN9x
1edDesbrUS+vg/6ht6tAYUjZku17uyAULhTexN0PDJ/Kz4I+B26L4+54SF+f+SpjNIyu2n/0
1wVBv1pu7J0E8T6vVt9fDsdq3uq5Yz7oTzs3GDNALedcY+oJT1+8rpkhILJosK92CaRM02c+
ZvB/V/dd0fOgfWNvo/SGGi0qFaw1GEJ8Aj/w7gmRFwvcDWgOR2ynLj/4HrL6pZV5cR3qB9Y7
Wf5LcAQ4C8lHQAnQrZGWQundxb6I6Qy7rIe2X2gF26KOF9p+DMK/CwlwDIeM2VnVrfcgsqb+
ouUYSGO0s0ICERXtl54NMReje/uWhIlK7++OfvNnN/P/fd70qK+surLqyqr5y988HFj6TOkz
pc/A9WHXh10fBkOvDb029Fr+UJZzZ8+dPXcW9Gv1a/Vr/+zaeHh4eHj8T3fp0qVLly69zR5n
BYEAsiQvZJDqiWtIIH3ONdaB1gmn8AX5DpvkTiBGaJHurqCUlcZ5ZYO2WTRTKgCDWag+Aqmb
5i+mglTDeYLrwHKfQQV/ALE7JyVrBdg2PP8gaRRo05zt81aA1D+1U1Y66NJjzK/Og/RJzMvS
Z8A7puruUovAfjA9NPlDCHnXb050XXCNMGiWXaC1tgtXKgQs964W8xOY7yrJagiYjKK0cIN1
ie1ZzkTQeevHGp+DfqNqV5eDb5bSS5QC0/shCaFPwbQn5kLhb0ApHjjJqx6I8lkbLech513b
YeuvYKvoWG93gu5babvuFKgFpA9FNtBackjjQZ4nt1YsINppI3UTQOyXBqtfgmGhkq20gqDP
TeP9MiFvrWN8Tl/QRbq+yzWButre36mAVt28yO8jEDjjcueBYvKdblgLyHkvxSegjcku510X
AicE1PZOgMpZZT+IjYPn0x5/VbwZJA9JLxnsD4qX2kBaC8nb7F2ye4HpuY9dCgd2y1OLrIEn
WYm9bdegYAv5Vp3eoNXL3aI7A+Jrd2zITlDP2o/nJENEXmCLSp3AFpSbld0RnHWkYKyg7qNP
3mawfuv60G6B48lXp5yeBOZH5kPhc+FK04fbfq4FFT4puDzKCcZI28CAWLjW83ZydldoeKCi
aPwEUhvnVnocA1kHbCtuFQaf675nQsZAiaqlg2s3h+J5JRZH/AzPLj+5m9gFTMOybhm/grw7
iafib0LJa+VWR2eCa459imyGAt9G3wxxwK1qN5XHFUC/z91LeIPpgVIobR/4fOa9O/EZ6A+Z
KygTIeaK85jTDvZt3ltxgnGgLtE1AFwjlIvmWZA4y3nB+QSY8Wc39f+dDGsNaw1r4fLgy4Mv
D87/4Yr1I9aPWD8CwqPCo8L/agzum4cQm41vNr7ZeNCn69P16X92LTw8PDw8/l/zx3ucrQ6H
3QVoaLgBDQMKSFGk4wKqEc9VEOPwpxJILmyyA7TL2mhHexAvpOn6k6DMkRIpDFJRlmkTQJQQ
IZIBxEjn2txvwNbm6oPjD8B27WHH+6/BXdtW3DoGDBX9+4XKYJhaYli5b8E90/FV9iLwm1L9
XouaIJeUexqs4Hj4otfT15A39ub0683h4sEMo3UrvNbSCmYUgZgUn68DW4But7O7IxdMo6TX
SicwnjUV11cGYxyJ7iEQGlvgaewACHpefVW1cyDLkWrIPZDc+j5aLbA/ubbi7hbIO/38XNJn
kF4ob0jeHrClOB44y4E2n+laHjhfO687b4GoLq0RcUB50VurDnzpTtYWghbheqx5gxiiC1Gu
AhOMpYxpYDtrO5EzG7K2JvsnToHc3Jt1b8sQfD9kTNgB8G4RfDBiHmi5/rvC9oPtuNbAuATu
7/V2O9qDZZ7hnrsdGBaJO2oP0J7aVshmyNnv+EYNAEubrJ+1AeAu4J6etxHUTFucazvYJ7pW
2puCzqp3K1+D9qurgaMXuM+r9+UIMFTXxxuHA5WUTiIQjAdNY3wPgPc9Q2+5J+jeNc0Ts8FZ
Wtw3+YJq13XWwkCJ0M2X0yB4o/9J12nwcQUc8F4AFdeUnNl0HCiv3KlaAXgQ96j/oysQnB4U
bm4Mia0Tbz54CvULNAyr+Qu4X9o+Ct0FoTvC65nvg2+8dze/0mDNcAymGLy68lzJvgLaMZv7
xRkol1V1VsUseHA7btHLjvDc/1X1eCOkfpTi96QwJOxO35PwISgWv9wMDbxNptk5+0Aek9nX
3Q8cG7yC3AMgqHrguMDPIX2eu2/uZLBNkPvINSAvImteVjJ8d2zChvMZf3Yz/98rY07GnIw5
sOjMojOLzsD5cufLnS8HOb1yeuX0yp/vunmz5s2aN4MRNUbUGFEDzOvN683r/+zSe3h4eHj8
v+JNj/MfT5ydDqv9KUglpEipNIh74rVIAJJIlaoDKhlkgNSFEFEEqMpS5QiIH8VwdwVgsjxd
egDSIBEtJoJ7MQt0+0Buqn+qvwnqtLjXR/fAs22bJm2MhYxf8j4wbQTzPe+P/UZDYG+fWIMN
zCLoF2k1eN2vdqqBF5h9ynapWQTkaBKU66B+bTfl3AH38mspN76Hx9qj8Tf6gnWqliV+Ad8f
pLlhN0E9yxJDGvhO9d3pXxS8Yo0xXv3BXNX7mVc8mF1VkoqPA34IdfrHgNhhL2e/BLpvLXOy
Z4E15P7RFzpI2/W8UnIc5PrYPrBVBlcPqZ2mgLAwQswD50PnMud34BziNtq+AnkaoaI4cFa7
wE9AtBarVARtt9RX0YB0w0tlA6hVxSBSwH7B/o5lBGQPef3QugWybmV1sz8BZUv40qDJIKab
hPcPkOVy7rT1hoxX7pzMHpCelyIyS4FFlzU5ezXYn1vqZD8Ex1HnOncm6DdySz4HelnX0rAe
5HP6AXoNTGFGneE5SBtkh1IHFKe+mH46yE3k/nIVkCfJ48QpENNFKTkatKZqFuXB9bH2lVYQ
tDq0UH1B3NG2CifI4+RJ+m6gTDYWNz0HY3HTA6kOGD70M4auBX0zf6/AOAh4GnQ9KBZ0hc2l
jIvA9TQ14Vl7yKpte/9hOBT1itbpb4K61XnHqxY0mtkwZkBDMI/TdXO1A9ddWScmgdzaWdj3
MFgrvK74oAlYX0ofyc2BXdpVaTuoJtHF2AXul37a4YIdxEab9+PtkNM7b6z8Duj7mda7h4Ot
kPlm/FxgjPMzaTHYzK7ayidg+iWgpS4OXt7PqJtZBNIbpvTkEuxxLm59ttaf3dw9PDw8PDw8
/oi3N1TDKgVJ00BUFcvEQZC8pWIYgF7iNh8B6YylK4hyUq5QQKorLKIOEKGslAYBR7RB0moQ
SaKQ9g3I3ytPpT2g+zRnVXxDuL9/s27LVbjywdMtogcUfli+bmUTlE6uP6TKeXAFxa97eB50
57zXyZdB3zUyM3o9yJH6OT6fguZyX3csAuUDQzXv2WAd4bDop0HhaxHNYluB7YA2Oi8dkna8
sjmrgxxq3m9eC4YN+nSlFxiK+rczfwEMMnSRk8BdM/fn7Aug/9Jvq/ERYM48kZULedsfvHhW
Bqwzk5blaeDqpZ4WSSC8JT+mgXZYHSUug3aeZlokSIflynIbkFu4g7SPQQ0X4c5SIEVIB+VD
IPeQJ8ipIHcXqWplQK99xhRwFtDN9D8E1tHev/jcBevQ2HWuUpBew7+MdQzk1c6dn7ERMr9P
GBe3DzK3Jj1LNkDe47xW9jCQ4+Vb2hbwSfIZ4xsJwdcDbgR+DqZc3zM++8G40yvctBh0y00x
+i2gU+R18regrRHx3ABxWdjELpBiaCOmgK6U9Km0D6TzyjHpNmCUZupngBIlLyAa5JtiidQM
tAitt3IHtNbiY3drUMc6CmsOyNvpyLbdBntzm6xWBuu11yHJrUEMS7+Q0hpyC72uFuAC0wc+
tQPCwPd9Y2VnGgQu95oZ2AJudXp80iGgjhprkSLh8Q+3F51/ARan3NtrKRRYGr7BOxZqb6x5
olFRuBbwcGLcGrAdN9q0dVC0cHFryLdgXCdP9LGALl1NLtsXAsr6r61WC7zOBHUN/gJOlL50
deNqUFOzP0/qCsHXvT6XRoJXQfl5la/g9o+vD10qAsHNwj42tQZ1gyjreDN7Rfyf3dw9PDw8
PDw83oY/njgPEt+xHqgn3ZEsQBzNaQHcp4d4H/iB0/IaEDEsUgaCVFd74dYBpUVXpTwwV8rh
Z9CyaUwp0P+gj9ElQN6Xd7yuxEN68zu5qZWh4MPKeXWToey4lh0qzgH/DeEx/g3BVSPwWbHl
ILZoT6zDwN02t3dOQzBejNgk+YDUVFSRc0Br7pzjOA2ikiuQVMg94nwQshvsm3Iuu6qBq1d2
p4RvQNttH+meC5ZS6pfS+2AIVRrKO8D4XhlnrA9I/mxxXwB3n+fnXtrAeSrleOYc0LbmmN3v
gLu2fFW+DO7xroNaBRCZ7sMsBekTTGI46BrJu+Vu4PpKS9PaAyskVe4CzNDusAxETVFCawKi
t7rJ/QlwTz/OewbkNJTmeL0PKbmucpoF0oWtec4HkL7w1faEcpBy4GX3F3sgQ7z+NKkDaOfV
H9ydwPtS4IagBRDrXaxoITd4mQMUnxug/9ZwUjkE7uPuTzQbOHvZv7LpwJqe/X12RxBjM0eJ
yyBvE1MlI2hb6Ch2AGPkeMkPdAWU+bptYEhV/JQioJRSchUNdGbFX/4RtJLybnkByO2UFG6C
Lk+3STKCobpuvm4dsMFcWu8H3lk+Q33yQCuuZMrVwJXlXiqqgyPLVt9dBawX8t7NKwX2qmn7
clpB2nxltuEYmFf5bDSnQ4kxZRvViQTjs4Ag34NQ/kjx/ZF1IDQ+4lhYDzBtM103DAJjN8Mw
MQMqBTdbXt8XTJ+bm+sOAMEspy4o/YmUt4Kho5cxqBHYX4tW6rvgX9X8vXE6lMsu1aXPWHgc
8CznaQRY2zr1L4+CT0SwzrcuFGrqG/9oHuQU87ZmX4OIqAL1fcoBnrTZw8PDw8Pjf4230OPM
J2oa8K44KG8AZlJMSgIc0gp6gLZTjFF1oFvOa11jcL6WptIKpA7itAgBuavSRx4LulbuyfIq
4NZ/hHXXSs1MqwVFetbtWPNjiB0xvMT74SA98algcIC19LMG98qCGmHvnbUD5Kfyc3cMmLYU
2lp+Imhd3avtAcB6/Q1pOmgtX27LmgLuho7dqhuyfsqdmdsRsve/np62C9xbbEH2bhDax79y
4DQI2RrUwicClB+UAkSBeuTVwvR0EFMLPw9bDsoWo13nB5yhkO4YiMJSAXcsKI2ZJBlBOaTN
pjdIRumZNBmkw6IzUSCqaPHuBqCck2YKAyirpCnyT6CVlS4q74PYaNjmdQscA/Sf+SiQ9ok6
UqkFr5dZN1v8ILle4otnpyFtxcPX949A2vXUeynHQWlrnGS0QuDXUUUjvwTvFaFtQ1qDnKSP
wwyuzpZr9mDIeZL6OD0anN2dQ7TyoNSXK+mzwfSx2W54DV5B3lt9hoHXdO8a3uvA+ImXYmoC
hp7GZcYs0G3Tz9OfBJ2sVNEngfShsh9fEDWEKqwgjRAGrRtoF9UR2q+gLdWOuhXQFrivOPuD
WOas7B4KWkG3Qb0H6F17nf1Bl+Z+V7KBAflj3VPwveVjNswE93bfX43J4GrlsmsJkPehJcLV
DCzbrFus4+Dx3vPvnqgEDmvUocjLUMIdPrxeI4jUxUwJ/hS0dSLI5QLtqvs9swt8ennX4hjk
9c/zt4WBfFb+QL4IWWsyels+AtNA0zCTE6KXBX3hmwfqWfdgbT5Ueqf8VyVXge5X08qCpeFS
v9uRTw6DPVtZ4JwMZcJKbC6+Ea7vj8ve8x3kHXIufbAU+B/063IeHh4eHh4ef8wfTpx13fTv
md4DtbirsKsFMFz6nPrAPNZIs0FO5UN5CzhbuFs5jeB8njr39XtgiDCmmFwgrwsKCvoV3Buc
vs7KID/RqVItMKwsVbPEBAjtGetQc0H92Mfh0weYlHM76TUoNrmb6ytQH9iW53QDJaLEklrX
QN5nmuY/GqijFlQngghVyzo6g7XvszrJRcC+NOdjewFwt7anaJOBq9KpgFxwH5fKqjK8epF4
IDke3EGOJIsRIopElyg4DOQUd2/XYtCXY4LYAaJ8dEroO6CPDpvvewbEJnuCfRoQkHvTsQnE
EP1EcQV0D9TzLAR3E+d+dSAIWbpPfRADWUh10B3QfWHsCnaHcbnvNshebDhqHg+pmv2CMxmS
33nV5flESK54d/VtX0jxf+l8MRm4aarlFQ7BbYr4Fp0C5rLBJQOag7OUq5RrDOSOS7mfPhjU
6vbKaiqYmpqHGi6D/zfB/gHfQcDasIYhlyFgVNDPgX3Bf4rvVJ++YF7kXdjUFXTT9c90TUHZ
LxVXxoH4kcFiCWj9xEAWg/yuCJGSQQxgD62AUaKzWA/qZXWK9i6wk06iOXBSOygs4P5Ru6bt
AHdTdZvaBDRv7bp6EESSa4TrCrja2wZbQ0Ht7ChuuwPuH9WjzongTlMXiClg6KK7J1UB0wL/
zcY+4FfJT5gksH7vKOAeBq8Hpg9ODYYfh21o+VNfCDwf9H7IVgibF9ohpDRUia84sOQvUK5M
2d2F5kH2h+m7pLvgHCTddV+F1zeTTqQvBsNMQ4j+F6jgXS2waAxIG3SfyO1AsWnXXKuh5MKi
/oZDcPvprx2cH8Cjl7f33Y4Fv9MVppc9DPXVshv7HoKTDy5+sqsMAO/82Y3cw8PDw8PD4+34
w4nz6frnR10cDbXLV7tbrQ7IV6XNIgnECpGi3QSOSSPkNJArSD8p5cBrRVBK6FVIqZLULTUN
/AuZFjsuguGCobT0GWhrVG82gqFLeHrR0aBezumduwZEdafO8RNI86QX0gEgR+5iTAD98KJN
qn8F+iUhIvo6cMxxw/oriLE6b/1ToL/1Ey0HlOuOmUIDOV15ZNwB3lu8Uww3wMfbt2FwY3Dl
iE9ifgSLV/LihLKQ8N3j87c3g21rRnpaXYj4KTak0Gsw3rB1yIsFZW16RIYBdNF+bfzvgdbH
9ch9E+SWciWpKRjeEY3lWHDM04S2HXQ1lX3KPHA31Opq/UGti0G3GdyJAUcChkG6yxWtSZAw
M3Vo8jeQtOqh/vZ4eHnlfti9VWBb5Z6hFQT/dbElCrQB447gT/x+BpePa4P6BaQ1SZj1airI
j9SrREJo/ZD6wUUgPKP0iQJuCG8YvSL8C/D/MdDb3x+8TprHm7LAUEa/QvEGvUE6J4WAIgkd
XUFcUZuJSmB76J6hfgfaQ+1zrQlIT+UHsgG0q+4X6gRwD9Js2nDQyot9ogUoTURLCoA0VGok
lQXlvrxC9AGlCkJKBeUCq5UaICHnyoCunF4YXoBzkmmZ+SC4+6o13GEg1rotThs46jin2geB
u7ytlK0mOIc6FriGgTJelbRsMISZKss3wOsTU17AO2C7Y+viLAUZ/bNLZHSA1GI5/pnlIXdG
ni1zAWRcSa38Ohca3GxwscF1MPzk/zigIIR0DdkWkA3umupIdSboYvROxQlqS3eiiAe34i4h
/wzppBrzvoW8kVkXk05DtjN56pNv4fzjvB3xfaDkuBLRpR1QZ0PZXk02/NnN28PDw8PDw+Nt
+sOJc26bzFhHLdCNVnKkEuBurlbUAkDuJX3IPhCf4BQzQeom15eugNLEW/KKBlNQ8ET/ieDq
6rzpigfvZr7jAnLB/Uwdp64GscZ8PWQI6LJNkYEmcBfPeZ3eEvRfmsqYr4BSI3Jo6bkgPaW+
sgTA+aG1MohPlQHKCxDlpFr4g2itPdbGgdglzxYVgVA+1j4EeZT0obsj+AyXy9mOg+tDLcq1
C4xbA5N0RcAdZ4mM+hZe65Myn3cA11FbalxNCP0s8lDwZPBpFnA76kPQYmx9HO+DmCW1V+6B
a4P7a9clEMu15cIC0m1ppDgI8gBXN+cvIDXUfaEvAo7S3qNDwiA+3PHAHg/x3z7/8GF/eJFz
49H13ZDc4hUvpoGSENjLvxn4fxxdNioelDqil7QGMku+KpniBN1ozaHMh+ivo2dHVoCCCSUO
Ff4YQjcVSIlcAf4F/XN9joPpsv6AYQfwI2uUxqC2VlX1BchfaPWFBu6JjKImOGao69QCoI0V
YRiAJlKg/B0YLDqdXAB0Q6ReWEELlr7SRoH7jHut0hXso9W7ailwZTNDHAZ3V/UrdQC4OmtG
cRKUTfKXUizoXdJBaTOopbVHHACHpKa6fwBRjuqMBClKbJWqgHJBt970LYi+0gdGMyjv6R95
JYHe6j7v+AT0y211bXfBnejIdNwBXT31vqsN6DuaSynZYPjUdMTPC3I3WVMdQ+FVm6SdKdFg
H+eY4uoOPDc2NHWBwIU+X/qUhdzsrK153cFWzzIm7ydwJDnrOb3BOsQe6MwA6wvbJmsleJX6
ek9mO7CssnRIPQD+Y/1nKdPBVsIRqbaEX9+9X+XO15C6K63xq8JQnwbU+wPt680PeOTl5eXl
5UGDjQ02Ntj49+tlFckqklUE9nbY22FvB+hj6WPpY4HV1VdXX10dhg4dOnTo0Lf/BbJq1apV
q1b96/H/6PYeHh4eHh7/nf5w4nztp6fa7ccQm3i/dfRKqFKqwqgSkyCvpH2Sww+URqwXM4G1
JIqD4P7CZXFdh4BOfkt8dwA7xUnpS3DmuBq7PwNplKRwHKQWylmlIohglugegW6jX7LJCPjT
RNKDdlDtp1pAfo8yzubAUKmP/j3Q7ok56mmQDxCnvQKxxVowvQ04NmdmpT4Hxwvb6cwMoJnb
nd4eHqx6WfpJIqTXTu6Z2AEKzAr7LKwWBG4K/CJahWwf80vvEpAZ4O4n3QN351eNMheC71DL
kFwbBFYK8Y88Dsbt5pr+ZtBqqcW1VSCFinDJBtJjZxdtBMjzdXb/lmA55t/S9x48/CKnUUY0
PMu+c+Tuanj64fXtV6yQm2p/YikLXvHRG2OsYOgYMMD7Ktg2ZF/OfQJa8bxaju8g0h7VIOob
KNq7bNliiRATU/BFzBjwPe4/1O8oyC2VQ/IEkD6TJrIDRLR6SnsMopPW310IxA4+oy24q4ud
YgSIsrxgFkivZL18EkR3zVcbAdpP2iDNCO7y7OUi6PZLL5gD+jpKGakViD1itHs/iDLOU6Ip
uMLVsep5cGeLX92FQTzRrpMI0iN1EvuAIURK3UC8EBK+IMaIHFEBxGvRTBQEYRXjxWUQm7Up
Wl+QvsBFf3BfEa8lPxD9lWXGKJDLeVUwJIM+yvDYMRrkO85f7L1Ap3eud9QAJci51fkV6HeZ
Oxp8wXpfN1JfGzJtOd/numB/k4O6k1VB96n+tHkt6E8qV5RRYB2XczrrNWTOzriRVgzUWlKi
6xZoflp5dyq4L4vVukVguGzYKVUBd5jm5R0EAbrA0j4mkLbSQq0HKRczvsueANSiHMv/9fZV
bH6x+cXmw09Tf5r601SoV6lepXqVQL4p35Rv5q/35ie3i8wtMrfIXJBMkkkywaDLgy4Puvzv
+wIZVGlQpUGV/rzt/93EVXFVXIUdzXc039EcumV2y+yW+Ts2XMlKVsLt27dv374NcXFxcXFx
4KroquiqCKHxofGh8dDoQaMHjR6A4Y7hjuEO2MvYy9jLwNF5R+cdnQe5J3NP5p4E3fu693Xv
Q4O4BnEN4iC8TXib8DZwreq1qteqws2bN2/evAmyLMuynF+MkqdKnip5CurUqVOnTp3fLu6R
wkcKHykMWceyjmUdg25FuhXpVuSfP15/eyHkuTDy8PD43+YPJ87P1qf1fXQWThW8WT3IAqXf
KbkteiDo8uQX8gIQ34l2UgmgC89pBDiJww3qac2o6UFqIM1nOEj35a8YD+wkVwoCllIWE1BB
dNBWglgoLVSWA24xR/0IdHc4KiqCOIBFfgTirujo8gX9PP0R707gMqX3etYfcgeeL3byC1AL
p/RL6QLiunrKWhmeNr279ElpuP7p/R9fBYC02dFQigN/UXqsb2HQP1NOpbwL6hR8fMuCwRWg
RP4Cuiu6otI5yN7uPpLRFpzrsoJSLRDo7VpnGwLm44a15tsglVaDDaNAd8q3Sug8SKnvkxY0
H+5NTnr9SgdPLl+VrvSFh953Dl1LB2eM4jLowO+rgrML5oGcoQuVBkLO0lcr0m+Cv+JVw9wE
ShasHV35PBQ6U2pikSQIWRJ0Jngn6Cfq39X3Amkfq6gJYoEqaZVAZGhJuEDYxGBhBlnlO5aC
MpV5kgbql9ImPgJaa0u1b0B8I0K0KNDXoI3UF8QhqSzTQS6n3RGDQFwUy9gG4gB9tW7AFlFA
rAKlulxEZIBpihSqWMHxmXpI1AC3jFHIoC3SFogvQD2pfqI9BK08hYQBqC12axqINmK61A9I
pz3bQdor2jEGRBOxRbQG8T0yQaDOFbVEDNBOpEkpoLWVBxh8QAox7lM+B30FpYK+AogD0jvW
icAEVz33zyANlW5RG5Sbyk7TdMg+aykofwSOW+p411XwDfE/7BsHhjneqldFcOyXVOV7yC6d
cSPFDDyS78jVQOwQU9QgsHW173EPhpSv087mjQLjOcMg5SX4dPJrYl4A2iuxW/0J+INJq5+f
n5+fHwSMDxgfMB5eNnrZ6GUjKEhBCv7Vem8S5/rH6x+vfxxoQxvawHc3v7v53U0YWmNojaE1
8hOZWrdq3ap1Cx75P/J/5A8tJ7ec3HIyHJt3bN6xeWArYytjKwOFMwpnFM6AW7pbulu6v0+A
fit+xYEVB1YcCM+aP2v+rHn+BUC1atWqVav299s3CWoS1CQIrl+/fv36dRBDxBAxBNTl6nJ1
OZQ5U+ZMmTNQaXml5ZX+wIXI7/Vk25NtT7bBg40PNj7YCJlfZn6Z+eXv3/7huIfjHo6DxMDE
wMRA6DKxy8QuE0GpqdRUasI5+zn7OTtcqnKpyqUqUJ/61AeuSdekaxJEz4yeGT0TKl+pfKXy
FXgR8iLkRQicHnx68OnB0K1Ntzbd2kDOiZwTOSeg5fyW81vOhwKfF/i8wOf/fH2fTXo26dkk
GJIxJGNIBlCEIvwLibOHh4fH/3byHw1QeLBZFz4OXooXl5Mmw88X9h09/QRMhwx285eg1RTN
WQJEkch9kL6UFkoLARU3LhADxRS+B2mpOCLVAAmiGAjiuCgq3gFpkrReiQN5vTim9QZuUYIV
oJWU5uteAY21HW5v0HZIAYwGtaSlSdIccO5LGnl3BtjqPw+IOwTax+6ozO1AjtbZcQRMP/qU
Na2BuoNrN6rkBbXjmrgb+IFxRWhedGVIa2df670XJLfPvMCt4P3M7OM1EXSqzyc+G8C7im+l
6GUgVij1g4Ige1l2EYsfZL1vOZv7Ezjue33iVwVSX/l2CLwC98++avDCAHFrz1Q49QDitt1Y
eDUCnD2Nh70OgTky+kj4O+Cu6XQ6VLC987pJ5h0o8lWsKWw3NK7RYk7dNlDpTI2bFb+D2OtR
w6PLgM8zw2SjDZSW2hltNegOi+JaCzAtknvLq0BflaLyN6CrLj6TqoEUL1ryNbBXna2Ggu4d
7YwaDUo8c7UHYHxH6Sp/CHqZXSICpE/du9w3wbneNcDdDWxDXd+7M8A6zqWoa0AbK1ZQEIz3
9Q7xCej2SQfcg0HurDXSjoEyVTvtPg9KiJBFcdBdkXuTB8oFuYfIA+mcFCKVBemyNEbUBjmC
pqIj6N6VE6UBYNgk6+SHoG8iPZeqgrG3tEbqAIZBUg9CwTBHuio6ghIu9ZRGgHJOl228AAbJ
67HvCjDvNrf2eg1en8ubpDJg3iB9rfYDfy+fmvqq4Pu+Lk/ZCDmV0mLT7oGjsiPHdgzCb0VM
Dr8H0aejqhddDfJtccnUB+SPWSO8QddfmalcAvso50CtM2R2yJ5muQPqTbWN2h1kp5jrin57
DbV4TvGc4jnwZOuTrU+25i/PPp59PPs4uAa4BrgGQPjL8JfhL39/3C5dunTp0iU/kSuaWTSz
aCb07NmzZ8+e4P/I/5H/o3++vG8Svw5JHZI6JMGt7299f+v7317/zqg7o+6Mgqorq66suhJ6
ZPfI7pENnV53et3pNVwZcmXIlSH/fDnsdrvdbgfXRddF18Xfv53vA98Hvg+gXLly5cqV++f3
e2/DvQ33NkB1qbpUXQLdSN1I3UiQqknVpGpQo0aNGjVqQJmzZc6WOZu/3Zse38LphdML/9VP
gkcfiD4QfQCyi2UXyy6Wv/xNj7TPOJ9xPuP++XKeyDmRcyIn//W+qH1R+6Lyj9vRo0ePHj0K
G+M2xm2Mgy2NtzTe0hiOFT1W9FjR/PV+7+fwe+Pt2rVr165dkBabFpsWmx9nz549e/bsgdOn
T58+fTp/+ZsLlRPFTxQ/URycTqfT6YRDhw4dOnQINvtu9t3sCwc6Huh4oONvl/vNhd/tkbdH
3h4JOyfvnLxzMjyd8HTC0wmw/en2p9ufwlb/rf5b/fPL/6Dhg4YPGv7zx9/Dw+P/PX+4x1k2
yKu9BkGjHZWM9W5BDXOVzCIdwOZyPnK0AzlRPiEdAWkk20QeiIPiqagF3OISF4AvpKnSpyCu
aXW0l0BJLZEc4Af5oGQF2vKhOA7iIdWk/sBDbohJwGbyxDXQ0qT3JCPIm93z0/wgffz+mut+
Ac128cu75cD0fe2NNWqCKO7bwn8QSCl3e94EAhcbzxsWQ3ZVffnA5uDcYdSbksGV7pzq/Q1o
UaZ6htZgbmDQjCNB11A3w3sUqB/xrWsHGJrKfsIIhvt+/YKWgjXI8tjQGmxLTLWNDcB6Lqhv
5Pfw68GXdxLKwJ33T9877YIn5gefPzaBq6zfFa9B4F08qFrgR+DqkhttLwn6Ldox9y2osLxy
y7JAqeEVV5RMgBhT7PICJ8Brsa6LfiLknbGMsKwBRw8xXHwNhk26CoZjYPpcv99QGpyTHfUd
34FixYgPKDPkID4CzaYZte3Az9I0UQyc5dzB7p6gTRbnuA32VmKAexWIINUsfMHdQoujPMhP
pKnaJJAKaAXEenA9F8WkWqDUlAqJwmBYqW8rMkDOYJT4HJRg+oqHoOTJx6SWoLYRjaVB4Kqq
JpMFVBODpdsgbUdTl4AygrbsAcNBXRN5PkgZ0njmgPtbNU77FaSZKtQH7bF4V9QGrSEPJRPI
WVJDkkDtyCV8QJwXZ8kC6RvpphwNan1DqGEtaF15T3ofjCb7PbsNcDinOb4HHpqvK81AZNOO
fZBbxNbM8gKMmIXRDWEfFFgRNh+kPUoPw6fwelzC+w/mg/smoY4DoM6TDwkVrGbrSbU12Hfa
TM574JWnDJGj3l5DLfpl0S+LfglXwq+EXwkH9zfub9zfwLNRz0Y9GwVFBxQdUHQAMIxhDPvH
8cqUKVOmTJn8RO6V/pX+lR4aL2y8sPHCv9pvj6I9ivaA07dP3z59+/eXN2pv1N6ovSDHyXFy
HKir1FXqqt9ev2OBjgU6FoCkvUl7k/bC3bp3696tC2mH0w6nHQaxSWwSm4AqVKHKP95/aufU
zqmd8xMt3S3dLd0t6GbtZu1mBS8vLy8vr9/ePmxa2LSwaX+1YBWrWPUPd/sXmd0yu2V2g8SV
iSsTV8KhDYc2HNoAjvOO847zENkusl1kO2gwpsGYBmOAhzzkIbSNaBvRNgJ4ylOegqZpmqbl
J26h9UPrh9bP38+bxPnU1VNXT12F1NjU2NRYCNkZsjNkJzQc13Bcw3EQ2CywWWCzvy9nY7/G
fo394BGPeAS0j2of1T4KjnY72u1oN/CO847zjoPea3uv7b0WpGwpW8qGy40uN7rcCM6VPVf2
XFlo+qTpk6ZPfvt4nO17tu/Zvr8/XoxfjF+MH7xq/6r9q/YQeDnwcuBlsFqtVqsVHP0d/R39
gUwyyYSkfUn7kvZBzOuY1zGv4erVq1evXoWoqKioqCholdsqt1Uu3P3x7o93f4SLAy4OuDgA
Gm1utLnR5t8u95sLy3W119VeVxu6hnQN6RoCftl+2X7Z+c8evLnwLElJSv7+08TDw+P/QX+4
x9l5zfA40QKPveM/PdIWfEv49PGpDPJlMVnbCZJDnBPLQPQWF7EDebzgKXCPxzwG+VvpkjQS
nPWcL109wbHdVdpVH2RNriK/ArFdLBYRQA45IgGkygSQBZQXT0gE+WMNlwzWrMvFTwWD1CAz
x1oNpBFl2lRyg9/HTX/tvRFCLW0PDnoH/Ie0iu1aEkL7VO1dKRfC04NW+b4Dxk/4URkC6gem
k14qKFt1V0zxoOzSvTQLcFzWfGyRoPZ2fqKeAUc7x0RLUbB3tbTM2gk+JYNHhNYAt0+hc6Vl
uGt49dWrWhC3+szu03fhSfcH9eN6g2OB727jQzA99Ksa0AtcXfLCrNHg80iZLDeDmqNrvazq
gCq/1F1Y+WeI6RXTo0AF2G04UOPAM1iVvuHXH5fDD6O2bt6yDFb6rJ22diWc+PXcodPvw6sT
KacTvgPDIZOf3ABks+64bhK4r2qnxKfAMXmRrg/Irw1j9SNA/66phX4DeB01vKMfCoahjJPO
g3RP+KozwTRYzhOXwNBU/kLaCXworojioDZUC7rHgW2be5lrMNi+ts9xVwJ5iKgvlQO/bPNL
5RqY5up1UkHQ66VJagUwFJemqEvBq6byPTFgXiy/J/0K+o1yLD1A3aE+UreD8xuX5r4GrkNq
stYZ3BPJ0fqDezZttXhwqWKoOwvcV7WRag9wW9SFYhu424q22s/gbC8aiBRwp4iRFAf5pc5b
3wMMm0xfeXmB6ZHxjGkjeC0lVJQFU5pptdQBfMNMicoUyD2R2TT9AVjGW47m1oeAQ2Fj/PZD
kYIFrxbyA1MV/RlfGxjijNO8skGbIQ8zVYC89dbhogG4B7t3mae/vYZq/MH4g/EHiEyMTIxM
hPjQ+ND40PwhGsWOFTtW7Njvj/emB/QN7Yp2RbsC8mp5tbw6f7k0VBoq/QtjU/92DPY/8qZn
8NHjR48fPc7v8a0ypMqQKv9CT/OboRVvhnq8SVjzFuQtyFvwhz+Of8jtdrvdbrCcspyynIKu
hboW6loI+p7ue7rvaQh+Hvw8+DkcL368+PHivx3nTc/siV4nep3oBRUqVKhQoQJ/GUP9JlGs
d7fe3Xp34b2l7y19bynEdI7pHNMZTp48efLkyX++/C9/fvnzy5+h8uDKgysPzr/A4jrXuQ6V
LlW6VOkSvPjpxU8vfnr78d7U603inHow9WDqwfw7GfIIeYQ8AmxnbWdtZyFpZtLMpJlQoECB
AgUKwPNJzyc9nwSlepfqXap3fjlKW0pbSlsgoW1C24S2v13ev72wjJoZNTNqZv7n8GZM+ZvE
uWWLli1atvj3n1ceHh5/vj/c41y+TcyW2hPBIOR72QHwqkSyV3JLKF6+2MbCtyCnel6n3FGg
P6q/rx8FfMIGqgD9CaEucEFc4ipke2VF5eyDoOnB3kEW0LqLMlosSJukKGkUkCkuiTogbjOG
zSBtk1fI3uBuml02VQFbg/jIxGvgSsoItt2A0Av9lw/cDvozoT2iboFrpCPdYQPjxoKHyy4G
8Z7jc8dVCOxWbWZABnhNOb/xUTN4Uev5udQVYB9DrFwL3FWdQY7jYNhj8BUWkF+7nqixIO1T
jzkWg1RRCGkD2I/77Pd+F56+TLmfMhkeOC5+cv44PE59sOLeZ5DT1WuJ8Qr4p/g08FkKcpqt
seMW+Nm92pimQdT9YkdiBkH4l8VOFPgGDLf0W43D4Na9O4fv9oQ7zeLyntSFl4nxp145QBmp
bNS/BHu2+sz5JdzWx73zNAcOfH2k9vEAqLqjkqX8OCjZqNj9IlZQ3tcVMjSA5EHJ1uR6EOIT
sjdkEeiaisf6LmCeqVdVHwgrHT4rrDN43zNPD6wOzg8cF52fgWunO8K9H1yfuvO0LkBDuaXy
OSgTRF1pIMhBuo90FshIyTtgKQ3ZjXP0qSfAv5vv+wFLwbDduMSUBtxRTHwL7o/dldw/gmuW
+ywbQO0mBop1oH0oviIV1P7iU3yBPTzSvgHtY4G4ANjI5FfgI8aI1iDXFu/xFeAtDotmIIpw
T5wFqZxQRTlQh4qHYicItzgj4kCeIr+UjoNUyFjCNBQM32lZHAefwY5WtiMgUg3FWA8UFiFK
Gci5nf48dR14Nw8c7BYQuDCoQ0BpCD8izkjrIOVo8uXXR8GZJoQlBbKCcoo4KoP2Qv++9963
32CL9yreq3gvuLH6xuobq0G9rF5WL0PQ3KC5QXP/9bhR7aPaR7WHR3MezXk0B0pTmtLA422P
tz3eBpzmNKf/9fj/SHJycnJyMvQc0XNEzxFgTjOnmdMgISEhISEBOMABDvCXhPEf9ay/uZCw
GW1GmxGMdYx1jHUg7FTYqbBT/756vGG6a7prugvVjlU7Vu0YGOoZ6hnqAXe4wx2o7KzsrOyE
9aPWj1o/Kn875zLnMucyMIwyjDKMgj7WPtY+VngV8SriVQQcP378+PHjUHhx4cWFF0ODYQ2G
NfgvjkOFixUuVrgIN+Qb8o1/oXtErBQrxUqQ+8h95D7/xQr/efzfPDxJBSpQ4e3FC0sISwhL
gPSH6Q/TH8KrsFdhr8IgomREyYiSoBxUDioH84cuGbcYtxi3gCnVlGpKBct1y3XLdVh3dd3V
dVfJv2OgoKCAdFY6K50F+tCH/6I8f3th2TK4ZXDLYEj/MP3D9A/h9f7X+1/vhxsvbry48QI4
xCEOQWta0/rffnZ5eHj8mf5w4pxYL/XTJ0ehhVfd2PYKnL156cmlMLD7uHs6akLh+AJqbG1Q
QuU+yh6gm6giNoP2kg3aaNDKqTnuXUBj0U/7FqT3RSV5DMiLWCBPBdcO9zbXDZALyilKS5Ci
pFgGAS7JgBl4aV9kGQ2iu+2KowR4naxYvoYV9F6RZYvVBO2l/VdrD5CClFvGkyA+wCIvBbd/
eqilAxjLRPYvUhMCO9WeXPpncP2Y+6U9GDKjcxe6BwNNjF/pMkBrrvo52wATXEWyDwMl1fbq
C3AcjupeaAI825P70lESHhe6GH3+ODyJutP9Ri5kDNOX1q8Ar1amXH8TuL9x9XGWAnm/fF16
Csomv736pfBs+quFzztDwsmUjxJzwL7HXsbdAxJ3J/+Seh3sZWzlnFVBlyB3UuqDmiaaO4NB
tHFnievgjhB6cReyduTGOr6HvT8fPnByAJy3XMq+WhvkJ/I3Ohvk7bW+Zz0Lcl3pQ6kUmGNM
webaIPayTWoLfm39L3iVhh6vOvq2qw6Bfv6DgwaBoZu+utEP9D8athrqQM7I3Pl5qeCc6Vrm
yoDXjdO6JYfB5apX690cCekrM0anB0LoqfCSQS/BlGMqZv4FvPNMm8z+UEmpUKOCG3y6G/19
L4B6Q/tMawVaG3qxCbSxYqZWArTBmsxmEDdFS1ERpA+kkdJJ0EZpH2nNQfijcg80bxEl6oF2
WLzHOyA9p5ZoDtIw7UeGgjZIBIsUUGtRQ2wFrSlrRB7IFuM8w0XQV6en+iN41bJVs78P4mPD
ZLkAmGtqDZR+YJOyUzK+ANlqnK0vClGdChJeFkofKvQk+l3w+9xwy7wIzO94ldX7g5cufGXU
PAAa/ZFZNf5WbGxsbGwsnOp1qtepXlBhToU5Febwu4cw/JZ69erVq1cPjvkc8znmA79u+3Xb
r9ugSJEiRYoU+aue6KEM5d8wO0L1G9VvVL8Be+ruqbunLpimm6abpuf3sIdGhkaGRsLFdhfb
XWwHtahFrf9LvDc9khWpSMW/fqMUpSj19suf2yu3V24v8N3su9l3MxQqVKhQoUL5QwMq1a5U
u1Lt/B78+/r7+vv6/Nkx3tgRvCN4RzA0P9T8UPNDENoqtFVoKzD9YvrF9Mtf7e8/h2jsidgT
sScCOsd2ju0cmz8EJT4kPiQ+BEJfhL4IffHP1yemU0ynmE5wq+atmrdq5o/VfuNm5ZuVb1aG
2F6xvWJ7vf14b2YHCZ0SOiV0CtwveL/g/YLQcV/HfR33gW62brZuNpzvf77/+f5QIrdEbonc
/Hh+jf0a+zWGJlubbG2yNf84vjluCV4JXgle/7jcb2xvvr359ubQdlHbRW0XQRl7GXsZO8T0
iukV0wt2Pt/5fOdz4AIXuPD2zy8PD4//Of5w4lymfPHW1aaBdZbzYe5F8B3r9av5A0jdlrgn
9SMo4BXmF5gIOe/aDkud4cb0OzsvLYSQOv7PI4pAXLWXdc91hajAwHKFWkD0ubxTJXVQMKHY
jkIdwLhGn2kaB+KeZNXiwSWpD90zQf9MZIo9wGjZgg8Yvi7wRbgGPsa6c5p0BHcrOYi7IKvc
E3uBEtzWQoEORquSDrqGgU0DAS1TX9prGJiDSt4uORICSiZ+kZUFWtszl665wBav/SzVBfe9
vNfpQWD5MPepKwjcawrvK/MaUr/0nupXGl5Mu6W/cgSelbo197oF0p5qkxgAuiM+j33mgMGi
dGcT5EzLrZQ3EjIbqhftgyFxfFa71wXBPcrpp60FZ0W1nLYXlATDVIMF1MJqL9UC2mBXF7cd
5CXybSygbXAvdXcEtbU4o7wC8lDUx+Du55qtZoK5uqmBz2aw1LSFa81BHeWyW0eBaZBxp+k7
cGdr/dRAyPHPbWnTgZrtbielQUrZdFNOI1g15sesbR3Bb7xfKe+zUH5PyYSS74G6XFur1YF7
T+N8HpwB3UC9RW4Ethr2d+xnwIbVx3kcMItS8lDQuiot5RPgPOl8lLkbxD33IOcHYChhTNd3
gqLOgi+LTICAe/53gmaBmKXe14aAdAtJnAP9UqWbrgW4b6iLXVNA66i+piCwQLhFWRAOTokl
QAuRQzBI4/EVA0D7TEyX14Boq2WqX4N0iQrUBC1cbaXOBbm+cpbboM6VToscoL9eMQSAvpc2
SNsF5nj7cFdF4DNDmHwDtF2igW4V2B5klk2fB3KK7y6vAVB9Wv3lVQZBtVfVq1e+AZyVylIF
tFhRgjtvv8EqNZQaSg14r8Z7Nd6r8Y/X/9tZMH5rWrD0QumF0gtBq/hW8a3iwfSh6UPTh/m3
wuNMcaY4078e//cuL5ddLrtc9ts/bv9uO1vubLmzJbzHe7wH1NTV1NXUwdkiZ4ucLQKbfDb5
bPIBNrGJTRDWOqx1WGto0rNJzyY98+M03NhwY8ONcLL8yfIny4P7qPuo+ygoN5Qbyg1ouLbh
2oZrwTfWN9Y3Fqo1rNawWkPYe3Pvzb0384em+DbybeTbCBr7NvZt7PvP16e+V32v+l5w5tiZ
Y2eOwea0zWmb0/Lff5OQ119ff3399UAzmtHs7ceLSYlJiUmB1C9Sv0j9AnxK+pT0KQm6RF2i
LhEsiyyLLIvy1yOCCCKgUaNGjRo1gtPvnn739Lv5Q2fejHWvs6DOgjoL+M0e579VaVClQZUG
wZ7IPZF7IkEaL42XxoPUWeosdYYG1xpca3Dtzzr7PDw8/jtJFy9evHjxohA1a9asWbPmvx5I
C3EPVq9CenrG2pQL4DXY/DhgN9z+4f7TE2Mg3h3vzOgNRXXFNpc5Csndcjs/+RXuzn1a5FQo
RKZ5r4uJgJdFkiYnHoZW8fUO9CsBvuE+7U03IcDo9zSwEAReCpkR9gzUhaKlmAHqqrSzvz4A
NUPN1VUDw8TIbWWng3zD8VSVQI1TpqljQchSOXkh6ALUr6UHoPY1tpWLgO6ovFm5CTaf+2tv
3IDsInuCDybA65HJzbK/htxKjsXWx+B8bp1giAZdcsHypWygZlbeUSYInux/MOfWLLgVcbjA
zlHw6HLKkCwLWBt6mf3Pgv9B7yDvL8HRw7bOVhXSCmdNT+8Ali7OINs90LXX5+jvgurQ0sQp
0LXVXTO0A22GXEdLA9qpelEXnDMcs1zTQRwWDbTeIEVJtQkELUI7JkqB8BWh7AKRI45pMsgP
5a5SI5AfyLvlDiCflwdK1UGaKi2W+gA/Smb6gHOc85VaAQzH9G2VPaBK4pV2C6SxooXSDCS3
9Bm/gBQuxWj9we1LipYDulTZoWsAhsH6C/J0UGerx0UzkO9LR5QY0P4/9t46PotrXdi+1sw8
Fk9ICAR3L+4uLe7uWqBAkRYoVlxaWooVihWnuLtDcXcvTiCQEJdHZmZ9f7wnX/Zv79O3m8Le
3e85uf5Jnpk1a+51y8w996yZWaNnkSeA5kyRGliO2JO1DSA7mL8YwyDnhOwlsx6C0O2hGUPW
QtZPMx3MXAAyv864KVMMeFI8n5kDIM4ZVztmC2RYlOGbDNdBWEWspQMoxZUB5iQwrhur9Ysg
LbKhZSToq42KHj8QHcUb8QOou5RfFSd4arrHmIVALa4VNEuBs5NnkbwEspewit2gLaKi2RP4
zFND7wL6aFdJ1zVIWeLWjOHgXGLEkBcSergmeLqARbcPdgyBnAtz5sp2Cqo8Ka0U/x4Kdyq8
MN8cUKO8m1ivg6OfNYvj/4FE8Hji8cTjiWBfaV9pXwmlZWlZWsKVJVeWXFkCcd/FfRf3HdSp
U6dOnTrvv7//aWzbtm3btm3QrFmzZs2a/dXSpJNOOumk86E5d+7cuXPnQO3Vq1evXr3Gj099
qOJd2X78+ISZZcBp9ZRL2QailnLK+x484vnQ+3fgov/t385vgJAf/Mw8sVBrdfURVbPCa/mq
yYtB8KLBy3pPCsHbBbHzU4IhanBSicjeoD0Se6PD4cWDVwsj14P5ccrblE8hx9zsD3NmB09B
xmpeoPY3BzrngjW7PTHwCZin1Qo+Cggf1ap/B4qp5vGaBTwTX7AKKCsO6QZ45t0bcb4kxDU7
tf/oXYgrtmHAnr0QPfS33W/8we1kXlB1UOp7Ncs2FKxlsozJvx8C2lYsWPwJvFFi4p/9Cjc+
O6zvbQSPU55lf/klxPbTvvZ+Bv6zvU37FZBT9Ir6bog5nNA7tgokXEr+IrE2MFG9I/qDFqA8
FA/BNtC6SRsKor24pZ8B5brcaa4AT2tPO0MFvbBxW28AcqYcJZeBcdK4p38K7EE1BYh2SjsO
glTkLbM8sF8eJQLMG+ZpMy+YunTIHGBMlUJ+AnqssUHvCbKCfG7+BpZjWkFRCWRVcVTeBnld
1hJOkMuNpkYPMK3majMITC9K0BHYZ7Y0z4EhzSzmGjDj5Ha5FmSwnMx+MDOZE8y6YFaQx83n
YJ4zw/UjILOIAWoYvGkXOSvhHES3jv7q7U5w1/d0SHkIxjk9yBMOISdDnoXmgIj2rxdHOMC6
xLbFNhAsYZZGdn94vvJ56ycGKKvVKuIKJOVKKedeB5fPX9tydTpE5Y66GFUFtILW1dpy8I7y
LmhvD2+yRkXFVoTzX1wucbUhRM1/WztiI2T8LWPrwAKg3VJvOaKBCGWv8grUnBQw+4Ax3Fyq
DwHC1XvKz5BSwTnKfR2MK3p/41eIWhY/PyEK3PlSarhegM9Xhl3cA7/uGf2DRv3V4f7HhJwN
ORtyNu19zafnnp57ei6Y283t5naoGls1tmos2HLactpy/tXS/udRsGDBggX/BVNA0kknnXTS
+c8gPDw8PDz8A0zVOP/zBb8TAp6sz9HgejGwDTESio+FwHY+LQOj4c1E5/NbVyFojVsJbA1P
Dz+d/fgYxM1zPUow4MKsJ4efV4Us0bY7gRbIuzW4cfHb8Fp9UzFpEdjC7QPj9sCtQm9an/eD
QmPyni5cEQL6Z3HnPgnO+dr3vvPB9JGfKetBnSZKGWcgOc9NZU93sCzP0Df3DtDK+T0NvAvO
06+q/+YE1+0nJSL8QRzXgn0iwTtfdXft8uDnyZiSZQfYJwZ1DOwMMWtO7b6eH8xRgaP878Er
xcwevRwe7jtf+3QUvBj01P9pPEQNxVDPgVeI12G7CawQPwkdkloklk94CImhyf6Jz0H5wjpD
mQv2+fY9lu4gRxvh8g24OxpTXT7AIA7wFuhg9hKfgHxoFtRrgzJYfMwsMPrI/zM3d46WVSkF
YqTxyPwcbINt+cRPYCbK6mo0JMcnJeomKMnqDAyQU6ir3AdziPHAvAjiCy4pD0BZJZbyE3hy
uuLMSDDuUpJCwCHu6l+Ap5J5WtYDLZaflZbAGFbLImB62CCrgJhpnhGXQPwgXhMIIposZiGQ
L2Q+qoIsQj/OgVJCbyh6geZnCTBmgHlOVpFzITFDEvo5iFj9uuTrVeBldyyztgd6PjypbgL7
QK8GXs3h0bdPsj69Bm7N3dssAc4bzoUJX0HipsTqwe3g9dOYUzEKRH+fMCN2FbAufrC2CB4X
Cp/7zAYlTnwk8u2C8GPPpyfvh0jfmNwxNUDUjV6nDwWlqTpJngG1gfKVzRe0Z5Z98gbkcIW+
ybwVzE7MMXKAFi6GaaPBXkM7IfJCgh43M3YqKF95nXC0g0sJd1s9eg1PVz4r8nISfEqR+Lx/
KrL+vXhX867mXQ2a0Yxm8Df//BdZycqfuLBOJ5100kknnf9JvHfi7Oxoq+RW4MnXUZ3fREBQ
B/8+Z/rDw7HP7qXoUOx88KNawXDQfbHJ+tzgrm8cNTdCdrL55a4Fmfy1oxmAuo1K923UCWqs
r+WqcxCenn5a+pEfuE677iYPBCexWY2a4OmpH3J9BfoNOc6tg/LU8ti3HFDc2Kl/CSKbGO2q
Cu6g37g/Hd4mrZu9MxmCa7fP2j0H2OfkzlnaAbZduSp5JYJ6w1pJnQKcUYppT8HTPzr/y2hI
zHyxw7mxoFW1bkqQYBzMfDesOzx5cGXB1T3wvNTNUtdzwpscKbNdB0HOcPj5vAZbE+sv6o+Q
XCK5SeILeFsr4ZfYX8F9Sc9jnAQxQxxVa4E73JnJ/SXozT1rjcLgWWTml8tA7pFxYhXIDNJk
Iki3TDH7gEgRbQkAEa22l+NAtGGZWAO29rbPVV8Q1c2c1AapmIFGPrDO8XqoXAa9hWuVUQbM
LPoTIxy0cC23KANyjexmXAQ+FXfFGDA+ltHyDuhL9ArmEpD9GURbEIPUIC0TmJXleClA2S9X
iIkgN4sZ8kuQlc1xZkVgNof5AkSMyCZeA4bYJGaAvsiMNzuCGs1gtRyYdd31PQdB1SyFGQRq
nNZS2wUx/eMyJvWFy+Wvzb19E3IuyH43wQ6yj7xpbQFv20c/i84BlvKW8eox8Mvr+7VvTnDv
8uyVQEJiUqH4OEjyJHZLPAXGFPkNa8B5zOWfkBdO1jlbL2EWiJmymjoO5DEKqgVBKa38oGSE
h70e3wm/DdQUE2UKmBO5ZfwIbzK/rhyRGfKIrA1CW4LfF75fhm4DUUAtqVUAdP2u2QES/CJz
Rn8BHBTH1MPgaed+60l9y8DgvzrM00knnXTSSSedD8H7J87rzTEEQNKot4HOOLAYMSn2q2Br
4D0/oDy89BV1r3vA8lFoD70BpNiNTW+/gMRVry0B4fBZXIsM/UaDT1PrLu+OICYz15wOeXrl
blrQBVFP4qe+9ILLtxNi9vwC/ps9k8p2htACajHrx+CKcW/RE0As1+y2r8HowzLDC9TZfj19
kyFgVeXPKuwH+/FidaqHgyhrWj3lQXYyj+m3wdzoKcxIcH/8utydcRDXYOfI7b7g7hB7Qs8E
vgvLba1eH145ksbGx8Mzz6UhZ8ZDxKbo2zEVILmIeKm0AL9fHIW9M4H0118adSDhQmKGhCXg
umacNQeCXMULcQ+El3nH3AiynoihDZi+cgHtgJ9kCbKAbCHvy74gKrGf2yCq0RInyK/kUakD
S8wR+IB5izlyOrge6oP0RNCei+KKL4hu4iPswPd6Rr0SmBbjkdwC8qZZjFsg/JVnSj6QveVZ
uQHoREklDIzfZGazObCBsvIlqK1EL0WAiBLd5QYwm0tv2oJR1ogzzgCSgnIzqFOUzOoAML+R
bcxJIDfKrXIiiB9FA5ERLIdEW66A1tfSgAFAfkx+Av0bsxR3wVXSlWhMAPnY7CtrgsgjNioV
4P6B3yq9iADdafQzMoE6QmukngclQcmnHIdoS+ziuK6Q1RI2J6QpxJSLexubDfS2ZgbZFtyn
XQc9MaCkqMXUpuDO4B7kugg0N8eI6aA8UC6rW0Hz0YSyDZQJogJrQNxQs6kmyIYyQmyBNzve
rku6DY7vrUvf5gTrcMtgrytgu2CL8s8C0qqFKj3BFe/akdIcUirHD4/bBsYerzBrRWATkX91
kKeTTjrppJNOOh+G906c479+Wz95LGS6ZGlRpBj0DmgcObQ9WB8FLvJUh4NLrxZYOws8nbza
O2+A9xF7QFIT2Njs9NBZ46FzYa8iXzwD597kLeIMnO2+M+awBbzueS8M1kCvruwyJkPeQUGX
8lyHF/PjVkUUhpCC/rNfXAMfR2Dr0HAwG5nDjSWgbBT9bKfBMjFsae4BoPzgWy8wCRiuFJEC
5B33EU9NkGWUg9oxwKmtkW/Bk/w06e4ScM9+MzX2FKijMscXqAzuxKCrvi641//X40c2wItl
j3c9HAhvyus5zfygzXFM9W0N6hg+lacg7lZSSvwhSLziLOUcDJa2NlM9BPp1vahxBBSrEi8u
gmzLWjMGPJs9242vgQNMFc9BjdZqqwPALGAU1EeCPkkvqQeCYlP6KAHAUjlMzAHzvpnb3ACe
I3KM3ANuKVdigOJQQsUV4BeuiV/BXGc+NHeAGCUziGLgiXGP1E8ALURJsRcoJ07IlmDEyNVm
FlAHq7HKHuCSGCbLg9nI+MwoDbK27IQC5jJjtZEN1CxaN20HyA3ymClAqSymsAu0rFpt9T7I
oTJUdgR1v7jND6B+oc3ma9DbGV/J/sAamRMfMJoYNY1IUDZrmnIAqMIccwfofcxLUgMlQpuv
ZAU9UHrMvcA0/bSsAXqI/tpcA0/aPPV+8xZ4qGyRL0EsVz4xQ8F6x3pT/Rg8DzxuVwEwjhhd
zUWgHlIba8tABkp/ExAbjbbKQDCXiqHUArUbKXInmKPlp9qXIJ+Yr6QKET9GDY8tD34hvqW9
l0KmL4Pa2eygZOGm9XNQ24tM4kvwJCWtSPwBtA7Wuz4T/urwTieddNJJJ510PiTvnTgXHBw6
puJO6CfbNBseCt5+gQUc30BUv9en3+aGxOyRuX1vw90uT+88yg+vX7/xfvkIlLXWvBlywC7L
ucKH+oLXFPUX78EQ+71n7LMM8Kqeu/lvZyDpl8SQ5EkQn5h49vVa8I1zb/GeAtl6Z6mWqQEE
lg81siaDa0dKB3d34A3d7U5QhwUfyaUBtVNmvt0HynnjmBEKenFlmCgBygH5mMtAObOI0wPa
QP8471hQ1dA5Pt0hw+1K35dqDW+9ndmSLPD8wuWDF9tDRO94jzMLpHwulmt+YCtjjjeeQfKF
5DOJOsSmJI+LXw7upuYooxuovfRYqYNcKdfxE3iKeCLMruAZaTiNJFBmEqguA5J4Ql0w9niW
G0fAfGPG6DtAG6ecUz8HEaYMFdPAU1bvoBcBsZkqohiI5+YLaQfZV8SJPmBkkiPkUBBjGSjv
gyxDD5wgr4g2tAJ1uAhAgJnT3COXgnysrOIZ/+f9oxtB7FCaiXMgdoop5AJ5XX8qI4DashU1
QHNrm7QgEBsUqygIVGaavAOivMgv/MH81CxqNgExl4/lCjAmUJuV4Dnm1GQHMIvKazI7WFdp
K5VcYP5qjhAbgayyAWVArhDjqQ3ymZwvg4A+Mrd5EcRNuZmiIDOZA+UxMLtymZngWWjuN2qB
ulr7VAsGidnL7ATmx/KAUR/kPDO7fADyW9lS5gR5Uq7RZ4PSR0wz5wMT1M7aVbCUsJRRAGr8
n2/m6hX1N+4uYFtp3aZmg5Rzru/EIAj/6E2XyFbg/dD+kbcLfEyv6KD14I4VE0QQmPk9ka7z
YJ5MOabcAVrQ8q8O8nTSSSeddNJJ58Pw3olzTpmtbpaf4Fyva4knGsGx+xdsh7PDi5Ex34b7
g2NthkoxU8CvQ8BmR3OIUV4Od88Gn85eQ+0BkJDVOeNFNUjYZJ5NALI19+3jfwP8vvFPLpMA
PvsyJjuygHDwWtqg7LjiaxtfhvuWOzku/AY5nheYkqcE0MNywNYSqKkXck4HLdY/NNPPIKfZ
FrEWpGls0KuDKCvuKQmgPJLDjCYgC0vT8QxsZXJ3LVoHMizKGJzHAO+hmfbmnQHXJ6/+eclY
eBX+ZMzTAxAz1ijMJ2DsFCn8AK6VKSOTRoAepIyiOriSPA2NxWBuMqMZBfKp+YW5HMx6Zoi5
BoyJsr3cCkYpM9RsDeITpZy8BSxlPIXA7CMLmm9AbmWe6ABmHG9kKIiCsixrgRCyUxekD6Vl
ViC3mMomED0oJCuCTDD7yVjgkJjAS1C6yRQigduimwgF+TX5lW/AbIlVTwE5yfyC6kAhBoo1
YJzSA+VFUH9Ui4lAUF9aqioPQG6THUQkMFAOlX2BPTRiMsjcpl3uBpooGeQaMC8bFc0nILMY
J0RnEBm1rkosWEtZQ4QN+NZ6RnkKSnV9n/wSjOl8Z+YEOcV8q60BztCTGUAVspsZwGhpPpa/
AKo8rAWD2I5FZAWzpyylDwQ5CjdzgOJmrJEdxBhh1XKCvlB/QRtQCgt/kRtEGT41PwGRXWY1
PwVzBA/FfTCmm6WMFiCK6boMAVM174nOYPygD5SlwF1NdMMCynqtppIJ3sZG+6YMhjc1fIPf
xoDXVHuU106wvhRzvE5A8udimZkT3AdSDrr8/ytI7rx/oN67d+/evXv/jkNCOumkk0466fzP
pUCBAgUKFPjz27934nws2631u1bAsyvRi+MGglcBa3ftJ9CfGkfMLiDCYhdaDcgYkuG1fzlw
fp3R/rIGZOrkzlGoBLwKS5gS0Q68H1qDrafg0fo3HxnLwHd+XPkIDSxdtfm6AzSbl0juAe79
D3vL9XB35Q2vbW0g47gsCXpDKH+l+sV+X0NykRRryjBQbWoRLweIhl7jMncHXshwWR2U6gTT
D8xjwiIygwwn2vQDsUE7GRoA9i6hz6yDIL7z83GPP4KrrY/nOlEG3n6TksEdC8lrmC+mg9de
W4CXP+jZxCbhD0klnDdSfJgwd38AAIAASURBVMCzSF9srgTRTiQpZ0CJVLNpfcFsp0917wfl
ktnCjAUlUi2u5ASzkflIngSyUYnhIBThFveA2XKa3ATYKMrnIE1ZVJ4B8Z2oqIwB2VN2kc1A
q22ZoNUAY6HZ3/wYzNlmPXMGqJVERhECyh3lrtISzJdmoHwBZmNKsRUsCZYetoKglzey6NnA
NIzJZgugnbQzAkxptpJvAJhsZgIlXqmo7gNljHpNPQVGbqOj0Q3UQiK/2Awyi5lilAW5Xr7i
EmCqlcVF4BthoS/IZEoTA3KBu4gJmEWNauZekNGijboCuMVRuRzkefmJ7AeUopVcAfKmURQ/
ED+LzHpREL0URbkIVJD3lA1gHjIvmDWBrCKKH0GMpKaxC+gqY83N4PmIOeZHIA7I5Wom4DCF
zNMg9qpdjTkgB2ujtKVglDD6iI2g1lc06QPmchmsJACdRV6egGWlqKDUBk9xfZxhg+j1MYMS
S0FIh0B7ogV8enthfQrCqk8nK+in9fLCBXTmxX9CoKeTTjrppJNOOu+P8r4dONe590W6oJgt
h81sBiXqlGiT0Bgy/5q9tPgVIiJTbriHwb1+v42IyAjeTZ33NV+Q5/x6vT0PuRsULJC3HERG
JJeWHcAszM3kbyFqSeKl+xvh9Z2Etk+/gOiSydtenoMr16/1PFYUvPsHl8rbCM5ytdr+ipCw
NWLAo4GgWG2TLP3A+Fpm1F+CeYi69gpAHXqIbEAF6ssjQGnq8gUo5c2VYiyYlXlgzgRmM90T
BI9jz646GwXhTZ/4PrdC1DD3Uvk5aF/bHnnVBv893h/7jAV1ufKzchdMf6nxBKzxtuy2caDU
US6rj8Bcam415oGyQdmoLAUtRCugFQalv9JBOQIiCxaegbgn9omvQPlE6ap8BSK7Wlh1gCWL
paj1Eshn8pKsBpbiluJaTrCfsp+2XwNrN0tjqxts1W2X7AngOGfv7RgJyiplh9YP1Gpqba0T
aDc1XX0KYo/IRWlQDiifqWvBYbHNs4eB10b7PVsxsM+x3rHmBOtLdbjlLCgTJEo7YKeRz5wD
orb5g1wKlkzqVnUcSJPqXAQjSs7lLpjfMob1IB+bIeYpEIlUoToY9fRMMieYrVxhMgrMI8Zo
5TrIKvIcDUDUEnalErCIA3wGFGGheAPiRzFaTQARLnzETmABi1gFtKGzvAmiovhIGCAnmIVk
CzCtZhGlFSiqYrF2B0uytsXrDMgK5j7lLhhv9FLsBSaxWR0JzDbXUAmM9Xo5MxwMocebFuCI
fC4bg5Hfc0x/AsbPnlBzF+gPjOF6L4jq/XZWYkmIeRIXntgYaCXtrv6gfal0ZS8YNc1Mepm/
OrzTSSeddNJJJ50PyXtXnB3D7BftYyF+q2taQiMIS+YTry7gPUG+0j+BzOGBDe3xEHJNG+i3
ELK3zGBVnsJvm+LXvF4M2QbYy5X+HIrML7EmWxQ8Lf383rXHkHgm3vQeBRqWGZbcoN6zdEoI
BOWEa7NtFgQe9FP8V0LE49hCyXVhb/UD1ecGQ9vVHa5PzwNJT+URrSEoLUW0HAgyq3go5wEZ
iVY6A3tEW9kKzHK0lX1AOaC01qLBUz/2elxpuKle6Hm2MEQNSQpJWgpJHjlM+QG8ejlaeIeA
sle+Mk6DZ5zrtCs34BDjxVZQroiuigAlTqluhoM+331LvwXKOHFLcYJoppVWqwDdZXvxI4h1
xBlfgbRzRDYGatFNnADzC2khHEwvs4xsBsqPygr1Z1AV1UutC0IKUzkNhmo4jSGgdFN3Kj+B
2CaOKWdBHWIxtF/BPGSWMs+APt6oo98BbbY6Xl0ExjIzybwCTJb52Q+WCWoVJR7EMyVeqQxK
faWzUgWMm3p76QbKM1kmAb+JFUwFMVUMEtdAm21rqfqA8dz50H0ZzMN6Jj0zKBUUb6UckGB+
J6LBLCGyi4ogZsuSHARZWu2pPgMtk7pRc4BMkvFmLiA3K0UoaDeVUdrHQBeBzAPMFMPVUSDm
MIbaIGzKQNkJxAtei6cgeqkLRG6wXrIV9/UDuQq7qAzqAjoodQCPXJB4CTwz3SNSHoI506iv
mMBw82vzBSjb5XX2ADbRTzYFM8Bcp08Fdb3aQUsAcVrmU4qC45hjiH0ZKOu1xra7kDAlKb9x
DtyLPc2MAFCbqn5iH8gIafcsAdr81SGeTjrppJNOOul8KN674vymW2RoyhawBtqm2XtCkAiO
zNUCnHYlKu4yWLpQRI4FfZ11acoZiIh0fRuTC5L7JudJ2QPXS79af/Ae3K/+YvT1WhAf/baO
LAuWKMc4+33wcgSd9VkKbNIvqOdBdjR6Gvfhcf4H1udBkFAq5praE14eNi49jof7qx4NWbwE
vO7Yb1rrgfkNdQ0nsIyr6hHgqngkTSCjXM6PwAqzjbkZrHMtNbVkeDP8buVb1+BZx4c9Hn4G
b6PcJ3U/kIFiukUDm7/trdoUnBvcldzXIbmGrrm3g5lLXjet4F7pLus5BcZU44BuB+205al1
IXiW6RWNDSClcc5cCrZmluLKE1BOaF00G6iaWkO7CJZxlsaWemArZPncEghc45qsBhSjhGwP
DGQAdUHsEbtZB7KmzG48AOcvKSOS34KnmyfA3QM8RfWXRh/QDSO3sR3UMLWomgLKTXFRmQ7K
5+IOV0EqTDJvgbiijFdyAmPkGjkISKI4Y0AsUVK4CnKnCOVL0JZr27VToE80fzC3gtpYLhfV
wTbMWtI2BdRm2gNrDVCDNS/1R5BlZGFRE6TFnGguBzOcqeQC9ScGqQpoz5RmFl8QaymqfANm
jGmlCRh7jOemP3j6ejrrW8CyQuzVCoFlieJtuQzWvdYvvJ6A+a3ZWBYGs5i+09wH7oEpdxJn
gvuz5IcJZSG5ZlLd+GFgfORZqlcE79q+akAKZL6bJTJ/AQhcF7Q8xyWwdfTum2E9eAUENMz4
KQTvD5maYyYEfBfcMVsecPT1Hx/cF3yrBPbP3BQyHgtdGGYDyzeOVQGFwdNF36KWAsv3Yrmx
CLSOooo25q8O73dnWK1htYbVgjaH2xxuczht+fQ80/NMz/NXS/e/hzJlypQp8w53LP6+/V9l
r3/VfuOOxB2JOwJfbfhqw1cboOqdqneq3oHKAysPrDwQBt4aeGvgLXg57uW4l+NAfio/lZ/C
rFmzZs2aBTX9avrV9INKKyqtqLQC+i/tv7T/Unjx4sWLF+8xmep97fSv5vfs8Z/iL3/ElbJX
yl4pC4MHDx48eHDa378n9VP3qeP6vb//W/mr/fR94/Gf9YN/F+9dcc52LmNb603IvCjrTt8g
CP8x+n7MFXjmfrov5QgozdSZzjHgfqyUSPka3raPPeg3HrwDlQ6OupDyo2ya2AhcdfRNRjZI
TvQUt/cG+4P4PHEhoPT3O+GJB6ODNkcdD+4U09ecBcoF0TnxCSgfa42TRsHzrm+7hGSDpR/t
mrppLrRrUNbXkQ2K9616oftESFzvPJyQE7TTtLBqIDPIEjQH0Vz4q5VBjjLuuh7Bb6Uvlb10
HqI6x5ix7SAh3v2KU2Apbr/hWAhqiLildITkMym1kz8HVyc5xwwEsiuRWk2wTLIM0nQwpxqN
lKlAS6W7WAXW2dZR2jowV5u/mAfAPCrni4GgndQ2qGVAjpJT8ANlvDJamQBylvzeWA2c5hmT
QJwRx0U/MFeYG+RaUHuoXZRIsJbV6trmgzpXWaINBnOIXEdH8MTpo4z9oAareZROoLiJFutA
b2SsNrxBG6A91uqAkqAq1jygTVG9FAOMFOOxEQ+ivrCL6sAZDNkfrIO1stoIkOW5xXeglBVV
RUGgltyGN6hXxFS1HWgj1KVmIzACjcpGd5DD2GJeBaLwkt+AdlKLURuBGCSesATMfkYBaQUZ
ae6Ux0FUYaLYCMSJEcpvoF5WnqqlwH3aU9y9ACxH1R2aP3gqu844X4HnqHHEOAfaTe2q9guo
NdS8wgfMsmYL/WdgsXiqeUCpo+XXnoKRz1wtX4HvVd9aPh5Qcwe+zZAX5DV9pXEELDWsirYP
vHxsObQ4YL55VD8JXKSTpwZYvlUmkwTqYjFLzQnWIvaF9gqgVVZuKsVBaS+GKa1B3a08EVMB
6PrXhfe7czT+aPzReDh///z98/eB2tSmNmwI3BC4IRCGM5zhf7WQ6fwDp7ue7nr6bzztr7LX
v2q/qSfcwy8Pvzz8Erp169atWzfI7JPZJ7MPTOs6reu0rjD6zOgzo89AD08PTw8PrK62utrq
ajDo7KCzg86C+pn6mfoZ/JD0Q9IPSfDtkm+XfLsE5p6ee3ru6ffX+38av2eP/xR/+T30j/SP
9I9gauLUxKmJ8Mz9zP3MDcZ547xxPq2dp7unu6c7hI8LHxc+DgZVGlRpUCUIeBjwMODhXz2K
/xz+aj89Ofvk7JOz3z0e/1k/+Hfz3hVn/a4lybkQ7jV+9PqJFa5Ov7v07k4IrZq1ik9+SLkk
k9+8hMiL0SUc5UF5IAJt2yFyRVJn8yLE9I/L47cTPE2MNhkOgK134OdxDyG5oqdn4jJ4e+BZ
liQF4k69meiaAOY447ZcAk7vlKlqZXiTGNsxrhlEdIguFT4e7uUNfxU7AFZcOtx0ShyE2+72
OjIZ7FntrX3rgJnNzK93AbFW7JctQXmkfaUsBefDyG0RBeDJg1unb72FmNYpc13RkFjbmMpC
sFZ2fG/rDe4xnvzGFUj5yb0oJRT0SpQiEYwl5h5jKAhF3KQJmKfMxiYgOrOOB6Ad0PpqK8HS
T/tUk2C+MSvK30D/RG+o7wIjkxFkNAJZQ9aR/cBcaP5irgO51Bxk7gI5QNbiZxC5hVs0BxbR
lfXAGK6bScAisV5WAJYyQx8MIozdhgY8kq84BqKzMk/JBOoy9aHaApQl6ix1E1gWapu1mSB/
lrupCGyWS0UJUAwmK9dBOCkpdgOjZArHQRYwx8k7oK5QWimDgI0oygMwpphLjXUgOoiBigKi
m+iu3gDchIuqYFlm2afVAyWzEq10BesN63XrSZDP8TJiQdymvGwKMsj81jgPeqAer18DudZ8
LuuDZ5MxxFMSkpa4puvzQV9mjMUP1DfqOm0CoCHEJ+Bp4mmn7wbPbM8C4wTIitJubAC9u37I
cx+Sf01uHr8RImq8uvy0JUQvjBoYPheSOyQ0jXwJZoKnaOJ2SMqS1DLuDMTXi88e1x6SvJIe
JH8Jzi9cYZ4nkFAgqXdKICQ4E6skjIK4q4ndE+PBc95o4t4FtlbqLPPWhwvUg9EHow9Gp1WC
m2dvnr15dmg6senEphNh+9jtY7ePTWsfGxsbGxsLI0aMGDFiBDTY3mB7g+1p7Ud+MvKTkZ+k
tRsbPjZ8bHja9n3L9S3Xt9w/Lu99qfel3pegU6dOnTp1gjtV71S9UzVtfa9evXr16gWTJ0+e
PHly2vKdL3e+3PkSvm7wdYOvG8C+ffv27dsHrVq1atWqVdp4GjVq1KhRI1h2fdn1Zdf/UQ+p
lZBVt1fdXnUb2ie0T2ifAImJiYmJiWmViMZhjcMah6VVMlLH+Ud8aLmiskdlj8oO/dR+aj81
rTKWuv7Wylsrb638fXmmvp36dupbaLK7ye4mu2F+8fnF5xf/x3aplZvfs9e76udd5f69/f6z
tJzacmrLqb9f6YqIiIiIiICQrSFbQ7ZCn0t9LvW5lLZd5peZX2Z+CbcH3R50exDYK9sr2yun
xUvnTp07de6UFgep6Lqu6/o/L+fv6T1Vf6l3bOrUqVOnTp20ePvp/E/nf/qbE/2f9ddU/cxx
zXHNcaX1v2DBggULFvzz9vgjf5m0Z9KeSXtg165du3btSlufmrDUf17/ef3n8PbA2wNvD3w4
O6eypsaaGmtqQM6cOXPmzAlZs2bNmjXrP7b7/yuUpSlN6TQ/Lb2w9MLSC6Hh9obbG25P0++7
8q7H0b+3U2oCmLpd58KdC3cuDC8yvsj4IuO/3g/e108/lF3/bDz+s37w7+a9E2dPYSPcbyJ4
oqLtlv7gncF0+7eEjNe9CP0RCoWGbA1+DI6M3pbYvpDwROn7uj5oq6ylo6cDTxKHRGngKq33
TGgCxIrvk51gzPEpF3cNfLbZ3Y7X4B2q1rYOAUrp25y7wLbPt6dzJLhHu0ta3kJ4g/A7ykVw
fpUy11kZtFr+jYMPwpKKWx8PnQUJc8L73D4L2nDb597PwAzR+3iOA6e0wYo/RNd9XPRRWXj+
9KXfiyMQE5sS7KkAxhulvHoGLCnWC5Y+4Ex093K9huQJnmKuJiBKC6eYDjKXccN8BYai19EL
g9mYVuY+kMWML83HQKxZ1xwAymDxm1BANJJjxGow85gOMwdwgvOyHZi3zBtGBRBDRHcBqJFq
iogAxaA6LUC+MfIY1cA4r8e4T4H+1lxjNgWZVXpkdmCIzMVKcNSxafYosG6ztLUEgTWbRVqD
wdrKUsRaE0QB860sC3wsi7AQ1N5qf7UFiMfK92IxKNFKOWUUqN2VIGUP8At+/AZmf/OR6Qc0
Jgs9wbwud8glwCZxgyNArJhKFdDQnNbcoPXQytrsYKtns3mngOM7R6RvFXC4HL39boKjjtdO
3zpgG2Mt6LUT/Kr7HAksCL5N/B4HNQZjgpHBeArmde6yH3xX+E8NmgVaG1sZ+36QRXnEZvD4
6O31UDDOGQVMF5iRZhVZGZyBybeTuoHna3dAihX0tq4cyZ+Cc3vCb7Ed4LUjYsrLW/Dk88dL
Htjh8XfP+z29COEtIhfGTof4Lq6tnkIQt9J1jngIHxjTO6UCRB5Lae4JhpjmSfH6aYgKiuvq
Oggpp9wtjf2gPMJi1vtwgTox68SsE7PCD+1/aP9De9j6bOuzrc9gYe+FvRf2huMdj3c83jGt
/bQD0w5MOwAhz0KehTyDXS93vdz1ErY93/Z823MIGx82Pmw8fNvm2zbftoGJWSZmmZglbftF
pReVXlT695dXtFa0VrTCxYUXF15cCO657rnuuRAVFRUVFQXXll5bem1p2naX+17ue7kvVLpR
6UalG7D2/tr7a+/Dp6U+LfVpqbTxLL++/Pry6/DThZ8u/HThj/WyZvWa1WtWp50wUg/cqYl6
9TXV11RfAzN/nfnrzF//uL8PLde3eb/N+23etKkF27Zt27ZtGwxYNmDZgGUwo8CMAjP+L29L
qVmjZo2aNWBp+aXll5aHVatXrV61+v/iJ79jr3fVz7vK/Xv7/VCkntD3ZtubbW82sCyzLLMs
S0vgI3ZH7I7YDUW6FulapCuUvVL2StkrMNx/uP9wfzg0/dD0Q9Ohu6e7p7sHsr3J9ibbG5jQ
eELjCY3fX77UC5yAgICAgIC0C7CtIVtDtoZAQvuE9gnt09q/r7+WFWVFWQFLriy5suQKrKi8
ovKKyu9uj99rV69evXr16sGBXAdyHciVtv7s2bNnz56Fgh0LdizYETJ8kuGTDJ98ODunXiCt
qb6m+prqMKzmsJrDav5++yebn2x+shmUvkpfpS80bNSwUcNGaReajcIahTUKg+v9r/e/3v/d
5XnX4+jfE1w3uG5wXdjTdE/TPU2h1rpa62qtg+lHpx+dfvRf7wd/z7v66YfiXePxXf3g3817
J872SZ6unn0QtNhvvXcTCHb47bN0AyWfudYoD3GrjCTHEdAamw9kXQgYpe3PkAVsi22rjEvg
vKhki9gO7pKeHbFx4E5IyuabAXJc8uubOQHsFeRDvQFYfktcoEaB46KR21YKLFMcG+VTyPA6
8yRrcQgOzlBWHwZhrqC53oUg+VyURbFCeEvntJQzsObehjZf9QFik2RsdRALLEO9moG2S1am
GURceN7wfkF4WyCmWaITYt/oO83ToGa0CK0viAminDIbkvKkvEroAK4VeoJ7OojhRhPzF0Cn
plgF/GIOFuVAHcIXyicgrzFdvwRGVvNbPRKMtobH2AwsYhRlwWxkdpRrQbEpCUoQKF+Jj1kF
ll7aAFEV5A8cVkqAmlu7YOkD4pYyQs0AxgMzO9OAUGLlYRCtRT2lCjBETFIngVFLLqAbyJnm
VOxgbNHHeDaB8kZsFztB7aeOUUsDHanPfRDdRBvRGdSVqku9CXQRfuwF5Se1otoHeKLECguI
ueIeTUDZwHkWg6qrczgD2nplr3ITxF1ZWgwGrYX1R+0qhE7LUi/ncMh8O3OzfF7gO9H/WXBO
CFgXnJixDoS4Mv2aowqEZA0rkt0PAq5lLBGaC0IbZw7JNQrs170mBCZB6I+ZZ+dpC8oyzaGO
AeOAPsc1CfQRngjdBPNr47T+LZjfGLs9h0CuMY6YV8HcwDSlJIjcxJlDQE8y/PT64FXC737A
YbCOsvV3NAejvqxoVIekhwn7466B+3PnquTSYE43vzfWgGWf5YBtAjiaedUInA/2ZbYi/pnB
/ES0cjyFpJH6cdsmSFzvzsR0kP7K5+qgDxeoqQfIsTvH7hy7E5YvX758+fK0A8yM72d8P+P7
tPanu53udrob9Dzb82zPs6B8pnymfAZisVgsFkO3ud3mdpsLp7qe6nrqT9zCS02ALy26tOjS
orRKX1mlrFJWAe2adk27BtHToqdFT4MryhXligIVKlSoUKECLK2wtMLSChC0MWhj0EZYP3z9
8PXDYf6F+RfmXwDzJ/Mn86ff33/rVq1btW6VNq7UKSZNdzfd3XR3WrsWkS0iW0TCufnn5p+b
/8fj+tBypSYafy9X5eWVl1deDvO7z+8+v/vv95d6Qg0ODg4ODk67Nf2uvKt+3lfuP+LvK1RP
tzzd8nTLP477HypYpShFKdjRcEfDHQ2hz6I+i/osgtwHcx/MfRCmNp/afGrzf9xfjik5puSY
AlW9qnpV9YLnGZ9nfJ4RFl9ZfGXxlT8/jlRSb4WnVug1TdM0Lc0PUi/E/qw9/p4yfcr0KdMn
rQL/Z/3i90it2D766tFXj76C+O/iv4v/DnZP2D1h9wRo8qrJqyavPrydZ3SY0WFGB+jerXu3
7t0g49cZv8749e/3H7QpaFPQprRK7uZNmzdt3gQrK6+svLIyvN3/dv/b/TBp76S9k/b+Cbu+
53G0cebGmRtn/hv7RrWIahEFl/tc7nO5z7/fD97VTz+UXf+eP4rHd/WDfzfvPcfZNl67qpSG
xOMuP0sLMP01P6sLnLP0V0YSaHbb7qSxIPfqZ+QsEGXMe8554JULC+Mgor/xm/1TsA3SDqcs
BtsE5UfrIkjYEjccPzDPupol7QZjitLKKzP4jggra4uBhDuJpb0rwuujzldJfcH/qX2NuhH8
63HO+wTYb4QNjYsEZ6v4br6RcLFT+ISXK6BIhwOtlpaDqgXrNuy9DcTnqkcMh/Ds96c+DYUY
Z0qysyq4bupb9dzgKOHzlaMImJflQDkMnEOdMc6HwFO2iTNglJVTjKlALzleeQ7mDnlZLgQx
nI2sBA5hl1tA7jJXytbAG9FArgNxQHGL5aD10eprX4A535wtA0GVWnPtMzDHmEnmPhD9hJco
CupqdYPSAsyz5ll5AhgrD5AflBEcUL8FJatQFA9ol7W3ojbob/VR+nMQBdV8agIoyaKMmAnK
NOWgeAO8El7qTeAL0Y/XoAqttJYdlEeGMC4Am+UrgkEeVrLIpyDKy75qPxCFhb84DcpxypAT
5HxCRBMQT4TH4gSfn/0f+F8B+3lv6bcT9Kz6OeM+xA2I2/D6KrDeiEoqD64fk8pGTQVhUbPY
X4I8Zd7QO4D+g17APQXU/mpY7ATwneKzz94fXC1T+qXYIaF8/BcxfcG85C7hmQVGUT3ENQzk
x5Q324GcIKYqK4GrYpRyB8RRXstyoPsbn4lAsG3yivE3wbbA63u/kZDcLplIC+hXDX9PdQh8
6ufMGA0B3wR2zxwM4ms1F5+CKKJhvw1aRUsZR0mQybIodUFL0oppt0DLa85K+QT0e+4eyVdB
b2soDAG2vGtE/ff8UOCHAj8UgHsP7z289xCuD7k+5PoQWHpy6cmlJ4HBDGYwzGEOcwBZSpaS
pUDbp+3T9v1jf+KSuCQugfncfG4+BzrSkY7/vDzFzhQ7U+wM3N99f/f93XCx6MWiF4tCyZ0l
d5bcCdYL1gvWC7C/5f6W+1uC7yrfVb6rIPB24O3A2/B5pc8rfV4JQvaF7AvZl1ZZrVKlSpUq
VWAHO9jxf9m//bb9tv122u/IHJE5InNAzT0199TcA5ShDGUAK1asIKaJaWLaH48r9Zbph5LL
+Mn4yfgJzJZmS/O/+YZk6oVPTnKS87/pL7Wy+r68q37eV+4/Yk7ROUXnFAVPB08HTwf43Pa5
7XMbvGr8qvGrxrBp06ZNmzaltXeddp12nYYxAWMCxgTA0ddHXx99nXbrd9CtQbcG3QLbcNtw
23A43/N8z/M90yrS3Yt1L9a9GHzh/YX3F95wcOvBrQe3wq7YXbG7YmE0oxn9HvoVl8VlcRlo
SEMa/jfr/yveCCKIoPf31w/lF79HaiJVa1atWbVmwY52O9rtaAdXl15denUpTPx64tcT/4lE
5l3tnDoV6Gj3o92PdocZZWaUmfHfJF6p7WY8nfF0xlNoNLfR3EZzISQ6JDokGkIIIQQIeh70
POg5vPjsxWcvPnt3PXzo46iyWFmsLE7r99/tB+/qpx/Kru8aj6n8s36w1net71rfd7fvn+W9
K84xXgkfG13AHKdmcHcDz2d6B+Lh1fbIYSnfgf5DklCzQWAl9XTwbxCawf+3RC9Qw43zYglk
POTTwH8KZGyY4QsxGyy1LLWi+kFISNAhS2Hw6uqb0dYHfEbb6rMdouYnnY45C3pGP3fcMggZ
nHVaioQMH/kv8SoEynb7SGZAYt64zkwG52uXn2cAuI857qW0gnX+57us7wb7iu4MXLIUXFVf
rXnsCy8bP3W8CIO4Dm5/Tz5I3m18Y44HtbGls+VH8HTXc3sOgHOkO8U9DGRhhqhzgDV0UsqD
aZNzzOEgexMr+4L0kRfkQzBqmZFyAzBReaG0BHFU3aF8AXIRRfkSlJYsEDVB/CTf8Aj0fPp5
/TyYQ6SvfAzyqvxVngBjjTHdXAR4kYwE86J5zNwHspfsZfYAdZI6VxkKSkulragL6ih1gjIP
lF/EItEV1NdquLoDlH3KPmUaKD+IySIfWEpZBlq+Ba2Fsl3NC1oRdboWBZqXVk2rBVqSFmMp
AdZK1lu2/WDZouW1+oGcJiJEGFiz2nytGnjX8Xvmew2sA+377DlANjCnmTMgMc/bpRGXgJ6e
2UllQbknsmp5gcnylvIc1BtccPcDpYJcYIwHy32ll1IQrN0sb1UVvGf52QMvQlCt4KsZV0CO
0FxDCryB0ObZNuUFshXNc/+jAMh+Oe/8UhUgbFquAcW/gix3cs8pPgcy/5h9XqGjkK1MnviS
pSGXlm9hqTWg1rbmCqgAPneCBmd0Qb7yHw2uegoCM4X5FboPjsVBb4OTwDvQr3dgIRAfay0s
hcB4xlq+BHW5tlLdDdI/qVXkIUjMGf39i+8hpVPS4JQ9YFQ0FknvDxeobb5r812b79Iqoa1j
Wse0joGvHn718KuHcO3naz9f+zmtfeqcthUDVwxcMTDtqebUv8uWL1u+bHlaQvjPkrp9aqWi
UFKhpEJJsLnu5rqb60JJs6RZ0kyrWK2ssrLKyipQ8UbFGxVvpPVz9erVq1evQv9r/a/1v5Y2
JSC18vD/818Vxj8iy4QsE7JMSKs0Xbx48eLFi2mVyZEjRo4YOeKP+/nQcqVWXP5+DvoFeUFe
kPB1pq8zfZ3pw/nJ79nrXfXzvnKn7vd37dUkS5MsTdLmLlqXWZdZ/yYBSF2e+jf1lnZqhS71
wi3V/w7kPJDzQM60W92pU4bmFZ9XfF5x+LHHjz1+7JE2/sjmkc0jm0O++Hzx+eLfX8+pb/dI
nVKSOlcz9Q7FIrFILBJ/M/4P5K/v6gfv2i51ysZ8Y74x34BaD2o9qPUAtOvade36H/f3rnZe
92Ddg3UP0hKv1L+Zd2bemXln2napd9hSH2psl79d/nb5YeOjjY82PkqTN9XOFStUrFCxwrvr
7X2Poztf7Xy1828q81tCtoRsCYFSF0tdLHXx3+8H7+qnH8qu7xqP7+oH/27eu+JsvxMaHlMW
xEpPbXcoeK57dHsvSNztGhZngcDP5JOQRZC/VaYFmYdByC2f5hm/gzsRlu4vA+F1/IMOZkaw
n1NK+ncAMVEkJ9eG18uTXhrDQDsXW866BYI6BQ3TzoG7bNCatyMhPPKJI+UkZGjuqOM3HZIq
+FX2KEBCQi+fH8G3v59bzgZbx2Bhnwhur4jv3wyH2LOeSq9nwcny9z85UgCM7UlRlikQvi6+
knMlJL1yOTwXwbSIHOY60KprH2tjwPmzntvdGDzFjVqeb0CfSRkxD8QwY5HZC2R9sYmtIFfJ
ScSDOd8caYSAslLJIXaB2dzsZewBfaT+tT4XtP7aQstoEMPEVVEFjA3GAn0mkFcxxREw8rr3
mReB60jqgNJbTBGtQeQXMaIhUJ5JDAbjuGxiZADzrlwrN4F8QknxE5jr5MfEgrpWfCHvAKuZ
xEgQiMviDci6sh5vwTihz9NXgfKlNl47A8pN5ahwAZPIKk6B/EQ+k2tATBaKWgh4pIUoK0ET
lsLWJLDMs71wtAJ5XyywfgvKPTFOKw/OiUnZE1uB+RGb3dtBllLLWJNARCku6wLQNokn7smg
WVWrGg5qK9shr2UgslueWCV4f+O9O6APqPW0nbZaoEs5xEwAszu9xVdgfeO90G8giCv4KQ1A
7aO1slqBtuRgO8hfCZLrQQkji2kDTbHcsw4F57CUpIQrYM2v2vW+4N/F79esP4M5galGflCe
qcvVYiBHyrIcAWOAKWQ1EO3EBtkd/KTPLOs10C85B+rnwflCC7OeA8fT4MVh3cES5pjjUxXE
eDFEmQIM+zCB2vVU11NdT0Gvkr1K9ioJSqQSqUSCulJdqa6EMYvGLBqzKK39qAyjMozKAFNH
Tx09dTQ0vdv0btO7aesL7yi8o/COtIdb/ohCJwqdKHQCOp7veL7jefiFX/gFqHSz0s1KN+GO
9x3vO96QOTxzeOZwcMQ6Yh2xEJk9Mntk9rSpHZSgBCXSHn5JfZgw9Sn4UmYps5SZtr9ZC2ct
nLXw/y+o/y7jx48fP348TPpm0jeTvgHnVudW51ZwrHKscqyCL7N8meXLLH88zg8t16iPR308
6uO0RHNd2LqwdWHgNdhrsNdgGJtpbKax/4LE+e/tNb7i+IrjK/7z+vmzcv+en/wRm0dtHrV5
FDCKUYz6x/Vn552dd3YeUJOa1IQbFW9UvFERbnCDG/9Nf6kVrruz7s66OyvtxOvu7e7t7g3l
jfJGeQNG5hiZY2SO99d36sNjk/XJ+mQd6mesn7F+xjR9tdrZamernUAXutDlw/nru/rB79nj
99oVPlH4ROETYK9kr2Sv9M9P0fizds7RIkeLHC3+cbl1qnWqdWra77AJYRPCJkCv/L3y98oP
L1+/fP3yNcw8MfPEzBNg+dHyo+XHNDsMnT50+tDp7y7v+x5HH3386ONHH6c9TBmUMyhnUE74
5sE3D755ANG9ontF9/rX+0Eq7+qnH8quqRdg/2w8Zq2ctXLW/2au9u/5wb8b8X/msklZvnz5
8uXLv3sH3T8a+6DYXigVkHdXubrgjNIvun+F82fvvjh9FfzXew30Hg2ZSvuVz/oKzNfKXktX
ePvi9ScRF+HuwsfF4+pDyMxMpyy3ofjN0HY5zsPTpm97uTzg15zqZj+IbKFNjB8K3ragIXoL
UG4a5eVCeLkqrpSrJgT2EoeyLgDzWeL45OMQOi3z6Ayx4HfLuivlLsSWSHI4XeDZqh2InQ65
rgeVqNAb8j8JctZxwPYrS3ovWQZXSz0r/uQ6pAyQHaxLIOxs1vG5YiAxOmlj3GZ4Pu1lvad7
wcgn8mqPwDxh2GQXQCG3vAGiLbdYBmaINM1CIPfJc7IbiJyimWgL5inzgLkTlBzqYKUiKGvF
VXUhyLvGl/IV4BB95EswP+MbMRnM4+Yt4xwo3+GkEVBWrhPNQFRSLooRIFzKPXSwFNCwNwDx
WCylNyhjlAh5E5TeygF1Cyjh6lbbJNBOag/VfqAFa3dtnUBOIZe5AeRNmSKdYD9hv+r1BKya
LaNXa1BfKEXUkqBkVAdbz4El0fqFLTMoMdpLtTMY+0VXtoNSRjy2HAHumCHmPXBFOKslzQZ2
MdH4DBy97V3sr8FcZZxztwB9jHNEyvegVdB2WAeDKGvZaR0D4gd1lXUuyAWsUruCaZhh5mqQ
p0WwpoB4rixX9oK52zysLwDnspRnCe1B8WGPjAdZCz+lE3gizEZqCUiZkJAj5hK4+nlSUgZA
UK+gisGfg88PPonBX4Nrrss7pQjo58xXyRPAskzZru4DSx7H8KDa4Ip2tXGvhoAvHWgLQTnA
j56xEFsjwZ34HagbrM98n4GaV2lINCgHuabngexlMsbZfGCJfemVxcf//YGdTjrppPNnSa1A
XlGvqFdU+L799+2/b//vvyX+/yqpd2xSK8jp/M/g3Llz586d+wAV59czY3OrHjj748OwO2dB
7nY/TRgFwf29v/PyBUX3Pamcg6g31vuRW+FSwrnIt5fAp7zjtDgFtpayvNoaMswlMMMEUPP5
5DAnQO6rXqrlCrw49+xpdBzo26xTkrJCXL/keZ7qoOU2T3iHgNcQVVrmgTuvK0GuAq9tAYPF
EUjMI5a/ag6vfWNv64XAtsvWx6co+A43s/tMhbIj8u+p9gIMJbaFbQrEZIs/njAOnF8aZYza
oGzWKoqPQexSz8kz4LK4PvE0BqOivkxaQEZqRU0Bcrk5wWwCMlhmlddAlmewzATmOXlMRoN6
S8xTLUBWDtMMZF75mCigh9lTHARjrNxsCKAGTglwV9YXM0FeEEHYQBmoHKMVKCHic/UE8FTe
ETEgfeVpcxnQQpQS5cH4SGY3s4Kjl+2yVxCoU7UeqgrWcfYB3r+B30/+r4J/A3FQfC6doAwX
fS0KmFaji3sVmKZx1TwJtt/sVvtC0PLZhtqXgXwq2luagpqsjlAFWM6qW7VPQI8zC7srgXAZ
ddyfgKwkDaMaKFU1H9UN3md9R3sngjnQs84YBUSbHd1dQAieMxRsd3xaBnhAy6Q11YJB7an9
Yn8K5knjZzkMxFnRWN4BswXH5CTQ6+vtjGpg3tQvpBQCc7WrcPIRsNaV3sYtcD8yAokF19ee
hXoOiFWif44pBEkzk4/GZAatP43lGNAVZ/ekX8GsnPmB2RHsxR0F7B7QD7kNuRVEGWWbnA+e
TUmZ48aCnCZ7qEPh7V5XlSQnmMvNAnpzED2sF617wZrZmOzcDMZY/Tf5GgKy+8zwKQVaX7zU
O8DyvzrU00knnXTejd0Td0/cPTHt/bpT506dO3Uuv1/iTyed/0W8d+Kc/XXocmUAxHVzno7o
Bf4H1FVetSFDB83bsRJiLMlZE+uDa5R2XP8Cipr5A30MSC5rLJH9QItXN9ungO1Nwi3LaDDL
pTg9dSDADLjm8w3YU5ytjMng7StmZBkFrvX2z9+8Atc1Y3bKKWC/p76jBYiFDIqJAGc5vYt2
A7StSjFNgcAhwW2CToLzjtd152Awx8QMclyF4K/9rTmD4dfbpzsfOwzu08xnL+jt9e/N8WDZ
bC0q2gALRWsCwDPVGKgHgTXAYXrPAstNr0DfWNAjPEPlXeAKDuEP9okOu9dFsA2z3bAXAzO/
8ZveGzxHdOkJA+WeOkHtA0LSS/kFjHlGe/0zUK4pH8tksNy1RvpWAdMqHpllgDUyQmwE7SdL
Hdsq4K3MwxEwgjxhruOgDhaljeKgLbN4rPlBi9QqWHOD+pVmtWjAUkUoX4Elr2WcV2Mwf0Ua
+0EbpOzWPgPRiZ6yA6jl1PlqIBifmRf17MDXPFZ6gxgvNnAV2Caryxcgm8reelXQ2nBdHgDV
Ye3hKA1GrGytPAMxR22ingf9M091T3eQPxJDRbB+bhlqKwqOw/Z21kvguqv/JOuDucxM0C0g
B5nfGSGg/CZa4gIRzQPDD4yPSFK6g/HQ6Gm2B87JqjIX+Jz2DvJ6CfInfYf5HURciLRHjoRo
x9uBrzuDu6WrauIjME8aB80mkHLJk9V8AeZSDiu+EHUxsmXECPCe6zXQPwfY2jsy+PwGcWcT
vonOCfaPvTzWkiCeqxPtG8CT4Drmqgm2saqvpSNYjuq/KucgOcaTJWk+eOX2Key/AuLmJnRO
9Aafy2qAZeo7h1M66aSTzl9O41eNXzV+BY1pzAd4W9//OrY92/Zs27O/Wop0/lW8/3ucDyRk
cGaBHJ2D1mUCfPLbCnk9hcSSarweBOpC/Tc1CjKEa7m9a0BQjhxXjc/BXt6eSakHwY2zhIWd
gCjVEh5bCF7neV3QehzyPPArVjwYMqqh+QOWQQan7z2XCRna25JCe4LyNZ9a6wMPWSt3gudt
Smt5EmxjLT9pvcErl62BOhNcu+1V3iyE6KaRdx8fgI8K5XpYciuIsYov9eF54YhLD/uB5yvz
huEA87ZZjZ9BfKnUV+LAzG3mEj1BidI6qa8goFzwqZCdEJIr0/JcPpClc64H+f0g7HCO0nl1
COyY8XnWeuDtDPQNXQ4+8zJ8nvkh+Kkh97M1hoDjoWVyOsBPD6mWfQD4N8vwY9gK8AkIqBvi
Bb6dAvdn2gK+wQGtQ4+D35XAmyFlwFHB91bgC3B84ds+6Cz45gsclvEweI3y/yE0H1gXed8O
3AJqmKOZXy0QJawdvHOA9YC9hM8BUI9a4x1zwVrLds97FajjrE6HL9DA9pPXr2CuV2qoc0Ap
rx6x9gKlhfrCYgHbAMsz2xqwv7BHOg6A0co8a4aBmKSV134EUVk9qOwFLcISpu4AESkilECw
T7df8RoP3s29M/kkgN3L2+L/KcgeIotlFygDjZ7mC9Ceikiigd3mR04V3OGu/HENwZkppXfi
PEiqFrcodhA4O6S0TfIB5bmyXJkDykptj3UUGAvMqe7KENI+4KpjGWTKF5w/sAYoA5TlNg3s
T+2dHB0g04McPjmskPFqtvPZRkNAw4DyAbvAz9uvsE8FsLywPdYyQEC9gFJBLyG4ZED30Fpg
NZQb5lHQ8mkXlRJgXlXcIhaMWaK/Pgxsfay1tRXABEbTGPQxohcbwTOEnfwv/sRrOumkk87/
VrK+yfom65u/Wop0/lW8d8XZ8rn+XcBYMFtFH7U0gTdtXctS1oEWHOhMKQEJuTlg7AHjSMT3
rsMQWNZroRYLtm3qL4oPxI6Vpx4ngiODfy+vQ5B0wjk1fi2cX3LzwkVA+9I6Ue0NjgN+tfgU
nOMT4vTGoJemIj+Dd5TPK6UGWOo4T3sFg6d98lN3MrgyBbbRGoBlUrKfz8cQbNHmyfZQoEDW
LBUaghyUMlxJAW2veVRUAVdDvbeRAzyF5Qs5ABxN1VG8BJmf1bIUkJtz2jjQzluX+30GRmVz
g+cNeBYnD06+DrK1bCRvgPKjNsjaB9Rz1oc+WUBdqhZzLAWlv9rCpYMcqN8wGoEoQ0OjFYgm
ak4qgSVRXeHtBXKt/MVTAszyZg2zKCj1hEVbDGYKRY26wCRRWzkG9iT7p74WEDa53jwLhuRL
vIHvRBFzLGgf/Z+3bqhTxSTZAXiNl8sA0YpV6ioQt4mSzUFrbjbTfwFTd8cnzgIaK19aH4OS
V43VBoAxWQ/DA2ZrGtILmCT7yUZAHblfZADjmtHAyAhGBf1hyiAw6us7GAbuO55XzimQPDsu
Jjoj2G7ZZ9o6gr2bvZ/jGHhr/tuCe4LwE9O1KaD0Nju4RoI5TO4SucG8LPvzKdgmqRmVY5Bc
3lXF0wdirHFbEpIAp28zx1Sw3FZ/UReAzwXf4wE3wH9/8A+ZroDq8HodOgiUp1ooDUH9yDbE
Ug7UucZICcjaopScAsoczccSBRhqP8dQ8ASmLEnaCs5zyU0TbBA42bep7zZQ86lFrN0geazr
++R1YLQlQt0HegHd4BtQ86iV7ALUZdZZFAIKazu0vgB0+quDPJ100kknnXTS+TC8d+L86nL0
zwnz4fFY9XB0G1A3+xbhc7B3Sa7r0xFML2dXeRQSt7otKXFgOp1v7B0gdILjSQ4viPo2Mebu
dchTxdbVngeSM2hVtawQO86V1+gERmJCt+Qj4Fs0W0/3RHA0sv/iug1Jx69NdO4ET2VrEU2H
0DW+bwP7gVdz6tnXQ4b26jqv45D43N03ohlU31bKVfc+5NqdYUiBjfDEfufF3UzgGiCvmgoY
oWKEUQiMlazS74CsZQ7VDoDMI4eKuoBT+Kl5QPnYssRRGWQPJYd2C2wlHHN874NnnSe3expo
9ayhWlVQKopnWn0wi+mVUuoAAUQYDYGvzUQxGpQ7aivRFggXs7WeoJ201nf0AWODjGEXWPNY
J1sUkHf1eOMeyJ+N1jwFza2tEivB/bN+ITkCzDnyuW0IaNMZKn8G2doYnFIJPOXM657e4B6v
T3BmA1FPOSHngX2QbatPb3DOcIUljwQ6KbmoC9q3tLNFA3m0zJ7cILyNrnQDVVcza8PAGGy4
PO3A/FT/yPMA1OLMMu+As3ty0cTGELcursrbw+Dq4ZruLAjGcr2aMxdYs1jaa8PBNd11U5SE
pOC44coIcN1xjUvpDqZbMWxTgEZmP09PSKmfGJ+4Gnxf+p30XQK2p74EHQLbCts9WymwBFly
WUzQj8gKRmlw5HP0s38FWj1HV5/HoP8gj5Edgh9krmWdCa4lyXs8n4OnuifSuQlEuHB5SoKr
bUrNxCpgTuCkOA3KJuV4QmtwVU2pnVADfMsEDve3gFd/n6k+ZyEpX3zjxDsgjhkJ+jrQ1ggr
AeD61GWjLrg/TTkf9wBMt5qRFPAdqBb0zvwngyqddNJJJ5100vmP5P1fR9fFq1liA7Cl2As6
voCUWL23uR/869nqeheHPPtz1vMqBPczP78V/Racp5N/VB9DYgtncMR9sO6wb1TCIPZwYpC2
GfRGKXOMO5D0UCmakhUc+dQividB3H6+JdkO8R1SXns08NzR9/mcAJfdKOHMCNmTAna6H0GW
ruUqBG4C5bKjSczHUKS33rjsUyjToMCotvXBq5RP0ZBIsJ+S+v1wUFtd6S6egb5SHyzegLrf
zC5ugtFWjHJPAzOrLGb2BdrINUZ2kCvM7eZ9sHxrya81BvcAs49RDNR69gn2GFC2afUsn4CY
b86Xu0B01DN7YkE/aXQ2b4CpyMn6JVBvyoyWfmA5af3Fmh88Gz39jInABrFf6Qf6CXcLfREo
bcikrAHjU8/LuCXgLpqS390R1I7qW69JIMpa8ymHwCzriXR9BXK8kdtTA4y73DCXg5Jdppi+
YL1tWW8dD05Lim+SL+hheuXkQ6D10NZbQsC9zrgqvwP3DtduTx6wLtQU2zhQLivF1bNgLNav
ug6BvaDluroPnDGJ/eOnQ2LHhCbR48FcoC8xHoHew907+TdQXUqM9huYhcgtLoPeQz9k2EE0
kUM8WSF5xpv6rzSwhXqt9X4Kyn4GCw8Y4Z4UTxxENXr7NmUXeLXxjDICQZttqWoPAGWkslNb
DraOtglWOxj9xFJtGMSXc00yRoAZKH/DDZ65+gRPJtBmWbdrz0HsM75WKoD7a8+v+n1w93cP
dY8DV72UsgmHQc2k7bENAdWjZJSNQP/CLd2D4dWa1/feBEBSYLwS2xys+dVyMg/Y1tkf+HQH
S11ttLcXuMqn3E35FrRnamcboOwyz7vKAU2AD/Ce2HTSSSeddNJJ56/nvRNn45y+0lIcQm46
itpNeBmb0MqzBTRF2h3NIaWVp7d5CFK+ifnJIsDvil9uvyR41Ds84/Nn4GmZkqh2AV9v33l6
B5Cq+UQdAeKR0SF2Lpg71HHqQYj+9uUUpSKEfh74s30Z+NTIttIsB8rDhP5ePcG3jTU8UQNP
7qfFzYnQvm6jipM/hbw/56hUYzq4/fW8fANqLqWfkQHEiehJvi+A3W+Pe/KAtZ+lrPURGCvV
x/IVKDeMLlpnEPsZLE6B+dAc5TkEKYcTLkRVBj3QXdkRAEpvJUqNAnOz9sLeAMyn2njbTyAn
GlVlAbAttte2lwRroDrN+g2k5HW2ij8NsjFD8QXPDWOvcRxUYemlZQcxw5zg7gVmLXdb1w3A
obZVR4IzOfF8wh0wGxkP9MdgjbQXlrHg9iQ+elMJbPPt1ewvwWeqX5fAXqAeUYpbVoM+ynho
2MBdx73OWRDUZ5ZYZSaI0lwzDoEyX1tquw+eZtKRch20OjRT2kNso+j9EclgqaPGK+fBzGTe
169DyiJWSQuY1cxpRh5Qv1ETVF+gM2eVziC6iJ/QQS9sjjROg+qnXxBfgqeOvsDIC2ZTc6dn
GpiR5hMxBMxwVomRQAnqi9VgvWHZY/0cjEeckBHgGSKvIkEdJBoo00EmS2RFkOFyt5wL7iau
GM9cMFsrEYYbrKOt52yPQQ9w1zDjwbVULxM7A0SEvsVTHpQyanfxBLQZwqVlBm26f9OgCeAV
EOAKPQI8Mr+Qq0CO0KfrVcAs6P7ZmAyOOV4bMEG4qeAZDbRXfrUmAY3FCrEVfHP5Pgr6HjyH
XPeNkhDf5a399TAg9q8O8XTSSSeddNJJ50Px3g8HavXtN+VRiK9njI/sDfpq92nXBYipGJ0p
pRvccN8blpgLkhrYdlAf3j5213s5FcIyB26RYZCpcIa7ylJIeuM1NfkesI+VshMo3VR/yxMI
6mI57JkCtmZqfnMcPKmaGBB7ExLGJgXpDnB1ZKarJBR7Fjqs1nPoX6zVzHW3INfE7HlqrYDk
x85HHh9wZ/V8HPczvHj0otq1ZRDV7HaW8KGQMdn2nVdZsGnqTNUGymDlFI9APhStjPMg1iq7
lDkgNTOCpyB3G831uaANV9dan4HXbt9LoeHg83XA1yGlwaF6J3vXBetFL7dlNNju2z5SS4BA
eiXeAccv/kcCSoHPfb8qQS3A64qjmi0n2AK1+XoZUIcg5K8QPyLuk7cnILFM/M7oqqD8rL7U
4kFvoM/xOCClbHz51w4w9+j1PY9AThDhqh8YraS/uQr0kXoP50Uwp7NePgB7WftFR2XQsltq
W/eDdtxy0HEa5E3lF8tbkF+JWIsEd09nVfc40Ot4BrrLQGKWhEdRl8D5KiVDfCgk13dOS6wO
8pnQzdVgrpX35QYQjcUW6Q2coLnYA6aP0cJYC+ZkI8ijA+P1Lu5hYPT3jNBtYL4yV3iag+eQ
Z6arE8hAs424C67SninuumAdYr/i0w+07cpX1o3AS+khG6g7tLpaF/Cc13vqP4A73L0uZTSY
/Y0Y/R6Y5fiOimD51TbSEQHqKes3viWB/fYLlmdgL+2V36cWeC0KeJ7hOXhX88sXkgVsPS3x
tgJgmWB5besJLh93PuNX0AYoTdS24LXJ67G9JXjn8W0RGAX+1YOswV3AO8q/ql88WNrYm9hO
gHZQNvcUAnW1rZLlA3385D+Z6Xmm55me5x+Xp77H9N9F6pe8Zs2aNWvWLKjpV9Ovpl/al79S
P2zy4sWLFy9e/NVa+3+H1atXr169Ou0DBqlfgBx4a+CtgbcgKntU9qjs/z55/tV+9Xv+/D+d
f3e8/rvY+mzrs63PYOrbqW+nvv3H9f9p/p3O/xu8d+LstNlGxe8Fh2/Aee9nYHniXVK2gsRI
o1yMCVGfR//wdj1kXWRJ9D8PsRXiCyrrwSeHbX/mHOCd3f6dchHy5wh+6hMN/rHeKcoiyNnb
t2/odNAStELq12C5IldYF4M2yePyLwhR51/fS2wEH80Ithb4Etrc7X5v6lnwmhGsZckLrh+d
MYlzQOSQkXopiLv+Kuh1L1A7e+77XwNlTUKYsQAyxWbW/TaB0lg8MCuB+lR9bHsFcojR2tMC
RJispn8C9kG2p9bZ4D0zcFZIZ/BrGNoty49gm+e3yDcjqAm2p7YzYOnicHqtB98LgfaQ5eDu
rs9PegWJXnEXXm8D9YJnfmJncPsn141bAK7BybniqkFyicSv4w8BFrnRPA8+um/VwJGg3lLn
sQGUO9blagOw7vByOfzA/pVjr1898FkZGJMxDLzzePv4nATZU3cZm0DmF/3UbqBt05LU/WDW
Mnt4akPS0KQR8V9ByiKXTC4J0fNf939RFl6ee1Hg/gtImep8Gn0AXB85y6YsBH23Z59RA8xN
xjGzKLBGLmUzuEu4Y91TwFPao7ivgGE1Sui5QemnhCiNQFQWFtELzLaUE78CzZVYZRYQILaI
NaBNVftbN4J6RIwSXuAp56mU/BEoh9WsqhVse225vK+DhlpJqwGiqFBEMijztUbaEVBT7Kvs
pcD62NrNHgJqD7WFMhpkXf2A3hDEaRnnuQuW8bZk1QTHAa/iGQeB2USZrbYFpZ11vj0crBkt
gfapYGxyX3I/BOfXiVvjLgHV5VzPS6A8o5xdwGVxNopfAsl7k+/FtwTXCefFhJrgupQ0OekV
mH09O1Niwdbd62vLRxA8Lvh16Hd/dXj/60n95O1fzcnZJ2efnJ12IuxxtsfZHmdhwNIBSwcs
hXPzz80/Nx++bfNtm2/b/NXS/udz7NixY8eOpV2IVP+i+hfVv4Cha4euHboWTnc93fV0V5hR
cEbBGQX/amk/HP8p/pzOn+NI2yNtj7RNuwCadnDawWkH4dLCSwsvLUxr97/Vv9P5MLx34uxt
uvpmnAwBpo81xx0IK+t3Kqwh1LqXY02ZglBve/XH5c5C0LDARyIFSn+T91DWziD3a3UMN/g8
8v4m6AE8y5s4K6kZxOVK8bY0A6OMGJ6SC5TNYp09GTIuDyiQqQ5kvaX6xlSFBlcK7igxGHr4
9rk2px44A2UHswoY19yPUvqDNkeLsZ+AlAlJxeL9wdHTvkQ5BzHRz/O9LAa2n6x2axQUGlQq
srQAWw/tR/ERaEXFNksVkM3MCDqAESkaqt+DYmq/2leCsk15JO6CfGlkc/8GhrfbntwFjF+d
dRPegH7M2SqxJrizJDdLbAjSMDJZloPXfG8zaCW4Mif3TboHKRmT38YZYHynfyTPgtJCqWct
Da6bxpiUMaA9sq3SnoNXngBLcALYLng/850Mvg+C4kIfgiMp8JfQxWDZYXvr0EFP0hX9UzCH
GheNJSBM85H5DTDRKGFUBLfbud45Aqz9bDUsNUG7ou2wxIPvuKDtwX0hrGZWR6HR4DvE+7fQ
L8H8UR+ZUh+Mj4zNngXgGugOdN0At+o+62oGxjZ9sX4CTI+UemnwDNe7eCaB7mMeMgCjGzXl
czBS9CXu2WC+NC6514CapOwRM0G5pu6xtAQtlzXWZzX4BmWolPE1BJrBn2XNCNam9tm+BUAs
ss/0+gLUzNYwWxxw0fhODABrJz6yjgCZTUSpm0BOwkvNB+pj7bjlOMiS8oi4B8opI6/+BmQx
zxCPBlQ06hq/grpFKaFkAOLUz+25QZ1qvWlTwb7e64T3OAj5NOOcTJXA3s/xjX8Y+PTyPxha
EfzX+F8JDQElSmvkdRfENTWXZR5Yr9nOeLcGc6020pEbLIXtG72qfbhAjY2NjY2NTftkaoPt
DbY32A5NJzad2HRi2idfU9vt27dv37590KpVq1atWkHz7M2zN88OjRo1atSoESy7vuz6suv/
uJ/fqzz9/fKx4WPDx4an/e59qfel3pf+cbvUSk+T3U12N9kN84vPLz6/+LuPv+XUllNbTv19
+eyV7ZXtlaHN4TaH2xyGzp06d+rcKU1Pqei6ruv6n7fDP6ufv18+o8OMDjM6QOOwxmGNw+C7
I98d+e5Imt1S35s7p8icInOKpG3/Z+34vvrc03RP0z1N035/Vu6zcp+Vg/L9yvcr3w/2T90/
df/UtE8Sv68+556ee3ru6TR7dS7cuXDnwvAi44uMLzL+43Z/5FfvGi+/58/v2k9ERERERAR0
93T3dPdAs2bNmjVrlmbXP/KTVbdX3V51G9ontE9on/D+cfyh9ZqYmJiYmAiDBw8ePHhwmj+n
3tFJ1cM/O74P5a+pnPGc8ZzxwOtJrye9npT2BcS/yr/T+Z/JeyfO/jn9D3rlhMTIxJMRq8B9
JeluVBvQL4LnRxg7qGvSunLwaetGu/uvh5CMvn4pyZC3d5a6mYdB5gXaAN8zkKmhVwvrCsiQ
PWMn4xS8MtyB1tvw7OPEe1GTQcnrKn2/L9RXy1ra1YDOHfooc4uA0ty/hJ8AUcLzjVoURFs1
UL0J+i05yjgF0s/81P0Ukvp5Fjt/gNger95EjIQc35c4VfUNeC8MyZF9LDgSLGu1ULDn0Xws
AWB0ljvM+aA48DY+AXWi6CdOgOtxcj3nW3Dlc+7Xn4Ocb97ACbp0Bbk2gLTp1TyzwNinf+u+
CVo2scHoC+yzVnbEgHbX7udjAQde1fwcwMfWs8ohsO5wVHEcB58Qv4SgkuC46L07YBLYxtl/
8IkAS7isJ3KDfjflN9dcEKO08hYPqPusdR1VwIKPLSgIrL/4FAg8CWKAus3yFbjnmKvV5mBp
5hXvXwKsv3odyTAMvKx+/cJOgc9h3/wZC4JPh8DSIcXBq23guND5kGVg7kklv4KQxCwLcodD
0M7QEdn9IGhb6MnsP4NPu8CoTNXBUsiW5BMASqKlrvcc8K3rfyC0PAQuzFAp63Vw9PZZEaqB
76OgvNl+geC2WUcXXg7BubO3LbYJgkSmoDzfQXDW0JF5n4C9lfepjJNB1FbKqMXAUls9Lj4F
Za70Mn4FY69RKbkkpDxN6Rj7GXi+SukWPxeYpddwdgIj2N0uOQyUrDLArAlGDX29kg3MbAS5
F4LZQpazKOCu4M5qRIFnrfunpJ5g9HW7UyaBUkAWNOuAWMhd5gF3hCnbgbuYa5e7Eeg7PFH6
apDZTbc5BxRvZYz8EfT8rk3GRlCteItL4JXDYpERHy5Qpx2YdmDaAQh5FvIs5Bnsernr5a6X
sO35tufbnkPY+LDxYePTKqpr76+9v/Y+fFrq01Kflkq7Zbn8+vLry6/DTxd+uvDThT8vz8Qs
E7NMzJL2e1HpRaUXlf7HdjVr1KxRswYsLb+0/NLysGr1qtWrVn84vaRS9krZK2WvwHD/4f7D
/eHQ9EPTD01PS2Cyvcn2JtsbmNB4QuMJf8EXHWoPrz289vC0RGf98PXD1w+HttPbTm87HZb2
W9pvaT9Yu27turXr0rb7V9vx93j+4vmL538zpaVbt27dunVLSwTbtWvXrl07uON1x+uO1/vv
L7hucN3gumkJTa11tdbVWgfTj04/Ov3oP7b/I79613j5PX9+136mx02Pmx4Hnzz+5PEnj2Hb
tm3btm2DbHuz7c2295/Xx5rVa1avWf3+9v/Qel2wYMGCBQvSEtidL3e+3PkSqq+pvqb6Gpj5
68xfZ/76z4/vQzN6y+gto7ekXaj+Hv9u/07nfxbv/XCgWBt0MGoZ2CtZdgS2geSNsTvdL8D2
kgUOb9g9cdeIWcfA3OLskTAS8j3NdKPmdLAmuZa5h8Nj3Th5czIUuWUfUzUMkr8R7phKcDTs
QvXoXFCgYvDonMOhy+oubb/KCZnP5Vtbxgbuvp5vPT+D3sW9Q18CyiP1jTwFSg5C1WjQ13nC
nAEghpmRhgd8VtnXB1WDvHfL/Fy1EPjty+IVWByS2kbOck2GDI0C9vtWAK1u1I/J/UDWc61z
uUA+NtdSBpQb2jB1MIg5KYedRyDls4Ta0QvA7bH28DoBlmLaK+aB00yZ4VwHWgPtmuUaqFHy
qswJ5ljpMuqC2CWCxVbQX+l13L+CxWq5ZnOA8aVzXcIa0L9NijWGgNDVp9o6sA6y9/D5CcRQ
9Y6lCKgJth+U5aDf05e6+gEVjRvGdGCB/M3IDSJcCdWWgXFPvlXHgZJXOW2MAvERzzgExiN9
j7gKSrC1o8wC7FXOqNPAnKPnNu6Bdtfaz/o9eGezbAidAV4tzMiQJFB6WHzV1oDHPS/lGnhm
u18nfQ6cNybLz0B1a91EP5DzxS9KGbBMUcaJVSDd8ifjMhi1pSJKAQhdrQDSj+dKR9Drm20p
AkYL3cvVA2wFrS+VosBNo5vFBCOv4XSVBftNLUyTYHxhPWxvAMpefE3A/omlvpgLxiXzuqwD
utRDzCgwi4koIxiUSco6yyhQy2gFHIGgmuKOdh00f6WWHg96Ic9r9xAQ6/lSDQettJrd0g9c
n7iuGR3BGe2+a6igtFYaWOaAoZoF5HZgqnSKGyAqqx779yCuWqqZPcHbozbWN4HdsHZRY/4r
SNq+f6Ce7na62+lusDPTzkw7M4Hyi/KL8kva+m7tu7Xv1h4adm3YtWFXOJrvaL6j+eByn8t9
LveB9bHrY9fHwr0L9y7cuwBmQ7Oh2RDoSU96/usOMKknWEuwJdgSDJ56nnqeesBFLnLx97dL
rTA93fJ0y9Mtv99vKhcvXrx48W/6yzElx5QcU6Dqrqq7qu6CXzL+kvGXjLD4yuIri6/AaEYz
+l837H+g+Lzi84rPA7FYLBaL/5vlW8VWsRU8ZTxlPGXS9LO0wtIKSyu8vx3fVZ+5onNF54oG
gggiCAatHLRy0ErIvi/7vuz7oOMPHX/o+ANMyTElx5QcsJ3tbOfP0zhz48yN/+b1jS2iWkS1
iIKfx/489uexwElOcvIf5f09v3rXePk93rUfWVKWlCVhYtaJWSdmBe5zn/tQd3PdzXU3wxSm
MOX/oofWrVq3at0KlNvKbeU2LD2/9PzS83/e/h9ar0fjj8YfjYd1l9ZdWncJ6EQnOkGLyBaR
LSJh6fyl85fOB5rQhCZ/PL4P5a9/H/9/hF5cL64X59/m3+n8z+K9E+ffrL+1dGuQNdqvjdEO
7FOVr8x5cGb9i4KXT8PxVo/bH9sB+a4FrQgbC4XG5b1VeDu86Y7fq9Vwpda982/mQVZH5vZ6
EuBI8nF64KMi+T/LOxHaZWm7YlB9CLRkDiwVD66tSZOTD4KRaHkrz4LSRlzVPgf5jbnKqA9K
QS0nvcBo40xIvg9M1V5ZL4FyQFnjfQCMy85Zr+eB5/uUL20TIPhumG+OLpAtIdu8rBPgovnk
h6i9oJxxG0pzMDuafcxE0OpYyti+BbHPk92zGNQM9omWRmBprHQR0cCXcrkBiJ0UUp6Bpllm
2DeBOtfR1ustiJp6R48AZaQ51LSB+NmpJ1cDTy7XM+ccMDWznWcZeGz6SqcGWrzaUVkN+msz
3LwElsqOlt6FQCmp3tR6gixidpOdQL8jNJkfZEWjuGcx2MvZZinB4Jhob28fDjJSqqIbYJV+
Zn9w9vPMSTkGejFnQ9EalNrWivZhoJwXd9UtoK2jHVPAesUWKcNB7GC+GQKxzRM+TsoKvDLe
yJWgXdGirIdACbM2Uh+A8YVzcso1kLvM7a6ikDxXPOIgqIY8r2cFy271gFYQxHU51cwC6isq
GK1BeSDLG0VB9Vc/d9wGr2RthFoTxDTtiXEIZANi1U7g/5FfkYBocGbTy3EDjBBjm/kIrBnt
G7S5IBfIfMYY8LR0LyIFXFGeFa7vwWG3jdOagDgpTOUB6Ps924w+oJ1Qa4itoOa39bDbQTyW
eeRbEJ2VMuINeCfKgspvEDjR+4jvcHBu1F8ah0AvZzqVr0Dm15/K0qDeUKeYC0HLYDtiKwV+
xy3n1JFglbYgUQGAzz5EoMpSspQsBdo+bZ+27x/Xi0vikrgE5nPzufkcBpuDzcEmhOwL2Rey
L62SVKVKlSpVqsAOdrDjn9ive657rnvun5fbssyyzLLs3bebU3RO0TlFwdPB08HTAT63fW77
3AavGr9q/KoxbNq0adOmTWntz/c83/N8T7i18tbKWyuhe7HuxboXgy+8v/D+whsObj249eBW
2BW7K3ZX7IdLnP9Z/fx9wvxHy1NJvSX+vnZ8V32m3rJ/3Odxn8d9oGKFihUqVgD7bftt+20I
HBA4IHAAvGn+pvmb5h9AkX+HslhZrCxO8/u/54/86l3jhY50pOP795M6NUA9pB5SD/1Nu8vi
srj8x+NO1W8qH8r+H0qvkTkic0TmgJp7au6puQcoQxnKAFasWEFME9PEtH9+fL/Hu/rruxK4
MXBj4Ma/zr/T+X+b906c3RvjvrPkg5SDWoN4Haxfi2kBJcA+1GhivAW/77wX5xwBb/MrRw1/
uFHu8cNbiZA5V/DNgJngVz30M5968GaZO+R2IlRZWLBMvVbQocDHiYNjwBrmVyR3BHjWp7xO
fgDKLdUhCoEWJn9Re4PsKbPp1cHcw0vjJCh3mCUug3uF51BKBHjN8YsIfgKRQ15meHUHLPMs
LQxfsHbyirRPBMVtaeioBGErs1fMsgu8jlpf3j4KCTfcbW39wRgvF4sE8HpjzWsrCwnH4grF
zQNinNOd5cEyxP97RxK4/F1Z9Nxga2EP8GoIjBUfkwlcs+PKvHkItnr2X3wOg9gismpfgzbT
Ms/+CsRg9WftKdiwBdpHAg/EblEOxGpjgJEVjO/1Cq4JoOZTgtQIcGdz19RzgG25VkWrB+q3
VqvNBPmJ/E5dAxQw3uiNIGFQrBb1EqhqHHT1AddhvZK8CfYXPpf94kF7ZvvepwVY6lg0bSto
xdV71lvAUnO9HgBiidzi/h60X8lgaQWO41oZsxDYGtsviuvgdc/rmVoS1HgZ7skFcrD1tGqC
u4Zrs5ELUryM3NIX7KO87vvmg5SLnrbEgWct3yvHwHVR36p7g62Fmk9tD+oD9WfLxyAXKpPk
NnCkOA7Zm4D4SdZTq4FeUoZ56oL/EUcWSxbQGqidrKGgrza7MxLEQ1FBMUDOtqSIT8HzWF9O
EFh+tMzUEsGsblaUv4AywXHJcgI8HTwbnCVAbaqNVlUQ1eRymR3MpuZKIxhEJuWtKkHJxU6t
EHhnI0YaIMoz2mwG1oV8o/wC7iB9iXkPXDfM74wwsD1V7stvwWukNZu1/H8FycfvH6ipb4dY
MXDFwBUDoZ/aT+2npq1ftnzZ8mXLocqOKjuq7IBTc07NOTUHtl3bdm3bNchwJ8OdDHfg7Nmz
Z8+e/ZuOS1GKUsBlLnMZLNct1y3XISoqKioqCh70edDnQR9gBStY8fvypb7V4o8SwX+WLE2y
NMnyNxUr61TrVOvUtN85c+bMmTNn2u/bUbejbkfBvOLzis8rDkndkroldQO/yn6V/SpDpCvS
FemCwrMLzy48+8/L9Wf182e5evXq1atX392O76vPaiernax2Mq27WV1mdZnVBQIWBCwIWACR
2SOzR2aHatZq1mrW9x/nzlc7X+18Be1pT3tgS8iWkC0hUOpiqYul3qGSmMq7xsvfk+rP79pP
0sKkhUkLYa/vXt+9vtCCFrQA9rfc33J/S2Ayk5n877P/h9ZrlglZJmSZAFOaT2k+pXlaPL0c
93Lcy3FwdsTZEWdHAPvZz/4/7w/v6q/vSrU71e5Uu/Pv8+90/mfx3omz1z2/3MGzIUs3v4I5
C0LJCqGf5KoDgZf9D3p84Zz529YnSXBpVGSr22dB3xxa02sjBBnuUW5/KLzePc8RD3W2NRw9
+ygUDczXo5I/OJeIcV59QQwV31j7gowUC/W6gCI3kQzyI1GGYSDay6FKF1CDlelqCdDjZDMl
CRytbLN9OkDc49cnYl/Ab5euZTsTCwUHlZpT/g2oGbTntlUg94O4D1l2ZWuQdRV4B9qX20+A
kjmln3MWMM04qMSDJcKSwTYXrAn2TY4NYBS2jFA/Bb0cEeIyeFt95vmNB32PJ9xdD4zBen9P
fnBk9Qr3XwueoXokP4BSVXupdgO1vCWSnqAMMGeI+SDyK3uU3WDEGdf0SuDe76qY8hDUp8od
bRfIS9JfbgZitVaKH8g9YpL8FDzr3RHJjYCbSrRyDozZrovu9iDLyN9ETRCqNcRnNHi98hps
8QNW8a2RHcwl7vHGEnBfN93GY/A0Vrxd18E4rb82boO8pleWM8EMo7f5FCyRFlMzwNqD/KI5
JI5ImJj0BIwSRjhTwfK5elA2A93ktmmAzzP/Kf6vwRnuGaxEg0xQDH0khOYOWOh/B3zdth5K
frBs1VYrRUCEiKJKdfBccs/SPwV1BBmVT0CsUS8oEpLKu9fqA8EyQnlirgVlkFpGnQ5GUdne
vAKe39wTXUOAsmxV84NnrPu0roOZ2TPA1RhsE22z/r/23jNMqmpb1H5XqFzVOTehyZKDJANJ
skhOIqAgWRQQFBVQQMmggghIUEBQBJEgSs4oOeccm4bOqXKt8P3w9tde3JytG/Zx33Pq/TOf
GdYYY61Zs3r0qDHnktuDYNZusRrEe7TVvwJ1ldJFuQmmssYpcihInYR3DWNBqa/O1baBPlX4
VOsLwk29hyqDdFK6IC8Afbe0UgwH70+ujd76oF4WQ/ROoP4ipwjnQB5izJE2A3Mfz0It2KQy
afSk0ZNGQ9uLbS+2vVjYX+HHCj9W+LFws9KmapuqbaoGffv27du3L4RdC7sWdg1qaDW0GhqU
31d+X/l9MHP+zPkz58MwhjEM6Fm+Z/me5aHP3D5z+8yFBiMajGgw4uF2Fcjpfrj74e6H4Vu+
5VsePz+M+mHUD6OAUYxi1B/7C46Tujjz4syLMwsjUv7+/v7+/lBHraPWUeG94u8Vf6/4v27H
X30+j0rBpqu/Oo+P+jy7le1WtltZyOiR0SOjB/wY/2P8j/Hg+9X3q+/XwuP+Ro0ZNWbUGOB7
vuf7f/0+rze93vR6U2h5p+WdlncgIikiKSIJplyZcmXKlb8u76+ulwIe/DzPjZwbOfcvyHE+
7Xza+XRhru23nb7t9G0naNKkSZMmTUCqLdWWav/3zf/jfq7jxo0bN24cfDTloykfTQHvWu9a
71qwLLMssyyDEYkjEkck/nW5/4x/9nn9q/x3f76D/M9C+O0/V12vU6dOnTp1/rqAZ5P6jy7W
F+p+X/xkzW3wzt7uN15Lg9OJV14/MxeWlP+56/IBIF6wv21qAvd+Sl+QnAYvN6z1dION0DGv
dZkPfwHft4Fu5tkgrrEdNm0Cw1e2G/ZYEAZrg3UfqF79R+dbIG4X3rZMBP0FYakcDeJxXlS2
Anu1FOkakGMsLt+E3E7pA29HQdbm1GOZ3UF9U3kpszgkjizVtIoDrKstTaI2grTJNFbqC9eq
H3hjhxM+8n1Ufe4UuPzG/ZS06WA8YCoZcgLCFib0LFYRnM2zf7r/CvjmqLP0lmAw2E6F9ADB
oW4J/AhM0Kz+YiB8xhhxJYgtpOqGuaAdFjPkHLD2DG8VdwfUfZ5n3H0hb2x2sdSDoEerpQKb
wHBaXiYXA8MvphBbMmi7eFo8B6riS889BtoCQyXrKZCHiGulEqAbtOb6VyAdlucYBgFf8I5w
FDSTnqDtAflr43KLBuIPepxyCXxl3EXzqkEg19/fOxHkedIOcy8QnpDKC3YQqomjtDsgb5Ty
bSEgv2zcYCwFerRWLTAOhJnaWO02eN/zjfYuBC1VL6taQbnmP+FvCPar1j6mvWDCdikUUE6r
jaRMsHxt2WU0QdhQa6ShBwgLA/H+BmD8znBFegcML0rNhOpgLma4KjYCqYfoJBz8VQNP6P3A
ne5d5ckH+aRuVt8HpZga5pPAHx7YHqgDhovyUYMF1G7aIJoDXYR17AB9hOpgNHBcfJNDwNO6
Q3kCbMPsUoQbtJPCc3IVkGrIV0w6eHt5x7jjQNuobApUA+NXxrKSH4Su4h6xLih+YawwH7Sf
lUZiPyBUswZmgfGWqbL0BUSttN61z4LQ+hFvmEfBm++8f/T9c3/3Mg8S5D+TglzVv5qj+p9K
QQ5w9WrVq1WvBmHXw66HXYesyVmTsyYXniZRcGrDv4v/ac81SJD/BA4dOnTo0KHHEHEmVQgL
Pwnna14bcLw6zHzum+vTW4KnpnLGfh7yZxq8ugji7tyRqY3hlZnRzersg3ZVqv/wQUfIPZuT
6uoN3tC0Tpf3QOKBp22Ne4B/gLpaWQTieD1JyQVRExYae4OQKzYQBoMwXM/SF4BWT5giLwIm
M1tZCSar0NDwJPgmSFc8GZDb9ciujcfBNWTzvFNvQOzUsU3G3QX9buW90VdB/4SnxJ0Qe61Y
6aQVULRS+JbwhnDt+cxOzoPgMwRE70egldQVIRbke8ZrFhO4T+Q+l9UVDCstT1gUkJKl89Ji
UDvTWugJhnbyGuM9UD/RRkhPAbPV1YFkCGx33c9cBP653h3+WmA5aX7FkgRCKvdMBtBO6T20
lqCH84G2HPxzAk95q4DwIYq0FoT1pBt+BGVe4GzgFpCsd/e/CPIQMV9fBf5DgfNKGIj9xJHi
cRAPi7/qN0HsZ4wyOiBkQeiZMAV4Sns2kAhska6ZB4FvgqeWrw/4U3yDXJ1Ai9ETXKfBvcKT
mvM9WMpbx9nc4FurVFUHgXpRm6jOButM22XjSJDaWOOMDjBeNoyVrCB/IntYAsa10vv6d8Bt
PlPPgbOHv6H4DkjPCwFpMLi+85cmFAz7xN3cAaG1LzJgAeNxw1nDavAX930X+B4CLf2fqFNB
ek9TlWEgHZVOiQlgm249H1IC5IXi82Jf8PX0Hvd2Atcmz2LvbFA6iIMlCfw73UVVC5i7GL41
vAzSh75+vsYQqKR+7BkAqo+BnkogzpLHmJaDIqtJwkBw2p2h7rZgOmv8wdwH1B/8M/1JYB1g
aS/vAS1MWGaeCOov6n5xBcgXrIeEEyB45dXynL97mQcJEuS/k32efZ59HjhjOWM5Y4H+FfpX
6F8BVtRdUXdFXageUz2mesyj6wkSJMjfxyM7zpZvTNVdL0JItu+FKCB5+T134FuI2hY3WBsP
pnNaauZp6OiM/rr2MWizpfWRsV64tds7OE0D6+X0r90/Q2SxSgueLAraAm0pp0FI0sfpfUEN
0RdkdwTJLh4KcwMbuChcBP2aflucC4SqP/o7gZRmXWp7Dm5XvnHkQBW4O2TCx+NWg6nHrz+m
dgethG+fdBvET72JaguQFfxyNbgj7mu7Iwtsc6ImO76AcmIVb6mOsH/mrRdTD4A/wVfT9xIE
nvUVVT4EQ2/z0PD9IOzPWZb1Cuhl/UZ/Cug/G3+1bAX66CWk90BZrqzTXwNlgxLhugD4xHwh
E/zrsnekhoLU2zDNYAHTRstP4dXB86r3tGcZWC5ZW1kPgVpa7audBVM1PpPqg7RJWi7/DLwh
XmUvaBvVD9T1oKWpLsN+EEpxU60M0svC+0ou+DV/ujYKhC7azcDHEPV8SIwtEbwXPd96voN8
MdeatRHopD7tHw56Gj9Ia8DS2LY+9A4IZaStYk/QdWWZdyn4WvvWu/uD1MzQwPg8OCrZu1hO
g1BKc8u9Qd2nvaKUBKUZFdQ54Dvvu5p3F/SPtPXadyBfNYy3tgXhhvCT6SVgPGcFP1h/tm42
AMp1bao4CKihN2EmeCN8z/i/Be2EsE/oC4Y9xpvWBuBr5uvkHQSeLe5jnruQ9byzXU41ME0w
2KTLYLgkjzIMgex9zpb+kRC+3fGR1QWOjfb9YmNQ24pdDe9B9g7nWs/3YHIJYYEICEzQLMK7
oB8W4uUrIG+URktfgOmwqbc8A/zfe/t6r4FoFCI4Av4vFV9gPShuNVI5AvYGxvflKDBfMQ8J
dYB0SpwvPwfAGNS/e5kHCfKfybrb626vu/13W/H4GLhg4IKBC2BkrZG1RtaCBtYG1gZWqPhK
xVcqvgITNk7YOGHjv9+O/2nPNUiQ/yQe2XF+sktYwyL9IOeGODkkBsJm2Fo6tkBoJVPHwHro
XrFLxFsDoVKlkn27zQZtU3R+1E4Ie+Kc9+B2sGVEp5V3gOm5sIUR98AXHvgx0A+k57Xz/lYg
TtanygtBnMtx00FQ++pz9E9AqIzF3w6MHU3vmdeDO9qpptWDU7M/vfpxEpRdeLBThh9s1Z/Y
WUaDsK8MdUNiwFq9/KDS+0DxBAQlH6yZRRsVXQvWY7bWJicUsUbdisqEsIb2E2E7wHnEFZ+3
DVwtnD+4kyEsN7pRfE8wljDPtK4CfyO1ohoC5lHmQdZI0PcKW/VZoL7gv+a3geWAobzhBVBe
kd+2lQPzE9b0QAxQRK3rnw++S77jnupg7Gp4Tv4EAv0DrZTGIPSQlsvNwPC+NExNB0Vig/It
iFN0p7AXDFXlOIsP9HipvXYU6KG38rQHIUJoL08CwyzTDOPrYBxnOGfMAm8f573sDZAq33st
pQqIvQ3PG9eBbDdUNsWAyW6aZtwK8gh5vbEr+Ed7j7oHg5gqnTD+BJLLeM8UBYYWcm8xAuSZ
XFEugqGr+S3pJtBBP2LSwDdeGeAfC5zSYqWuQDvxgv46+Jd79/sXg/iZXifvMkS3CIswyyDe
VB0MBMNU2WPaA4YNRqwDwNPP3zVghUBLtULgDsh1lBGiCIbWQm19GkhbjfHEg+JT+4krQf9E
+z6QDMIoMdHYFMJfieof3Rj8A3yT1V6gH/d3U++AKoqbpZpgXmo6YioL1nnm2ZZ40PfqS8Va
YNpiWCRtBUNNoZKUCupl5Yo/EQLH5WxKg3DL9KvlFfBYffuVomA1GU7yIsRsDH/COAjCm4X1
DC8LaiDQT6kF7P67l3iQIP+5FEkrklYk7e+24vER837M+zHvwxKWsOQfDahDHf6FlMi/yv+0
5xokyH8Sj+w4hyAnxi4G78jQ5vlpUORm8TqBTtBh3pN3BudC/IxSmTWjwL1PGCveBrGMZ6nr
DISeKd216mTghjjXsBUCki/WOx8Mu8SNpjoQKJ9f5uZeEJ+3ktgC9BQ+kvqBMJtD/neBN8U4
+T54v3S7Xbdhf/Glb329AKy9cj6KkiBhwbuGVjpk970w9UxZQL9U524EaPuVD1yfgXTQstBc
BEIrJx4rYQPzJUMFcRvIUY5ulvfA3NvS2O4Cw13LXEcuuNyuHplrwFYlvEjcMDC+ZJ4cMhhy
Ot4/dqMm8I72vFAPzIdsy+2/gFZG3eH/GDSRcUISSBYqC9tBMauLuA6Bt7T7alnQY9SBSghw
l1J6KcAsfCXdBHm9vlXIBq2Rvj/wOQheYbjmA2mmvMuSDpalxmPiy+B9wS26V4I4jPrKVhBX
y4NstUF9QRwsLQBV8493/wr+0QG7712I/qxoh1J1wLRJes84HySZo34fSPU1j/IVKA39S1yr
QRpkbK2GQyDd95G6EXzzPKN9RlCbih+JoRBSxYH1S9DPs4DV4E51v+JNBbW6VsdbAmzPmH6Q
7kBYmuP1kJKgeLQ3fbdBHqDXM9QA6biQIQTAetO0UJ8P3ud8y0UPpM/O3errDpYGxqXau2Du
INo5A16LP917DvRofZfQE8yrDNHGt4Es8aw4AvTramXjB5B5OL172lygiGwyTgPlGaGt9CSE
pTmiTB9AuNdWJnI3eAJ+o/cg5B53x6u3QKwizPUsAflJ8buQX8EzxHPM1wxMfS0D5GuglBOW
iKch60BGIGc3hG0PibDdB/MGcbPmgxIniwthJrCvdaxzxIEr1lXNeweAjn/3Ig8SJEiQIEGC
PB4e2XG+28jZz9gGwjPj+6gtwZeS/sHNF8HzQs6hzLGQf1wo4ekEptVSbUtvUK7ymf4JSPl6
C2YAE9R6/skgLhW7G4eDqiv7s2qAPlj9Qf8KhE9Nb4fFgf4iBmUaMF67qJ0A01RjWfNaONTh
4NLD2XDstZPdM3dAz4xec19+HkJmPpdd0wTpK/p8PKw5uBRnkcwOkJO/ocLy18Fhfvbei6+A
6WKJ7XHrIKdudiNXEbhTLreXJR5iv4m7Eb0I0lvl1fNOBneXfOutneB+1eVz1QL7IEeP0Dtg
nWy6aZsJekagg6snqCGBXfp9MESZjI4nQfcKoeJc0NcSp88B9WmlqP8KGHoYx8nHweC0Do4Y
AnqS9rGYAlzT5imXQPMHVrt2QGCI75TnMsg/GWqKI8GX5b3mHgT6eF+8YAP/JsqbfgDr69bD
oUXB3sNWWnwHtIBnv7MyWFLtZ7UN4JquyOa24Jrq7eY+B4Yq8mzPBtBDAzGeWJAGS121J8Hu
MA81twGmSZmWjZB7QdjnqwYOUV5smgD+EYEBfABer7ur9yq4BufvSd8FkTsiY60/gLmxIVP8
ADJj8tY550Numex5+T4I+yT0TXskqKLwntgA1LVEi6+AwZK3XekKajN/4/zrYHrSetswEnKr
536g3gF/x8AoX01gttiR/SCfkJcb3gXlXP6YvGEgzzBUNMwDPtGW6t3B+LR1pWU/+Kr4I70J
YHqbpEBHEF8OHNdCQW6u1/LNg5B+xhVyBkhXLR2MAyFgUI4ZPgCtjvC8WhUMftsacRsElqi9
9XrgbanEeyqCOcWYIg4Cb7f8mJxfofTqpKN2CZ5IrzSq2PeQF5XdVjwG+n3h9RDP3728gwQJ
EiRIkCCPk0d2nCtdrdy02BlIHnv2jLslNP7haU+PFRD/UU1z3WXAMFMZqw5aNWULJ0D4TvhS
3AhsE7IMc0A3qJn+l0CYLJYRM0F/x2nIygPDaL259QgwU/xKbA3+484S+RVAGCfMVYuA1iLQ
j41w+/KdcfJAaGR4qVn9NIhq+1SpCingqnF/UsqrIAg5O/P2Q9jJIidLxIMpv8SLlY5C5pOz
uixpD/HS6A79r0NOJac18DIYv7JGxUyDMpNL7i4ZBjdb3o/Kqwy5M3IT7BPBfTQvkP4lWL52
2IpXAkvtkBHhAhgGcDuvGYSscHSUZXD+7Dns9oOjvO12SAWghrBfKgLy7vBq4Z+C/44Qbfwc
1G3Kl75I8FbK2Z0xFPRqeh/lZSBevCIJIO2UxguNQNwqRImhII4xi6bBYK5gu25fB6FFjRZL
GljfsqwxFwF/vvMt50RQ5/m3euZDxpP5x7Q4cNb1z9G2gH5EihOrgeNs6GfmKiDvFt/XboBh
h1RU7wTspLbfBK6y+QuVjqC21FfoV0BTBYNxG2hdNVXbBaZm8nYxHUoYS5dMuA9yS/2MNhKu
dknR87uBhGGoHAf+s1orrSz4L+nv0B/CXwr9NSwMsjbkNHAXhwxP7tH8bLCcNY/XvgTlkrOd
Ug90G0Y9BuRjxnHyLNCzSMME6o/qDHU8GPeZDptCQZupCUp9MPQ2TTTGg9JetWjPQCBN+0H/
GawvW7NNdyGwUz0mTIKMw1ktMvaAfbT9bcdFMB41DDZ+AFKU3Nd8ETyiu6frDqDoDmUWqJv0
28I6QHVXcCVDIEzyi/fAXMV/JXcZVLIUN0UFIPK+ZakjGXJGpg7wX4XQ9tF2Rzb8t76eLkiQ
IEGCBAnyb+XRT9UY5X3m9jWofqnEhLJFoRJNol+sAJpijRTbgb9VZsfs+iB+bd5gigJR4QMl
GdS5wgDFBsZa5hz7S6AuF5/Rh4LaOneluzQEauv37H3A8kJ8iL4B8jvkbfAVgVAt7GLYTPA0
9v/orwvPnGj4XhkzxHdIVMObgE/JM6R1BVXN7ZzTBIwJLp1cEJvHlDLPBsMn4SExzwPXbePD
yoP/ZO793HIQNTF2etyLELPV/olaGqTkmMGWSLAfDTkurANjtbAxMangvJRe5GYH8BTztI7f
CGazZXX4MhDtrte8DggrZ9xlXgC2scIPSgOQrWp6qgjCOeGcVA20tzxT898H9Wt1u2QBcbE2
SWoJvnvCHLUlKMe06vp00L/yr/JFg9zM0tL2Cwg1tSTFDbpbeca1HdQing3SZhDjhYnG7cAR
oZR3PuhFtSzXryDUNeywjQN1rfqDfyCEqpZ6cjGwnrNet7UH63nDUr0eWF+Xp4ZEgDoyMMT3
PARO+yeoP4O9VsghYQlEOExzDa9BXg9/P3E6+J/zNPSvgqQSMYtNEihxykLpMuSud5X0HoIi
UTFvW8PA/bJ7cqAMZBXXegtdQL3tS/P0AGWlMy/jOhT9ytpfbQDO9bbdIXsg3Zj3ZaATaMlK
FWcfcNSwiMblYKhlKGtMAPaTwgjQftSjhVIQULRY/QQEPlAyxQMgzBQOimfBdtjSRi4F0QND
h1hkMGvmRHs6KOsCycIQ0HWu+AB9kOrWPODP8u7yJoGw37BZSYH8kc6ovCEgeHW39g746mg/
qwoINdWGykLwnPb3VD+DktfjT5hGQ9joxGdKJEJA93QSy4DxNVsfy7NgaxHxQ8iFv3t5BwkS
JEiQIEEeJ+KjCpBu6g3yRHj6bHOtgwJcsc0zfAl5oal97rSBvRN+7LEiHFw775xJXgPu4ZnZ
2W+DUj4/Nv8lSK91cv+RFaA+7f7CmQq5lXJeVQH1KcvZ0O9AOeLfpVhBua9eteSBsFS+LkgQ
usUuGbdDXEZsy5DXwVfPVcb1PoinHHNiMkAv4TykrQFxQmblzJ9B/MYw3OoFaV5In9AjIDxn
O2erBPouaa8hEoRc/yfOtlDKXDyj2G4IuxfxtVYHHNusqi8fQi2hnWJCQZKNueah4J6aNTVl
NKixUhXTBPAcEobY3oPz85I/zh4NeUN9EVptMP0UujfxOthNtvkRbSG7Y/5wL+D7yjUjfy9k
t8xKT2kF7rfdt3OXgHraP9h1CszvmwJSQ7AWNbaiPZiqmqyWQaBe1o+L40G5GHjJVQGyL+WW
Sb4O+U7XQucQyLibE68OhJR2mV3yykPkopAo2xSwlDW9b9gL+mntSc9FEE7oL4sOcCywaObX
IWSnY2jYBDBEm5+0DAExWqrhWA85pfJmi6vA2SvX6psMyin/QtcB8PXwvO17D3wv+Vc6I8C6
RcrWFIj9JORZyzxQflDX6mHgnOJ7yz0J3OFqG+0w2HTjq3pF0NJ4TrKDOFoNVyPAUE5oK86D
qNdCDeHZIM8yrbe2A2uK9RPrNpCeZbg8HPRFwtMEwPSqqMpDwFTS8Jo0D4SOUiJh4M8NXFe/
BP913zdaZdDK+fFJYBoqx7MeTC3F9w2fgXGp9IZcEoQWwlTjNXBdy3vN3wxcWZ4mzm3gy6G5
7gcp1LjRWAXENpZSlm8g7GZIP/tOKHm0ZFrRkqD1lDNCN0DahLxN3hkQ90pit0g3mM5ofcWi
f/fyDhIkSJAgQYI8Th454lzMZW3Z4DVIqF9CrWWEPFPmytQEuFzpeM3DcyHjevRycTD8NH3v
ubVPQ1KuKbnYYqg3p1tYZwHYbRhrsAONXPuywyGwJWd9+gYwOZ9YVqkqZLdLTTy8B6RW+jOW
82DYa3qn2gzwNwpsUhSgn3pFnwzySSHH8AUIVYX+0kVQjqUsSr8FSh/pJ0sqmOMjy8TYQSgf
dyrBAMavw1JD2oBwVauq1wZDsu0ZUzPInm+re2ESZMzOrXtsMzzxyxPXI1rD/QP5vf2DwPFM
1NfF8iCr9N3lV+uDd4uze/5zYH7BZg5zgTDfn+9+C3K7+crqP4A2JM3p2gghXxjbaypEvB8z
PHor6PO0EK0CmCc6G+aPhcgVoXPCaoN+AoP4Brg+99/03If8o+7W/k/BY/CU9tYEIVXqb24F
2h36CyKItfQ26kBwCd5v8o0gtKEqCyG+Z+RcxzgIDTW9JjQA11DvIm0bCO+JPYXdYNlubCdd
B1/JQCu9L+ScyM7L6g/+kspF5oDnUyXe+R3od7Q3fdPB/plxhtIBAhd9vkBx8Mzwz2IgxNUL
Gx59Am72zVie+QZk93TN056EwNd6cfELsEw3jQ5UBnuq8XW5DDBM3aZ8BIwwdpGqQP4Kb0XG
QG4D9xyvHYzLpEjpR4j7Nqy6eTyIyeJOqR4oU8ydTCYwVvbv9rcC7aCwgTdBHKIkCyVBz1aq
6ePB5DKJFAdfa+8U3ySQlgkTxRTI6Z4XcG2FQBV1gl4XAjHaKuU7MGwwHbVawXvGl+Y6BqGv
hB4OXwjKZcWvfQ7KGH2TAohr9emGn6FYdNgp8ShUulrGkNQVLB8aytiGgdRD3mxvDhFJEZnh
Chxf/mvvS02hGk9vZ//fvcyDBAkSJEiQII+DR444Pzmh8dyOr4Pfo3ZWFoF0wmCyyMCIiPny
Jshp7/4mrzZkjJEnu8pASFjiQr0SBBplfHwtHYzvRpaPHAnM8BzLHAJRL8QWc9wAqY55knEo
RFaKrvHEBYhaFfdcqb6gnFR+0IeCEMVGvRaI3+vnWA36VcHLl6DtBD0D9M/UskIIsM7WyLEJ
dJtvifYqGAYYLIZNIJmTFoQtBjbqk8V14Bfdd92zoMz2InFRn0H+ND1FDwX3xKwZGV9AsdCI
7WIlMGxyTI5qDuYajoiw6+Abn90krQIICdpHxilgXmCbb2sBniu+zsJPkDdabys7IMcjRJun
gedzZazQB7StWntpLBi2m7fbPKC9qY1Q08B1ynXT1Q2ks2qmfyckvBgebQ+FYskxV8LfB2NA
W+TTQAqoRwPp4KhmXmD7GswbjUsNbcEy03BY2gXme/JhQ3e40TItO/Mo+G36QPUrsHW2TnaU
Avc4V0tvGNx9NSMxcynkVHCdzfsE3C94q2dPAc9Md1R6HVC+C/Rx5oPrpqexFgZStHRSWwjF
non+JioNzoXfeDk9ApKbZId4+0J2D9dgz1wQ5uqKuh5CTVJ9cTXEzLXVF9uBsNbYUCoFWRZn
TSkf/N8EflDfg+jIsJaWdWBbZD5gsAAB/TVtA6SfzZLy6kP29Nx3XTbw1vRYPZ+Bd1u+L/87
cG9ytcjtBNKLzPJ+BKrBmyGeAj1bby+3geyzzkW+VpA5xlnM0wrSruXUz8mF7JHO0e5lkH04
t3lOBzCeMXqYA8ay4mZhF4SssD1t/BTCFtnDbVvAEDDkMA0S9xVPidoO8bfiusdFQOhaU7jt
HhS9XPpCmfkQqO0eqpngmve4+WLDv3t5BwkSJEiQIEEeJ48ccXaciApLqAnaG/pSEkDUjRGG
k5D+es4P2S+AS7tjuW+DmsPK36l2Eyp9XXVpo1GgHDfNle+CVF87pFtAreXNc/0AHBA60RxY
qS53lQbtfv7PnudBLBfROuEuSJMDq5TroP0irmIrUFJ8BR38s9RmvlfBNMLfz38L1DbKMelL
0HNN+fZhIGxw95MnAPdB2g7G1Ym1YisA3yvJgc/A3zqjwd2ikNfP0TktC8o1r2F8si6cPXLu
wAIf1G1b5avyL4O9k74oZjn8usK7oWhvyDl8d9DF0uAZlvd66gqwtAl/NeIwSIMCb/lmgZao
DNDGgjbGeDm6CuQ9qT+jfg/Ku74GrhZguK5+p+0H10ueQ+4yYOtkXeQ4DiFzhcbSIbB+bGhn
+BmkHczVDkDSofgZkYPAddQnKEvAMyl/WU4zKDIp9lh0BDgreEPVWiDWkT+WLVDkefvnxW6B
aNDxquCZ6r7sXAbO+57U3C3gPepZ5vGCeavphCkUmCnsNX0C9ovW9SE2sAyUQ4U3wTJHqqZ8
CaZxxk+tRrg65e4153RwLdByfP3Bssvwtuk6RG8KqWBaBCnjU4feC4PoBY7e1hfB3tzWNrQa
nAvcGX//OTB9aIqyDwPHC4bp5nIgG5QE1wDQumhp4h5INuWOUJqDnqyu898ErSovGDtDTiN1
SCAFNNHbSVkF2vPKBdcWcE6Rv9UzQLQL1fUeEB6Irhn3LgQmKPXJAjlcvK+eB0ea5VPxFOi5
+kA9EYzr5V3aUxBy22yhCKh7Ard8PcC83b4n3AT6Sv8WvSOE/RRb0h4NURdK7yu3FjzZmm7q
A9Hp8SVjmkG4MWFtdAociV8z6Fcb3Fh7/9U7IUCnv2dh5+Tk5OTkwJIlS5YsWVLY3qtXr169
ekFYWFhYWNjfY1uQIEGCBAny/yqP7Djrl4VEfRGoNled/NGQpdyffiUGSkxRbZZKUG5CVfnZ
vpBYpOqmp58F7YeYZollQbzhv+FLAPGqHiIsBOf7t1qdGgzW9FhvlfKgO90D898APnL3z64N
3Iv4NqEq6JfERnom6M8I95BB2qenCStBr0VS4CR4P/aFu3pDoOb1FclbQVuo9aU75PSV7Xkv
gePUnZUXp4F307Eex6qC5ckndpY4B+bK1bTSB0G/760dMgGefKvIZxYP+IY12Xj7GlQsX+H9
1pHQfFbdgd5akHpq6pPfdYJTX7qHxXnA/WnmlbsnQG5oSXe8BabJ5mNhv4DvTv7P2ZvAPTHn
SPbHYPCZ7MZWIBQX5gk9wH1YT5I/BctzRldYefB+oy5hL+S0kJaIzcEXGdhGT4je6HjBJoDJ
ZC5v+wDy2zhz3XchEGGeaGoKoQutT1tPQuwz4R3kNPA28U3Wx4CTvPzcKyD1Em7qH4I0217S
MAZs182tQz8B72hfI0t/oIPyaaAqiNEG3XgNsju7tynfQ2ChXxAmATvl4WIlOPvJzcS0dAhc
keO0WeAwmjaaygCzlDoZ5eBu+/TRYnewP2n52uQB0sQ0jwAZpqyfzF9C2K9hU6KHQpwxPMU6
AnLlnBp598Hv8pfXX4KMUbl3nJ+Bb616Qr0MUStCfjE3BpNo+kB/A2xvBgaIByFD46i8D+Q4
SQ2/BNF7Q46bYsFUVl6sZoG/lb+uuAM8z7FNLQdSN6Ng0EHarB21VAe9st4w8COoG7TO+kzI
X+qurDpAetW027gI8ro693lHgOOEeZNhJSSsTTgWsx2E8uIB61JQW6vV5ItgPxK7Ne4SBMa4
FrvegYO+A+5jJjhZ/WaTG/rft7AbNmzYsGHDQge6gAJH+uTJkydPnvz77AsSJEiQ/yk4nS6X
zwfTpy9a9OuvcPnyzZvZ2f8+fWXLJiWFh8Pbb/ft+8wzYLfbbCbT7+3x+QIBmDJl9+4LF+Dy
5awsr/ffaU9EhNkM777bsGH58mC3m0wGQ2G/16tpmgZ79mRm5uVBbq6iKMq/z57QUFmWZWjQ
IDIyJATMZlEUHzm/opBHP1Vjm2uDaw14892XchaDrVbYqtihULRJq6J1KoI2mXP6YQiUVd5W
U0Gf51W9t4C+YpjeGlRj4C2XEczh4a9G1gK5ZtGF5SuCNN1eL6QR6NtskeFjQNNUu/AO6D2E
72kJwlzOCzGgVaAr34NpreBwTAe1ns0Wvh7CN9eullAbTh2528jrh+O1Yz6/dAm6jpayboXD
/U3l9bsfQ8LVEu8UCwfb26Ze8a+CVMY8O+wTkNBb+z+Cpm808Y+qCPpnejZ9QHgv4QhvQ8ea
zeIutoObA9e0Pv0N5ES4DuaUB+cHWY3uZUKYGFu26AdgKmOLDFkMnh75x7N3QWCmp5l2CITW
4j52gPCrYZZoB/FWYILla1BC5SrGj8G9zdxXjgdppe8zTw/w5akv8w3kL3S1zf0YzKdUR95z
kD0k4879H4F55q/D+wMzA62UDSCOkBepU8C80rLKtB6EYXSQT4CeHwj1noaQnqY7Ul3QjJLD
1hKUdDHDHA/uKPcYpRq4OngMnmeAVdogbx8QnxeOWLdAWG7ELbsBXE/kbc9xgOe++6vcjRBv
ijZEvQuZuRnVrvSAkE5hi5OqQeiXjtGx70D2XV9X/znw5+S8pZ6FjLe9WSkzwLzV8pXpa8g6
kf+r9zZ42ntjfUlQJCt+TsQZMOw31LTOBl5SO3qjIfxE6LPmRqCO9zfP6w+pMa5wV2fI1IRv
5AGgf0ya9jFoPSlFEzB9a3AZE0E9KDynH4HAz9rH2lzwjQ/M1n4B5UnldU93kCppnwk1QR9C
K48IjjXWJPkklKhYzFlGg4h+URcja4HhY/8rWjqE/xTtjN4JptviEjEUDhxcu/rYMvjl9EXn
5U8gLV4xaFf+fV8MD2P37t27d++GU6dOnTp1Cm7cuHHjxo3C/hIlSpQoUaJwXIGDHSRIkCBB
/jWmTJk/f88eyMzMywsEoEyZUqWiokAQBEEQHp8eXdd1XYe0tIwMp7NQ74QJw4c3a1Y4bsKE
bdvOngWPR9MEAZ5+ulixiIjf7Hmc9/2bNXDjRmam01mod8qUF16oXr1w3I4dGRk5OWC1SpIk
QbVqoaF2Ozxea0D/P8Gqu3c9Hp+vUG+rVjExERGPT88jO87ucs7i2U+B8YJxgXkOSLkhE8L3
gcfpbeMpBkIx7baQCuoKeSvjQHhCbKGPBimOEMNG0Lep77hfAuPzxb+veA6MR2zbHddArc1P
XAdiGCQWBYNJ7+l/CgLPCj42Agf1xmIu6F7hsH4HaE0dNQzEm/49hmJgLd/wjVpvQP7ZrKQt
2ZBTJnmXvwPkNWWXezeo00odVTRFnAAAPFJJREFUKVoVfm17+dzeDGi2N+RkuZfAG5Z21HwU
7n9y25KpgLGuYUnWcMjukrL4/gnIXnR/wJUUONX31ovJUWD9wNEo5Bdwv8BX5dqDd+jNA8c2
Qf7I7L3prSHkVmREzCYw1reY/XUg4PQVz30ZpH5ie2Eo2HtaI0JaAdMNFuMwMD4nJ4sTITRX
XKCdA0MJ423HIbh7I2+CHgu+jq7vfC9B1il9gCEPlHrGnCgdiswNKWn8GDLHZS12DwdpAbf0
HMhzuX/WLeArpdb3mUEuIS8R0sFbXiulPQdyCzEk9024p+Wcc+0BSTTWcFQEYy2Dz9gQTJMM
lRwvgvU4N7z7wHff80VWKqgnmaZbwTTEvE0LAeW4+p5WBYo8F1up7FQIrxcRazsDnhddF+S5
kJeSfdHTAVw9tHH+TuCoYT9nOQ7exoFkrQx4e6pb6QCxb8QsjDoN1rnW1pYicNdxb3y2GwKD
Av09x4Cj+qzACsgxeNf6XSB8Ib9ibQiBxdpt6oJ5tmW+8RswHpCzpeOgjNbCxY6gGAP3vcXA
NsMwXFgNli9lh1wa5B+lFeFXIHej/3SgE9gnGzeL7aDc0KL1YlOhWP9iU4vdB8NK4a70JsRG
RA4NvwZR4ZFfRnWBS2/+mnT5e1jXZlOp3aGQfNdX1pULckdxm/2t/7NItj7eL4f/imrVqlWr
Vq2wPnPmzJkzZ/7zcUGCBAkS5F/j3LkrV7KyID4+MTEsDG7evHcvL+/fp89ut1gMhkK9D3Lm
TEpKbi6ULh0XFxYGBw7cvp2R8e+zJy7OZjObC/U+SHq6368oULKk3W4wwIULHo/n3/iCsPBw
SZJlSE//zYF+3Dyy45zyxlXj9VfAZ029kzUBqt3ovLZjBvgjfGUDr4B+UjbzHUhntRMcBaG5
MEBYAHqCeIp3QL+on/M1ArGkGCV/DtrPwh05Ebiq9Qk0AeElYZHghsAk4XVxCogXtbtiAyBW
OKnoIAzT94tHQAvBIVuBr4SvAmVALe9+WfkayoxIeKPKp3BL9Xr2fgQZ4fKB/J2QaNKuOtpD
ygvqt/LnkFXzfq97u+FTx9vXP10KN01phsAHEDnGNDlvJugHldnOkZAZ41rkeRU8X9jXF68O
8d2L/pSUAMwNeT50M6Tfjcotdgi8B9I7JceC94zxOfMecISEvh1yG4RbfKEngTlbXBCQICxg
0NWroL+nXnU6IbSz8WWxFJh3SWGBKLjaKvnlnJPga6/lWeuBup9+kgv0jtTUhoH8k9BZPwup
qbkh/t1ga+wob24D8iC5qqU/eGt4Mj3vQ2im3FuVQAzwinAdjGXlLrbTYA4zh5tjwDjPvsWT
AUIRWnIDxG1CsvAEqEW1DwPfg22ZnC5dA/PLxlJR08H7tK9jblUQ2tLCeBh8OYEnlDng2+58
Nj8HAk1Na61ucBndM3Ingr5AeFv5CIp7w3sJNcDoEiKl8ZBt9izQ7kFMl9AdlnwIPWlK105A
TlL+4vwe4Fa1z3U3EEe64VPQsulNUzBftFW25oDlFcPThqOgNtWPqF1BjVG3CZ1B7aMfEW+A
vFbSA7XB1NdcX/ZD+PrQWY4O4F3uTZIvg/tjXy1fJbAdMdiliVB8c+zZ0PMQayy2vPiboBcV
PrYEwH5Q7Go8BUkflLIktgRXIPumexpsfuHnDftuwJ0uubdu1AFLcT7xxoEyS0eIAp799305
/CMKcpcXL168ePFi6N27d+/evQv7C9qDOc5BggQJ8nhQFE1TVcjN/S1l49HlBQJeL3i9Ltfv
U+3s9rCwuLhCPQV6H8Tv9/sDAbh9OyfH6SxsT009derAgcJ6bGzVqk899ej2Fugp0PvH+1FV
XYeMDEX5R/07dmzZcvQo7Nt34MCNG1Cv3lNPlSgBjRs3b16z5l+3p0BPgd7HzSNnfWT71UYZ
4yEjQNu8NiB/JyjSdRC66ru0aKAEqzgGwkRhlbAFSNf3CodB+FhYJlQHf5GrIb+YQNmZnZez
G8QbcrIcAC1S6Ca+CfpWPEIZEG4Ln9MDGCVU1a4BHRgiVARdpJJeDYSxQnOhGIjLiWYa+BTh
XX0dFB1f+ouGF6FpYq3pHVuC/VlzufiacHlzhny+DJjNlpOh2bAv+eDTB8rDzYsW8523wW+1
1vTsAHuLsl+UPgXVqr3w/vM5UKpRtTJ1B8HQ0v1rdekC9RwV9JiPIPZ9VuXNBeuCmKZFVoDs
D/spsj149uY8l1oK3D3dzb3vg7GxvXpIe9AydVE+Bp6enpmeSWB8Ur4TyAcv3k/dP8L5+Buv
3/8Oki3p32XcAm+2Z5SrFEj3jBbjz2D2WV+1dQFOCV6pL0jnDB7jXlD6axmG3ZDXz1XFawXT
YvMLxkUQZgmpbf0aoiqGVA9pBubjYoRyCBgU8Dl7Q8gd81mehvivIj4NS4aYGza/vS4kfmzr
7lgKRkFsZs8B/xZlpj8M8r/NfTY/EVIO3f8ieQqoDrVXYAbkhyhh3pfh+tHMSScXgVxPuOWd
CezSL+WeBvev/mX+UnDvSOaNTCsYPpci/TvB/oS1hPQWpBgzijvngXOS57Z/B/gqeqt5vwfP
bN/mgBOU+6wSFoBUis90GYwxxp3yWLCXt0ebmoOtnHml7QOQaxgzRRECnfS9YiZkfpyXpd2B
K3Nu9kpPgIyN2UmZV0DZoXzv+Qmiv4560boM4vcUfybhOojfyUNMLcG7w19Z+xAcDeOej+0M
eeOcacKrsOXe5iNHouDwL1e+utAJ0vfm7UnrAM66WZ3utwb/CM+0+z88/gX7ZynYBPhn2x+V
mjVr1qxZ85+XXXZ02dFlx9/3XB43HSd1nNRxUuH9Pey5FIz7T2GFY4VjhePPz1tBeXnE5RGX
R/zd1hcyKXNS5qRMmN9/fv/5/f/69fnd8rvld4OnjE8ZnzIW3uedlnda3mn5d9/df+7nJ8j/
jaoqiqqCqqqqpv3rpc/n9brdMGnSkCGNG8P69fPmDRhQWP7xut/0Pojf7/P5/eD3BwKKUlju
3//xx2+/XVg+2P/o5W96HyQQ0DQATfvNjX2wPHDg1KnMTDCbIyMTEwvrDxv/Z8sCvY+bR444
y3VKW2OmgTkjfGX4LNB38CRjQG9MN14DYacW608A9Vv9tv4WCG3FtwyrQXxOKC0lgnhQ6G5Y
DtJOe0zMUlDf1X8gHkQPTyrlQWjKc5IZ9AP6GBqC3gAjvYBoBKE5CF2Ep/Q3gLZ6bf006Bms
FnuA+JOoWQ6AclAuFpgFRbWieoNbIK6WkS5DZqY46vItuO5MTbv+I1xMv37GUxvKrWyc8swL
cPaTHzud6A9hA4t3cKRA+egySytthhePdbvRqyJYt9qKmZ6HXZ13lv6uGDTeE3M7fwyEnDie
q22EsxX9b5S6A1kfaYeVieBblFEkZQEYe0vTi5YFeYT9yfAo8H3in5H3EeT48lbkzQB32cAM
oSNkH/Te1bPAdMzwqaEJGL4V1gUqgNhDOeoWIBDmdcnJYJ5i+cn0PASm+V/xWSHnUN5L2efA
VsQyxzIGlGc0i+UMOC95i0gfgbGUXNx4EvxGfY52BJTzgaGey2CbZJhl2waedvmrA1PA/5Wv
ddY1cH2o3LxshNRTafszVoD0s9yYS2BYJky1jAbveq8odQZ9lRRtDgO+FKvkB8Dl93fOOgli
Labbf4G8cvnD8qLh7P0b77uSoOTB+FFRKsScse53JELKc2lP5e8Hb1ey/GPBUotR8howl5FT
yYawb0IrmxeB8I0wz3QMlL3iRWkpyHsN66X3QY0L3BV/htzw/HeyM4GaREltwDrYesxaEWLm
hrTXW4Ca6+9pWgWG9uYuxiegyJTwtWF7IeJmMSluAcibLHUc10Ct6R3MSIj+Kt4SeR5k1dY7
TIcDL/3yy6XqsDfxaOtTL0J6AzYEfgLtC+PMKBm8T9Pt7qcgtJeaShWBe/+OZftwCnKW9+zZ
s2fPnj/2F+TcNWjQoEGDBoW5zo+LyGaRzSKbweuvv/7666//sd9x2XHZcfm/95n8nYz9ceyP
Y38Eu91ut9v/bmsKqVu3bt26dWHs0rFLxy4tbB/fZnyb8W0ePo9x38R9E/fN3219IWuar2m+
pjkU71C8Q/EOMIABDPgL12/fvn379u0QqBKoEqhS2L6l45aOWzpCX/rS9+++ySD/8ShKgSNb
4LL9a0yZ8uabTZtCqVLFikVF/bH/QfkFeh/E7/d4AgHw+63W/2oTnt//WwqFong8Lldhuyxb
LDYb6LqqKgoEAi5Xfv5v7VYriKLB8PvNiA/qfZBA4LfNgapamIf8e2TZYnE4/lh/2Pg/S4He
x80jO85Z1rsJyb0gbnj41jIfgfCpGq9nAYN5HQvg03OlCyCuE58TZgMBPpViQPtca6H1AalF
0eFlF4N4wDo4ei8IEepg317Q1us35NPASHE0i0Gw6Ov1YaCnEIoZhBK4qAnU1D8WDKBfoYRu
A+7pRv0H0JtzTusLUge5jpQAyjPq58ovIN03TLHuhCd2x5Zq0B0icvWfQ05CVKDEYfN2WH16
cdbmOCjVruLpCBdUz612yNQQkkPuxp6rBAn10o5p2yHyTXtpewcoUy1sheVNENpqLRJegJSF
csqlT+Fegn1D6HOg1yKs7PfgXHrvm3My5Nkzf072Qfi0yEWJ60GfaZ3p8EJOlUA3rTqoI72O
tJNgaCEPFb+DmLURxaNeBEMHUtSxkLo/q8GdChBaI7RCxLOgFfWdlA5CaFSIHjYT7Dsst6Ud
4PzF/Yt7OPhbeo/k7wHhsqGTMRZI13v67oMrx3PHMw0so00vyftAHaZM8LrAfceb7yoC3rxA
i0wPaJuMO3w9QF5vaGWfCu5h7qdzngUx1zxHagPWxeY9nAS5gfCefhpE9DG2pyAuPDq6yhHI
n+R6PucqFLkT2Tj2OkhficvS+0LC5tCokImQVS5ziWcl3P0qk5yfodQr8U/aN0EgVsgP1AJx
gnmGZQIoc+jCJ2CPZ4riBdMy8ZR+EQxOsZ1cFTJ35TXN+AaiE+zxhikQdzHqvZifwPyO+Wv5
GKQ8k9ndXR5ujk1tfm8olH2p9LIi58Cxqci70SXBsNDYxXYSPO3zrwV6QVS9mKSYvRCyLGZO
VEO48c65Vnd9cPiNExknq8H9i3pV/QioI+TPoq4B0/3RKQfBONc6Xb4JpraWpPgXH/+C/WcU
RJQLHOjx48ePHz++sH/s2LFjx46FpKSkpKSkx6+/wEFsndA6oXXCPxiQQAIJoM3T5mnz4Ms6
X9b5sg6sW7du3bp1kJGRkZGRAVFRUVFRUdCuXbt27dpBn0N9DvU5BOIgcZA4qDASV+Aw/TDq
h1E/jCqMzN1ac2vNrTVw9OjRo0ePFqovuC4uLi4uLg4syyzLLMvAWc5ZzlkOhl8cfnH4RWga
0TSiaQQoVZQqShWYljstd1oubCy6sejGolC6dOnSpUuDp72nvac9sIY1rPnj7RbkmBdNK5pW
NA0aLWm0pNGSx2dHda26Vl2D2y1ut7jdAu7+ePfHuz/+8b4fpMS2EttKbIMSlKDE79rHM57x
/9U8vs3bvF1of7GJxSYWmwh1vqzzZZ0vIatTVqesTrBj2o5pO6b9+fm5turaqmurYGqpqaWm
loKzZ8+ePXu2UG25l8q9VO4lGHpu6Lmh52D2/tn7Z//uxUIF8oalDUsblvbw3P4H2Zi2MW1j
GpT7tNyn5T4F4xLjEuOS3znONfrW6FsDOM5xjj/65+gz32e+z3ywKX1T+qZ0cDqdTqcTanxR
44saX8D4cePHjR8HUbejbkfdLtTn2+/b79sPXad1ndZ1GuTNyJuRNwOGnB1ydshZaBnTMqZl
zONbVw+b16ldpnaZ2uXxf2/8v46i/OZgKsqjOWqlS//fDnP79sOHr179z/U+iN/v8xVEgn8f
ka5ceeDACRMK6xERFSrUqgVxcV7v73Ogb9zIzs7MBIPB7c7JgZo1y5QpWhQuXrxz58YNyMuz
WqOiwGh0OMLD/6j3QQKB3xz+h/1bIctms9n8x/apU6dM2bDh4fdfp07NmkWKQP36jRv/fjPi
g3ofN4+cqmHI94cGbkN4VdPSkJEQSKKy8Abo9YUPhWdBWCauMGwAnhK8UiawQtiNCeipzHKP
A21obou0MUAF7bZ4GmjNO8IyEBqL/XQ3INNMnw2IZBENGAQzEpBKPrdAf54OejII1YSqugP4
jueVb0EXtCF+CfTeTDf2AGmeECo1B7W3cs5zEsKTHNbyV6F8lZJjW00H7235e0NjMItlWtv6
Qg/HixPaNANHE8/IiP7gv3t/aO5+cArnDqUmQ8hcw+2wnVB8aWQgrivoA+V+UhEIHVZ0hakv
RA63Vc6zQ+Ro+5dSMpgHxu0stw2M+w3jLSvA3SDLcVcCtb3ngs8JIdNDng1tCo6WMaeLXIDY
WlHXY1IhNi4qJnoCRHpDQ6N1KN23aHjpsxDxk+1MyF6I2ufoaagIph36cPenIDX2vp21CZJS
IgfIeyC0m6GMMhVsNulz70YwrKG8MxGsXxlLmRuCt7/HHkiC7G8z1bTPwbPfvcOnAWYtwfEN
mOK0o5U1CDtp6lsyBKyNDDctfYG7qt28EBx7THuL50N2M1cgfRj4X9SnURSyGqV2cylgeFt/
NaQJuFd6k/MbQ6nUmKPF54HtAzktfC+4mvlme49C7PKIROsNsO82LTLtgPhyEe3C4yCxQVhR
6+fgbZ5/NmAHxwaLKo4CYwv9EyUJMirff/V2X/D/6N+cOgByEz3LMjrBlZVp5U/1gIsJd8KT
l0Lugbyz7uJQ4ViFs0USoESn0kKJ78B0wNQrVAFXMfdO7XuwHnNUCmsKYcS8F5UL967f+jar
FBx98lj2qdtwo2T+Pvdh8NbXPWJf8Iz1bMh9HZyfO++mJYIhy3Ivahm4p+gbzV88voVacHzc
uHHjxo0b9/BxBY7zw8YVONI3b968efPmw+UUXP9Xj60rcGAe9lP/pqKbim4qCssuLLuw7ELh
T+xld5fdXXY3TM+dnjs9t7Be0P/N8G+GfzP88T3P1I9SP0r9CDpN7jS502TI2ZGzI2cHTN81
fdf0XYXjlj679Nmlz8Ka6DXRa6Kh2Y1mN5rdKPxpP+2jtI/SPnq4ntyduTtzd0J+2fyy+WX/
dTuWLV+2fNnyQjuaj2o+qvkoKDuj7IyyMwod5v9ukpOTk5OTCx33Z4c+O/TZoX9dzuStk7dO
3grHBxwfcHwATNg4YeOEjTC189TOUztDcmxybHJsYUR84oSJEyb+zgGI3xC/IX4DvNfsvWbv
Nfvn+u4n3E+4nwAnap2odaJWoYPbNLxpeNNwuNH0RtMbTeHq1atXr159uJw/O39fGb4yfGWA
bx3fOr51QCNHI0cjB0wqPqn4pOJw8eLFixcvwqxKsyrNqvRwPe0+avdRu4/+i8/JY1pXj2te
/7fwr6Zq5OVlZd27V1g+yIP9fzZVIxDw+Xy+3xzn3yLPv5VnznzxxZgxhWVB+8qVo0b16VNY
9upVt26ZMrB584QJr70Gs2YNHNi5M2zZMnHi669D7dqxsRbLH+UX6H0Qv/+3XGNV/e0cjgdL
STKZzOY/ljZbYmLp0g8vT568etXne7jcAr2Pm0d2nI2LzBnGJyC8T+iBiBjQ3tQnKG4Q8oUQ
IRVIw6Q3BLbrlYVlIHwgfipNAOET3/TcWaBeyquTFwLiF8I8815Q+wkZ+ioQautfMxOopI8U
IkB3UwIBkBAA9Dwy8IIwhzlCA9C/QRLmgp6lTvNIIHbyXPH0Anq5fd51gInZWgoI1YUqZIFY
T3qLqXB/ZVb19Hsg7r721NV0GGvptmrom1DlWIX6ra9CtXp1XmzVDlplvdS0Uz8wjKvwcWI4
/LRyZ6sdq2F7u71ZpzeB8VRgjpYHFRs7wsMbQLxDT/C8B6X8pujcJ6H80zGXjW0hJCmubxkB
pL2WfY7u4Nuc9WraGfAPc1509QZjsmwJLQv68yZT5BlI25A3QKsCd6vkTvc1gsxtzjJqW0jd
nnnQLUL6l9mDXF/CvRYZW3K+BfNxczXJCcJtf5o2DOQuTFaHQlS29RWhMkR/Z/3CXAMc52Sb
WgasZ0xvGOPBH6O8Tn3wDlVv5KZCrhjYcyIS0l7LqXnuDGTtCPS8NByctXxfu2NBusMOgwzu
1oEQz3wgXOpvuAfunj5jTkXI3x7Yn7wQ0vvlHLs5AzI+zPnacw8y1jqNae+B4YWw646+ECI4
sqO2gKOd6WvsEGYIOWysAMLLylTTOMi/kJ/geRaMJ6Qzigd4SrTTDtTuot22FrTZ5qa+QSC0
t/XPSYbcS4Hi6Z3hcv17odfiID3Sc+beRSgyslTnsBlQ7HCx1qX7gKAI8db+4C6WXzyQDpZY
x6CQ1yB0dcydmMqQ/llyaN4+OBN75OtTAtx8MfdgbhiodQ3DDaeAzppP6AKsFpoItUF6ITy1
aBwoG+TQeAGELHG48Cf+gP9ZCs5jLnB8CyJGD57T/M8oSM14MNe5QE6B3AI9f1V+gQOzevXq
1atX/7Gsd6HehXoXYPvU7VO3Ty28bsyYMWPGjIH639T/pv43MHrN6DWjfxfBfXD8o1KkbZG2
RdoWRvAKIodZk7MmZ00uHLen+57ue7oX1ocuG7ps6DIYcHTA0QFHIfx6+PXw6/9+Ox5MqRli
HmIeYobXF7+++PXFEPJ2yNshbz++5/NnCX0u9LnQ52C2b7Zvtg9a32t9r/W/kJ5UcN8FTJ8x
fcb0GbAte1v2tmwYYhpiGmKCZeZl5mVmiEuJS4lLKRxvXGxcbFwMsc/HPh/7/D/Xt3nS5kmb
f5cz3KRJkyZNmkDjdxq/0/idwvYtnbZ02vJfvMToz87fvl/2/bLvl8J6QQpMoyuNrjS6AotO
LDqx6AT06NGjR48ef9STOD5xfOJ46JbfLb9bfqGevOl50/OmF457XOvqcc3r/xYeTNX4s+WO
HUuWvPFGYfkgD/Y/eP3DUzV+O8e5IOL8YOS5cNw/bm/X7umnq1cHh8Ni+UeR4O7d69WrWvWP
8gv0PkhhxPm3+oNlQcT5r5YvvNCoUcWKD5f774o4P3KqRvHZkb2LfQGGm+ajVgdoK/RsrRwI
8dzQb4Nu1bsKm0FMYIrSABghzLN+B76ncmbmXQf/cY8UehiMBkMPqQeIndXLgaXAWj1M3ggs
F3vqXhA+1eeSD/p+/QK/gtBP6MIyUCP1NloCSF21ksJV8A3If9sngJDicXrvgqDLZU0LQGpl
WqetAeFZWZRbgL5IO6KOAsMG70pPLDQMfdLXvjqEX7fdKpUAvnB/tncA2LtFDys+AhxGoUGJ
hhDlTXIrP0GEJ+LNsCdgT589w7Z/BKtSLx3IrAgx0zz19AtQ6kLYRFtbMMaLu71RUKRrmKg2
gbVPaJXIg2M2Q51SA0HbndX3zjoIfJS3Pn0v8LbaU+8JlmohjcMPgLZIXifMBv9z/u7aFnDf
zxuZngOBSF9IfjuwVze3lAZDZC+bat4E9rOGA9ay4PlUb6yHQVTd8MWGyRAxICwxLBfSvsr4
3rMUbIPlz11rwLRRzpT2QVqxLCF1ByS8G9k3rhuk7/ANjR4K6V/66l8ZAPZIa33HaNDHS++Z
VUhf49ZurQNhcV6sfAJCjlu+iy0K0k/WH90bwFbB0Tp0HojdlB8iPgPjr+IdYzJoU0ly/QS3
6t+dkFEWfK96052roWjjmMX2knBzb1oV/SVwJyir0vtDkZzwlnIfCMxRvjAfAncLz3OBcMi+
7+6vzYDIMvZvi5wD16uBgZQCW7RpgXEUlOgYs63cCShyu+gnJQ9B2Ovhw+OXgL9VYLLUENy1
/BV8oRB6LLxDRCw4LkdXjOgI2U+lb3EuhZunT8WeXw93HNlvpg4AbZoxMnQoME99RXgLtK6s
950FsYKpcZgJhKnakUAEaE/7KmQfAOl+QHfFACUfz0J9MLVi/fr169evL4wI/9nzmAtymx+k
QE6B3Ifp/WcUODBJo5JGJY36LwZ68PC744iEY8Ix4RjQjGY0A+G4cFz43U/jWj+tn9bvj2Ie
bFcPq4fVw//cTnGgOFAc+Lv6QnGhuPCP4/R+ej+9H2DFivV3dhZwjGMcAzrTmc5//jn9VTsC
VQNVA1UL69JAaaA0EAS7YBfsII2SRkmj/rm+x03IipAVIStAHCWOEv+B/j87Px8mfpj4YSK0
+6LdF+2+gMMvHH7h8AtwqM+hPof6wMbEjYkbE2HZ1GVTl02FVaxi1b9icA1qUAM2Tt84fePv
HM6CfxgfpCBlY3CNwTUG/4OUjT87fwUpFH8Y939SX/4ZUm2ptlT7n+t5kH91Xf2zeQ3yf1OY
qvGPHdnHqef38h+WqhEIeL2/3xz4MB7Wv3z5oUOXL8OyZUeO3LgBH3zQsmXVqtC5c82apUtD
7drlyiUl/Xb9sWN/1PtHPf93xPlBHpaqMX58p07Fiz/c/jt38vLy88Ht/sdy/2Mjzuajrnpy
EzBUpbtUFECfy23gulBJuAqiT35Nvg0qwmR9LTBMOKQfAfV97wzpIviaSTVjZ4E4SFqIApTR
zrIA9KHCe9wAzusr9EjQ0/EQAezByXnQu+p1mA+G/tJB+TswNDXOMFYB6ZAjMaYuJK/3TTAW
hUuLM0fp8yBnuq+YMASkH8XWtAFlo7LLvxNCisQXL/sDhNqjk4p2BO8Pitd9H4TPxHYMBOUt
NdO7FALPBJZ4h4N20vumOg8SesdVqH4Y2q2pLT1dEep/VrlCRB6EDSlRx1AXlDXGAb6PoYQl
emdEDJSLKvtMyAmopltDc2rAEyONktYCwpTokOLLQCKscbGWoDby3cipC674nCMpE4BLWg2m
QOiJ0F8iR0HsmERfUi4k3i36eokhEOqzVYooBcJ1wwy5PITuj14QEQCHyTLF9DWk7k1rl3MV
zmy/WDbtI8jd7A3xLwdbb3uLiGywz7dJtrZQtWfS1uKLoUyPiLhiUWCw08b3JRTLjzpU4mco
Pygsu947UPSSvWHRr8F21WKx1IPSCSXOV24BEbawXpHHIWJCqCluIshTJCmiHHi6qsc8CijD
dXvuHjCJ5unmbhC+1v4iYZDwcdzGkH2giris1SDqzaifHd/Ck2fKlkk4C6Hhto9D+4E0WYiU
W4At1JJs6QlWt62X0QpiM1Nb82GIvR0WnzQfynQtnlFWhvIHKjxTsynYk0O+T/wFcru5Juv5
kDPEa1Lug7VOZE5kTTCNj5wdmQe5+t2+uVXg1tljL504AakHsvpcPwxqhLmqJRX0V6Ro43nQ
FH2V3gqEEsLnFAHuq9u99UCx+dY574NSSX3WdR0UK88pux/fQi1wYIsXL178918kBX/wH3y1
9p+l4LoHHYcCPf+uXOjGKxuvbLyysP7Rpo82fbQJ9pXfV35feZgwYcKE3+fiNW3StEnTJoX1
ghzc1I2pG1M3wqrGqxqvagx3x94de3fs47PzmSHPDHlmSGF95sszX575MiwQFggLBMjunN05
+19wmP8qtU/UPlH7RGH9swOfHfjsAMw9MvfI3CP/fXb8Wf7q/Lxpe9P2pq0wx7n6kepHqh+B
QbUH1R5UG6xvWt+0vvnHCKuwUFgoLCzMFS5IMXgYV0KvhF4JhevvXH/n+juF8h/8ZaQgIpwy
NmVsylg4+/XZr89+/a8/j2eWPrP0md9twvxk3yf7PtkHO7vu7LqzK7w699W5r86FFZdXXF7x
CJtnH3VdBfnXKEyd+GsR5yZNBg789tvC8kEe7P+jnH/sqAcCvx0L9+CpFw/ysPbdu69cSU0t
7F+8+MCBK1cefn1BWaD3j+MKNgf+45QKWf4tNePBcu/e69dTUuD8eZfL4/ljmZ//23nND0/V
+A/dHGj7NXJs3CLQO0h1DJdAXM5Y3gclxb870At8T3hWuauA6ZVQ7J+BsZgwWj8DZ+dcy83s
A6ENk7ontQbjaGZow8D7odBWXADCz/ys+0B/h+NaMogzhO7SYRCqsFFYDfpZalEGnK8583Ku
weoZa85usIDvc9UcsR2qbXuqTf1toBcx3GUXSD3kNPksiNHaNqUEaP3EE4ZewMvUEj6HwFP+
G/pZEP1Sa7YD6/WuZIKwgrfEycBcMUl9GSiiDZatEOhBmvgWiCsT36laAiofFj+wr4cSr5sW
nJ4FWaXCU3NGgngh76jHBuInie8+4YFKYyrtDVyAxNVpac6pcCopy6esgzNzxcv2d+BOeXOT
pDug3czbmTYKfJ0ym6b2B62o/cvQrWB/L+TLEAVMP1uamhJB/MT+lf0MaAGlk78ppG3PiRb6
gauY57yaC64Z+ouGnSDGyCXVG8BQ7Us9Cu68lnY6wwtsUl8zhEJY89DiljOgvCid8e2HUttC
+hR/AeQEw7yIopB3xuXxLAZ9hrDV9y6Yt2gDw3YCrbXGDADTJLm9+BUYL9EqIg0MfW19cy6C
53uPlHURMo25nfkC1LH+icnnoUypmNjyAQgdL+2LfwVs68Jm4AOlkuuUU4L7I5JV12hI6+VM
dVnA/LJZNZ0GsamwUz0CjjTzZFsPCC0XUS9kHtjHOgxhK8D8oX2mpSL48n0lhd3g/MA5yC+A
9K7pHVM4RKqxi2OWgLmzeadhFORPvN0r9VNIX3Oz31UT5DXJ1W6VBg9GQ/hnoA5ljPF10Kdo
c9TfPn+D1Aug39EP6ZVAG0GsXhmIELLUdSDaiTa+DTxLS73a/1kk7R/fgi3IPS44nzk3Nzc3
N7ewXlA+LLL8z07deFDPv4uXPS97XvaAX/frfh3WjVg3Yt0IGJExImNEBkTfir4VfQsGFhtY
bGAx6BHoEejxuy/k4bbhtuE2mGmeaZ5phu9Gfjfyu5EQfTv6dvRtSCONtMdgZ+8qvav0rgL3
X7j/wv0XYMvELRO3TIRiu4vtLrYbIidHTo6cDJlbM7dm/htfdNNf76/31+HeyHsj742EDSkb
UjakQKWIShGVIgpTFAoc1b+bvzo/BQ7s9BXTV0xfASNsI2wjbKAeUg+phwo3Y44oPqL4iN/9
49ghvUN6h3T4sduP3X7sVrhp8GGb2Ao2VXKe85yHVh+0+qDVB39MFSnYbPc5n/M5sGXSlklb
JkGlbyt9W+lb/jJ9+/bt27cvOGc6Zzpnwubdm3dv3g0bb228tfEW1PbX9tf2F25+/Fd51HUV
5F9DVX97hfTDHNl/Xe5/La9A74MEAn6/3w+S9NupGQ+j4FSNB7lw4e7d379Y5cH6w64v0PtH
e36L/D4sccJms9stFvD5FOX3I7ZvP3gwORk0LRBITf3jdU88kZRkNkO1ak8++Y8CPAV6HzfC
wYMHDx48qOt16tSpU6fOXxfgxtUguyZw2XDS3hWELD7UqoBWz/+F/xD4YtzdPD6wGcPnRiwC
9bL+lq8PnJ+yNfJ4DygZWWd09etgfTX8uGEQqOfVTD0JOKo69W3ANn2F+ioIPQ1PGsrB9aS7
yeeWQ/HNMbVK1wWlj9JOj4M9GXudR6qD81eXRY0EWjm+L9odSmaW8hX5Bcrfi19nSAZrF2tR
9oNaXm0h3gOpgzCOk6CUVzd794DoF7rLR0F4TaokzgL9ba29tA9YI36iBUB/DkFIAHG/Lirv
gr+Gs0JeBzCmGNqoC0F9wTU54w3Q5me8nPkdSK7I6WGdwXsnc+N9B+iT06emvwHSLllnBXhT
pTueNMhKur4zJx1WX9tT4n4LOD4s+ycpHfxLvOOyZoM/090iezII1eSRlssQ9mZInYhN4Hg7
dIN5I5gchtf0e8BAtbtfBm9F13rvt+DL9m8PfAbKMv2iNgz8sf6r3nTwDXRZcg6A2WlZZx0M
EdmRb4S9Bd477jHeruAp5s5y/gyZVbNyUhuDOl3Y6LwNWnvhZUtRcHb2b89Oh5A8xwqxCvjT
3NuEDyG3vjvX1RPKpcWPK/oZyBfEKEtluBmecfPuUTDUlbdbekHUmjA1tj1E7jGfN5UGbY8+
SukCdwfdGebdBprXOIh14JgQKlkFML8if2O9CTG58RtsCkQ0jywelQmGQeZrIedA+0DZbXgT
XKnO8ko+eDPVDYHhYFHCzoUdg9Bl4XPC7oFYUfvZsAOcUfdz7ncG3zfZA+6kgsenfJ47GbL9
rrcDByBvmz4qrCvopcV55mMQmMAM6Tnw3Vfe5zUI9Ap0D7SGwAFlpe80KDMCnbzngIXqPc9U
kCrpS3w94Vjqvk83nHr8C7fAsS04PaDAgf5XCQ0NDQ0NhWHDhg0bNuzf7zgH+WsU/DKQ0jql
dUpraBPfJr5NfGFu80t7Xtrz0p7C+sa2G9tubPt3Wx0kyP8OKld+/vlp06BKlZo1y5f/1+V8
882HH7ZuXVjv3v2DD/6rUyVOnz569MIFOHNm48aRIwvbo6M7d54yBUymYsXi4wvbk5M//viV
VwrrRYqMGLF06cPbH+SfjfP5bt++dw/S07///t13C9sHDz569MYNqFQpIcFq/aPctLT79w0G
OHHi3r2/8o+H35+fn5UFrVvXrx8a+sf+s2dTUtxumDOnZs0SJf683Idx6NChQ4cOPYaIs6Z6
fvT2B8O3xqaWI6C10T7WO4Jc1vitoTrIS0yKORHUEH249j2wxLPePwEcnzv223aB8QvLfENv
EDdLdUUTiE8IF4VnQWvLi+oPIEXLGYbXITUve3ZKPlx/4/qCQ1ugeJu4LnFNIPMLd233IHA6
TRNML0GxlWUWViwK/iLut3DDrRn3X3YNhgR3eF/7TbAesZc1ZINeSxvMUOC43lw/D+JEYaHo
B2GJ2En+AvSi+hfaFND684M3C6iorlOHg7RYPGEZCfoRcZDxHsizHesio0Dzq+0CoaB3MExT
V4Ky0FLV2RzktpY7se+DOSyyvnk20DMmsXRfYLKjTcxksNyTzHI0RCyuPst7BN44XeO9c9/B
r8v2XDjxE6ybs7+M+hXce810OjQJlEN5ndL3QfaBzMr33wdvnnujZTGEbwu7GVEfwk6HlrXb
wNIi8pYlH/Rn9CXqANA3KF7/avBX8Y0zbQfXMEs9w2kwnZdjpUGQeTH7S+/34H1W2R14F+Tz
xvGBY5CzxNsnewhY25j3WCaCPdKyznYPTIct7XwtQV5jGKdtAdedvBD3TAgrFjEzLAnya/uN
viOQsyK/Y05vEA5LI8RNYPzCMMHwMlwec7PhtRywvWY9ZGgHoVvCGhn9EDWq2MUi6yFyWkhk
eFMIvx3mc3QC0wyTM1QHQznbdvs4CBgCK6Rh4Bqf+5PvSchf57sYeB4kszXHMBbCj8VcjZXA
ssN6yGEC5ZW8i959kJF95/atoZCx5m6VC+shEK83zpsH2if6O8L7kJ/krqp9A87uqpxXAwLZ
WhFtKfirqd/pI0DZpnfQnwB1v9JX3Qz+6oE3A5Ggj9e2qlNBP6n2DTwDaiDQxPf+oy/Uh1Hg
2BY4ugUOdIGDdevWrVu3bj38+oJUjIJNggVygm8U/M+k4Ni5Xd/s+mbXN9CPfvQDmM50phce
1/Zm5puZb2b+3dYGCfK/C037LTKcn5+VlZ8PJpPV+o/OOf6r+P3/OGfY53O7fb5CvQ8SCPz2
5jxdz8tzOkEU//Emv7+awvGwcZrm8Xi9oCj/+M2APt9vdmZnu92KAqGhFov8O++zVKmoKI/n
t/OhQ0LgwoXMTEGA/zpeDk8/XaJEfPxvkWy3u7A9N9fjUZRCvY+bR3aclcmufP0nMNQL+0aM
A3Wpf6NaE3yz9PmBZWBsaGpCDMit5YaGRPAcCnzlawbieWGJNgcMy8ydDe/A/TH3b99cB8p2
5Vf/92BC+krvCY6jtqHhByH/qZxueT6wv2q+FjEGTKXN6+0DISrcvtkcAc7VziJnNLiyIqVd
7peQWCFyRlQa2HZYXlLrQ8q3aXv9ZaBYo/AiplOgNhV8FAFltFIycBiESWJbsRFQlIVCGAjb
uS+vBN0murPHgVCbGmJVIFJxqs+CctfpynkKDI3tTYu0BrWycE+9BLLTcT2uBhjO2sPiKoP2
rHLEmQ1qG+/B/ApgrGeuF/0zqDsMq23Pgvq59rIugWaVXzYfBlv18sfqvwfPly3f5+k+UG5i
mWobvoYFXX/46nBduLzVKpc6Cd6KrmYZq8AzMP9abiz4d6RtvDsEXPPzNpvHQ+iXjvyoaAhJ
DllhOgi2y9ZXzN9B6LshHzkUiDofVUtNA/9ZzxrXs2BQbIl55SCwW+krlgYl0avpm0D+tGR+
sY6Q1yf3La8GpiaGN8zVQLqrrglJBbfBXdO/AOz7Lf2FUhD/Y0TF6NNgx/BswmRIm25slfIK
hOyyH7BNhKh9Iauid4OzU9G3PX3AMMt4jd3gSAm32vqB5ZrZGfYVGBvKZvtgCPi17dJT4C8a
MBEDOTnpX3hfgMDXag5bQfvV2MXcHixfhY60vAv2quFrI54HqZjvIC7IbXjzePoGcLXLup/c
G5SzysL0j8HWxf6lNh98W5QrlgXgLevf4+8GdtGSpB0CaX1gnrso+D5UKuilQa8vVyAflNta
XzUU9KdMcXwISl/dpD8N2jFtkyaCcEkwGP2giMoK+RF+cv2zFDi6BY70g8fIFZzjWkBBLnO1
atWqVav277cvyOOh6qtVX636KixlKUsBhjCEIY8qNUiQII+DJ54oVSoiAu7cSUnJyIC4uISE
qKjH50AXUOAw37//m54CvQ9SsWLx4hERcPr0rVuZmSCKoaEhIRAWNmjQ/Pl/HP+w9n82Ttc9
Ho8HNC03Ny8PqlQpXjwy8o/XhYYajbL826u5/X5ISPgtgSIszGKRJMjKEkVJguLFQ0Pz8qBu
3cREmw0kSRDE/2In3q1bv+nNz9d1WYacHI9HVSElJTfX7y/U+7h55FSNew0uvntjC0Suf2JK
sREQSPd0UkuAkqnGBkaBqbexpeE46LLi8tkgd+TurodCIG+W/pVcFYpcfq7qM20g25PjuVcf
fMuVYcpoMGUbvxGrwdk3Lif8mgK5l9TX8l+GMqWil5fqCglq5JqKuXC60wXn8Tw49/5d/4VL
cPHM3dNSHajyZsWPWr4AdSZUyiw2Gp44FrVBaAlCSUNHsRiIG/Ut+grQp2jN1Nugp4pthDQQ
uwnFDY1BSBX36M9Dqin7+qUBkN7FO+tGWYgYFtEupBdonzpd2VMg3GJyVvwAQuc4epWrB752
WgX3BeADQRZlEHaRIvcC8QstIjAMlBn6z1obEHWxquENIFGP1lJB+Eqfp58GNV1vICQAFdkn
RYHtC0sVuRGsCp3R55O7sK7tUeONPqAn2KZHXQT3ZG/jQD1Q17tL5P4K+kXPzLxrIMraKf9S
sL4n50kzwLzL3sWeDw6Lw2KdDSEjrC+ZT4N5utlkkMEwQh6lPgfar6RoBvCXVj9WvKCf1Eop
3UGbp50OdIOASXla1cBTzfu6fzQIK+Vk4XmQ5gpxYk2QpgkLhEugLdBaCAKY3Kb3jXtA2yg0
134BUxXxGeNLYMg3/2R9ErRw1gjnQJsUaCimgreyt5lWHpx7vcX8AQiMCmwNZIBaT1okvAVS
jPGI7TgYx1vCjfkQXSakrgUo4osdZLsEdwL338j4GfKVnArpX0B27dSEi50hNz/N458O6jE2
BX4FOU5poyWBaBJXmhoAq41mOQLkD8V1UlHQ3+Ed6R3wT1DL8i7on5CvjwUEGgknQU8QfhFX
AB+IW6T5oMvaKb0WaG8JN8SdoGeI5+Rp8GO3n0d+v+3xL9wgQYIECfKfQVZWTo7TCb17v/PO
11/D+fNXrqQ9jk0WD6FChTJlYmJg8eKpU19+GSIiwsJ+/2bS9PTcXKcTXnhh9OiFC+HkyStX
/tE50Y+LatXKlImPh59+mjixXz+Ijg4N/b092dm/xY4/+ODMmeRkSEv7LfL87yImxmqVZfjw
w8qVixSB8PDH40A/tlQNeZzjO+NaCEzPqZvvBv2V7G9zdoEw3pXisoI+uuy8Ui1BLe3u414O
zuKbz/36NoSZX3y7XT4I+ywJwnFImGh8pegAyB7krpJnhxMZx7UDM8BS1mgMfQk8+2xr9FsQ
tcNaMr4hGN4xlguvCzvSdoXf6Q33Rgg/3O0M7ghpXeAGbD226/z3F8DXyU/Xr6FUYuP1xeuB
xWU6T09Q92uvix4QTol3hTkgjhT2SB1By+VDfwLIC6hnPgPu2nm+rP5wefWVnsdLgXJYn26Y
D/pC03DNB9GnIiKTL0LF7UU+9yVBdLK1ceIuwCIONnhA/0ZEawhMEjaLISBAS2MrED7Uq6sV
QF9HDzYA24WlwkQQw4XbFANtJp2UAAQ0pYh2EISK/tx8HcQNGU2uA/I4ba76Psh9zF3tG0B7
IaxE5CVQfgmpGnEV1F5+wfk9+Pv7Nud3ACU6MEarCYENWdOyLkKOM+sZuT2Y6hs/FN8Bs8W0
w9IeTJUMw02lQQw3zZM2gHRDkuWDINU1lLPuBOMeuYnYHgzmkL0EAJnntBQQvEwQl4AQokv6
BtCa6rcoC8pQPVXrA2o5JZJFkN9cKcMr4Fub08cbC97egSmKCAExUEK5AOpR9nIW5DWmZPM8
MC61rrBNBWMHcwPrQYgbZV9uXAo1OpebGbUGanxX8+XKMyDus6TLpabA5ne3zvq6JKS+kTfp
Zmmo3qCmr20bWL1pzb2fh4C+2fOqoSQ0/a5KrfrpcCXubIeMsnDs22PlzleAO4uyIrLGgO95
ZbDSBSxjTcvMvUA+ZnjV0A+0imoR/V1Qa2lfKidA/1oYIH4LYnO9uxgK2mX9rmYA7bi+Tx0F
dPv3fTkECRIkSJC/nwLHdf36+fNfe+3vtqbQcT106PPP33zz77am0HGdPfsfb+L7f41Hdpwt
85XJ/lYQWH4z7956INLXwlMFtGe8RfwvgnG30KbkGiDUNcv1M7DFfz2wBEyfxESGVAPDcqbJ
GyHzLffaDAGOrz8+fN8sSJhp3Bb3FriSzc1d4RCWJoxwJELsprgSxXvBqVPXvkwTQTwdMjhx
AeiLMtekhELRIuWHV2kLKTWu97kyFy4suOq9lgFHtiS1j0iA57pUnGnvBYFVgWW+SSBvM0VY
ngX1sLbemwLCKWGOqSjQVy8jhIPhA8tE0y6IKVFBKwMkHz7luTIMSu2WIuJWgv2SK9LSFq6l
bt69Kg7sc0unVWsDwjqho5QE+m3Wy+3BMKLo9jJdQX4nOrvE06Bv1xsyD1gh9CQb9IX6eXQQ
khnFURBr6tFCKTA01BPUD0D4WlusdgXXV84nM++D/Kqy21MaxE7m3Y4NIMdY9kdEgzHPciHy
Eog1LHNsP4Lp51B3uADaFGf/rFjwosRqcyHwvn5PywHtkF5c08HZ3LPWcxzEl13+/MugSOou
/SLQXHdzBoRVwhlxEhgX8oRwHvSdYh/6gP6qsEhwgdCQxUIC6PP5SVwN+iRhISGg9defVfaB
Hia8J5YB/TWhqHwXhLXSdrkFSCcNxwwHQT4Z0iDsFlimWabZfgazw7jGfBDiMq1ubSfUaFq8
tsUO1VrVrlL1GYjbXVauIYGySDhnjobASX0mO6Hhu/XdXcaBs4gz0OhdiOiV8FrpzyHa0n1h
2T1gX+goU0aG0EthvYu/BxUya0672w+Stlbvem4ofO9efmvDbfC/l59zzgPJHVO/zq4Iak9x
muQEo8OsWY+CIVFaYpgPsllaKD4DdMMpdgZ9lRqvnQFtoHJc/wyAcjT6u5d5kCBBggQJEuRx
8MiOs7RBPiKdBt3tqG/7EYRNMWmxo0DowAUhE6gk++Um4Ft+J+76DZC7RL0aPgbk92MiYr8F
T0jgfn51yBudl3xvEFTfWrlu3YUQ3T98erwNDqSfb7xhNIRH27rHTAK9nXzd8CacG3i8+o5d
YJxpbVt8MRSfafuyfDTU2lb26lM2uNAgsmdJQHhe/VJ7GqpmlPVECuAb7Xo2/T0Q3vI0zmoJ
2ipZtRUHcbm1v80HeiNDnvEHkC6ZN4rRkDLwhHy1EqSczX3vQjuwLYj/0JQFEalRjZNmQvn3
K/taDgGPuWK1u37Qk7Nq3SsCvgX3Ot/4AfQk13s5VUGVwss71oLh2Yj46DzgCWFYaDXgLP2U
eaA/zzlGA6dIZiVoLYUf+RB8n/g76M3Al+/fgBO0AfJdQ2fw3g4sci8DDN7D7u0g5OWuyvwF
TPmm7Ps2sLa0jwnzQ7EtxRKjUqB9dN/6zarA/fR7t7NfgtsrrsXfzYfb/TMGu3pC5mfuEoGp
kH/Sv1CoA+4c/ZxyEoTWaqQ+EgKhKlo8uE+o6Vp34AlhnL4e9GhhD/OAtXxIJogx4lDxKRCj
DB8YfgBhgxRp+AbkdYbWxgYgzZAz5IkgjzB4jO+DIUl8S14OjKczz4IhWrUG0kGbltHwfnV4
rvjzHUo1h6efbUP7kuB9T2wddRN88wNjvdGgHxa/8DUDMVa6LHYG6UVzmG0RRI2SK1jyQR9D
VfNiSCxWdG+TcRAwKVOVreDP9F/2Hwfj+7bd5hYQOK8ODmsLT79avV0VH8TPCcso9iokH3Rv
01+C7ee2fLrXBSlzMt+4uws8ZsNZeT1YBOUr03EwrTTVNG4A8ZC4TzwKcoThSfm343OCMecg
QYIECRLkfwiPnOMcJEiQIEGCBAkSJMj/ZApynB/5zYFBggQJEiRIkCBBgvxvIOg4BwkSJEiQ
IEGCBAnyJwg6zkGCBAkSJEiQIEGC/AmCjnOQIEGCBAkSJEiQIH+CoOMcJEiQIEGCBAkSJMif
4P8/jq5gt2CQIEGCBAkSJEiQIEH+yP8HQZ0UJZX6QY4AAAAASUVORK5CYII=
--------------050503040205070603090907--

--------------010108040302090304020507--

From bcampbell@pingidentity.com  Fri Feb  7 12:00:45 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A9C1ADF34 for ; Fri,  7 Feb 2014 12:00:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.912
X-Spam-Level: 
X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZIPm4S8ym-4 for ; Fri,  7 Feb 2014 12:00:42 -0800 (PST)
Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9A81ADEA6 for ; Fri,  7 Feb 2014 12:00:35 -0800 (PST)
Received: from mail-ig0-f171.google.com ([209.85.213.171]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKUvU7Y/54ESTzhUKQLKl0Hj3ntc3myXmJ@postini.com; Fri, 07 Feb 2014 12:00:35 PST
Received: by mail-ig0-f171.google.com with SMTP id uy17so2560804igb.4 for ; Fri, 07 Feb 2014 12:00:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=swgAaSwYz16nzBwBQo2S7EVRIHJvMcHbxlicEIT+p2c=; b=JEtlwL97uvMpCbMv5H6Sr3grzTnPOAvGN8Jlahkd/YmuSV8mWlCxxSdynLNe4o877l WpDt39K74ORed+uwlU9yLayu5Z+V1fumWFbj6OEqwhK7iB/b8S/81t1mU4IRfIHu9UZ3 XUv4+BWqKe+0sb89s67ngirBmE+JZh08huh5PDVIWPdUT1uivdBP6Sb94ALRG6o0nhQT MHBHVr8mDQDTz4xg+PRDvVdSsfOJpK6G+VpJCN8hpXfL/McCiUjs9TjtdKzdCmjxtfXp WQnS0xFjw4VQRqiafPSOalHtf5GHDHK3J8h+Anyp51xPfoAiLWGoMSV1wKCp7qHGsUBE syNg==
X-Gm-Message-State: ALoCoQmCGU5FwX/tuLYR/4d+mGaoiisXyptpw0mwpTrJ2f58tK1Rfg5WSDjDQZ6AXqwPpSzL6Obr21lg5Qe32PB7/AuajizwJDFs1WWLNcx5KVSvb00BmOito+/XN3YElqTI04X4JWgcO7P4l2rqSZ41e5uCJCkB6A==
X-Received: by 10.43.74.198 with SMTP id yx6mr5210371icb.40.1391803234941; Fri, 07 Feb 2014 12:00:34 -0800 (PST)
X-Received: by 10.43.74.198 with SMTP id yx6mr5210345icb.40.1391803234596; Fri, 07 Feb 2014 12:00:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.65.4 with HTTP; Fri, 7 Feb 2014 12:00:04 -0800 (PST)
In-Reply-To: <52F53A4A.7090600@aol.com>
References:     <52F53A4A.7090600@aol.com>
From: Brian Campbell 
Date: Fri, 7 Feb 2014 13:00:04 -0700
Message-ID: 
To: George Fletcher 
Content-Type: multipart/related; boundary=001a11c3923e66ff1304f1d67115
Cc: "" , OAuth 
Subject: Re: [OAUTH-WG] Another question on RFC 7009
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Feb 2014 20:00:45 -0000

--001a11c3923e66ff1304f1d67115
Content-Type: multipart/alternative; boundary=001a11c3923e66ff1004f1d67114

--001a11c3923e66ff1004f1d67114
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree it could clarified. But it's also what should be a vary rare
erroneous condition so there's not really an interoperability concern with
the ambiguity that's there now.


On Fri, Feb 7, 2014 at 12:55 PM, George Fletcher  wrote:

>  +1 for this solution
>
> Is this something that could be clarified in errata as it appears we have
> three different providers with three different solutions:)
>
> Thanks,
> George
>
>  On 2/7/14 2:43 PM, Brian Campbell wrote:
>
> Thanks, Todd and Thomas, for the responses. After some internal debate, I
> think we are going to treat it as an invalid token (which it is in that
> context) and return a 200.
>
>
> On Fri, Jan 31, 2014 at 11:19 AM, Thomas Broyer wrote=
:
>
>> FWIW, we return unauthorized_client.
>> Le 31 janv. 2014 18:06, "Todd W Lainhart"  a =E9cri=
t
>> :
>>
>>  > ...what's the intended way that the "request is refused and the
>>> client is informed of the error" when the the token was not issued to t=
he
>>> client making the revocation request?
>>>
>>> We return an error_code of "invalid_request" and an appropriate error
>>> message.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> * Todd Lainhart Rational software IBM Corporation 550 King Street,
>>> Littleton, MA 01460-1250*
>>>
>>>
>>> * 1-978-899-4705 <1-978-899-4705> 2-276-4705 (T/L) lainhart@us.ibm.com
>>> *
>>>
>>>
>>>
>>>
>>> From:        Brian Campbell 
>>> To:        oauth ,
>>> Date:        01/31/2014 11:58 AM
>>> Subject:        [OAUTH-WG] Another question on RFC 7009
>>> Sent by:        "OAuth" 
>>> ------------------------------
>>>
>>>
>>>
>>> Greetings WG,
>>>
>>> In section 2.1 of RFC 7009, it says:
>>>
>>>    "The authorization server first validates the client credentials (in
>>>    case of a confidential client) and then verifies whether the token
>>>    was issued to the client making the revocation request.  If this
>>>    validation fails, the request is refused and the client is informed
>>>    of the error by the authorization server as described below."
>>>
>>> The only error described below is "unsupported_token_type" which doesn'=
t
>>> seem appropriate here. The errors in
>>> *http://tools.ietf.org/html/rfc6749#section-5.2*are referenced too and, while "invalid_client" see=
ms right for failed
>>> client authentication, what's the intended way that the "request is ref=
used
>>> and the client is informed of the error" when the the token was not iss=
ued
>>> to the client making the revocation request? None of the defined error
>>> codes seem to fit.
>>>
>>> Furthermore, wouldn't it be better to go ahead and just revoke a token
>>> in the case it's presented by the wrong client? I seem to recall some
>>> discussion around this when 7009 was just a baby
>>> draft-ietf-oauth-revocation and, while I don't recall the outcome, I wa=
s
>>> surprised to look at the RFC again and see the text that is there.
>>>
>>> These questions came to me by way of a developer working on implementin=
g
>>> the RFC. I didn't have good answers, beyond the prognostication herein,=
 so
>>> I thought I'd take the questions to the WG list and the document author=
s.
>>>
>>> Thanks for any clarification,
>>> Brian
>>>
>>> _______________________________________________
>>> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
> --
> [image: George Fletcher] 
>

--001a11c3923e66ff1004f1d67114
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I agree it could clarified. But it's also what should =
be a vary rare erroneous condition so there's not really an interoperab=
ility concern with the ambiguity that's there now.




On Fri, Feb 7, 2014 at 12:55 PM, George =
Fletcher <gffletch@aol.com> wrote:



 =20
   =20
 =20
  

    +1 for this solution

      

      Is this something that could be clarified in errata as it appears
      we have three different providers with three different solutions:)
      

      Thanks,

      George

      

    

    
On 2/7/14 2:43 PM, Brian Campbell
      wrote:

    

    

      
Thanks, Todd and Thomas, for the responses. After
        some internal debate, I think we are going to treat it as an
        invalid token (which it is in that context) and return a 200. 

      

      

        

        

        
On Fri, Jan 31, 2014 at 11:19 AM,
          Thomas Broyer <t.broyer@gmail.com>
          wrote:

          

            
FWIW, we return unauthorized_client. 

            
Le 31 janv. 2014 18:06, "Todd W
              Lainhart" <lainhart@us.ibm.com>
              a =E9crit :
              

                


                  

                    > =
...what's
                      the
                      intended way that the "request is refused and th=
e
                      client is informed
                      of the error" when the the token was not issued =
to
                      the client making
                      the revocation request?
                    

                    

                    We return an error_code of
                      "invalid_request"
                      and an appropriate error message.

                    
                    

                    

                      
                        

                          

                                

                                

                                Todd Lainhart

                                Rational software

                                IBM Corporation

                                550 King Street, Littleton, MA
                                01460-1250

                                1-978-899-4705

                                2-276-4705 (T/L)

                                lainhart@us.ibm.com		
                        

                      
                    

                    

                    

                    

                    

                    

                    =
From:
                      =A0 =A0 =A0
                      =A0Brian
                      Campbell <bcampbell@pingidentity.com>
                    

                    =
To:
                      =A0 =A0 =A0
                      =A0oauth
                      <oauth@ietf.org>,
                    
                    

                    =
Date:
                      =A0 =A0 =A0
                      =A001/31/=
2014
                      11:58 AM
                    

                    =
Subject:
                      =A0 =A0
                      =A0 =A0[O=
AUTH-WG]
                      Another
                      question on RFC 7009
                    

                    =
Sent
                      by: =A0 =A0
                      =A0 =A0&q=
uot;OAuth"
                      <oauth-bounces@ietf.org>
                    

                    

                    

                    

                    

                    Greetings WG,

                      

                      In section 2.1 of RFC 7009, it says:

                      

                      =A0=A0 "The authorization server first validates=
 the
                      client
                      credentials (in

                      =A0=A0 case of a confidential client) and then
                      verifies whether the
                      token

                      =A0=A0 was issued to the client making the revocation
                      request.=A0
                      If this

                      =A0=A0 validation fails, the request is refused and
                      the client is
                      informed

                      =A0=A0 of the error by the authorization server as
                      described below."

                    
                    

                    The only error described below is
                      "unsupported_token_type"
                      which doesn't seem appropriate here. The errors i=
n
                    http://tool=
s.ietf.org/html/rfc6749#section-5.2
                      are referenced too and, while "invalid_client&qu=
ot;
                      seems right for
                      failed client authentication, what's the intended
                      way that the "request
                      is refused and the client is informed of the
                      error" when the the token
                      was not issued to the client making the revocation
                      request? None of the
                      defined error codes seem to fit.

                    
                    

                    Furthermore, wouldn't it be better=
 to
                      go ahead and just
                      revoke a token in the case it's presented by the
                      wrong client? I seem to
                      recall some discussion around this when 7009 was
                      just a baby draft-ietf-oauth-revocation
                      and, while I don't recall the outcome, I was
                      surprised to look at the RFC
                      again and see the text that is there.

                    
                    

                    These questions came to me by way of
                      a developer working
                      on implementing the RFC. I didn't have good
                      answers, beyond the prognostication
                      herein, so I thought I'd take the questions to th=
e
                      WG list and the document
                      authors.

                    
                    

                    Thanks for any clarification,
                    

                    Brian
                    

                    

                    ______________________________________=
_________

                        OAuth mailing list

                        OAuth@ietf.org

                      https://www.ietf.org/mailman/lis=
tinfo/oauth

                      
                    

                    

                    _______________________________________________

                    OAuth mailing list

                    OAu=
th@ietf.org

                    https://www.ietf.org/mailman/listinfo/oauth

                    

                  

                

              

            

          

        

        

      

      

      

      

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


    

    

    
-- 

      3D"George
  






--001a11c3923e66ff1004f1d67114--
--001a11c3923e66ff1304f1d67115
Content-Type: image/png; name=XeC
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: 6d6535b058936589_0.1.1

iVBORw0KGgoAAAANSUhEUgAAAWcAAABxEAYAAABZ0L78AAAABmJLR0TIyMjIyMhnRJJpAAAACXBI
WXMAAABIAAAASABGyWs+AACAAElEQVR42uzddYAUV77w/W9VtY67MoO7u7u7BQ0SHEIgBBJcQkKA
QPAkaAIJrgkOwd01yOAMzDDDuLV31Xn/uJedfXZvns1u2Jv73Lc//wxdXfWrc6rrNL86deq0dPHi
xYsXLwqBh4eHh4eHh4eHh8dv0r35R82aNWvWrPlnF8fDw8PDw8PDw8Pjf5ZLly5dunQJ5D+7IB4e
Hh4eHh4eHh7/L/Akzh4eHh4eHh4eHh6/gydx9vDw8PDw8PDw8PgdPImzh4eHh4eHh4eHx+/gSZw9
PDw8PDw8PDw8fgfdHw1gszkcdvt/vpABJzpSQApnu9QQxBgpQgoAba+rhDMCiLMUs60FUcbSLb0C
2Gu9TnnhA/rVQYEBh8FoDbkSPQPcncwHzedB+ZhzxiMgfUsmW0FdKBfXvwTpgPXnrC/B1cmWkTMU
jGdCr8T+AGKsPd6SAs73n+y/NRPESrmhshe44/5GHQLay9zlWYtB3S+NVjqBZlXvmwuB7b3sua54
sA7PLZO9D6zF8qJzh4E1xd5fzQGLrzPTfgEsT20xuevAMcgx2dYL9E981wbYQRrvGxaQAZakrBPZ
2ZD3TTZpPcHdWVotVwRRjc66aqDN8P4+KAbs+6xW62FQAk1FzHcge2KmV+bX4HUy7FZUNmiJyo8+
z8Hs4x3ruw2EicfGSqBfZtwg7wP1c3cD7ReoObj2u+UbQ02pUvHIp6CVdi9w3wFprWhHNIhAKVRc
AKkJZkJAWHHjBkD6Pz5Ihf+YkvAOEjIQxCd8ArovpEXKIHh5Jfl++jrYv+5Ux4trQRj1T92joffk
pjMbNQHXRHmRFA3aTjETb/B/6v21sQDIi6VAeRforph6mI/CsenHU/Y3hKwCNrvaHh4lpSy8sBh8
XofOzOsNjvtJXsqvcD/uVZmna0C6omtv3wA5zdKmicuQMyhvrN8n4HtD96XhNoQuCUwpeBVKbC+c
W2Yt2Lo7xusWQHpkSrA1HGIbh38jhoHtYzXXMgkKHfSyRteAgP4FP42eDtZmtsfpn0FAoFen4D1w
oUncp3u3g+0btVtaExgY1XLQ9C/A+YPcXXkfym0s8X74Bnj46ZNluRVg/5gLx5bMhBw/m+VqD/Dp
II/yD4DUuymV/Hxh7p1Jsctn/NnN3MPDw8PDw+NteHs9zjICDciWTAQAddDEOZAWi1dCBWmEuCH7
A3b9JnEeXPfTFyW3AGOQXwGfc6AFau9r1YCmulLmr0B/TlZ9ToMWIOLUpSAsYrorGJSrUpSoA5z1
eRnYBQyf+yYGvwfaJPd7zvPAMVFPqwZCdm93NAGXX0pA/C5Q37e+l9kJ1BGu5vaPQMzNTsmdCM7h
2QczroF0XnmizgSRpLsq9wBlleG2YRgYGpiy9fPA2+V91XwAzIfNK72qgeF93Xj9C1C83RnOD0Dv
EoprBJhWmy7oS4LyjhQhh4C83n3cHQRaJVdlezFQuqgfOOqBPpkJ7hAw9dZ31SaCMd3L7rMWpFHO
uo7u4DvM+5B5Eoi9anlXcwhZGdYt6BR4L/E7GGECnY9ep78JD0fE5T0/BJYplip2DeR3lXHiV9AG
Sp9JYSDNZTsRIJKlYCwAiL9Jmf+DCgigmBSOAKkWdaV14GojXrifQIGZkb4B9aG/pUP3Zvuhwb6K
qWW/g5CfQggywoUh1/S3P4X7w5+2uVMNcmIyB1kCgGvyArkLGDozVloG5sa+r6JGgxKhlHboIOx1
wFc2C9iVHKH3hmp9S25p3xoC8qSkosch+1D6nuAM8B/mVT24AhTuENy96Epw5TqLFZMg52yulcdw
t8gz5ZYeCs+PrOvTFoo4oyzlKsD1SfcOZI2C147MjVnTQbdHGvmyHvhslWu4voFXNVP2P/4ebpS/
W+unmaB9Y2kTWBgiIr0add4MuhbGvrrB4HPSPFoXCymulG+ynsOvHz3xP3IJsptn931wDNxtcjPy
8iDjdtLorMJgHW1/7j72ZzdvDw8PDw8Pj7fpD/c4/4ULCQFSYWGXQkBc4JFYBFo96bb4HOTK+sXK
GVC3WRJtlYHL8neGWSDPNnTQzQFlgjJMvQjittxH1AJtkNxfKwNShFihGwMiUBMuPUhjXPMtQ0Eq
rZ/kNRjUz8XHbhto5RIbPqgBWrLjpmszSL/K83RrwHDae1jgFHDtt5yxpIJ0yl1ISQB3oKuvazy4
P3I0dHwKapTSQtQDw3x9K70XGDb7mH3rgRxrH+GcDiiOW/a24DNPai2dAOmsbJOMoM5xT3SUBv0D
+SJB4Nwij9EGgHmMl9kcB4zLLWD5GdTK2hRtOojFdnNub5DWayHKUnCpFlPOJ+Bd1DDQezmg4HB/
ANpx2/qMzwGDfFkfC7ahefLrGqBf5HUgNAj8U4KKBs6E7NuZ9syF8Gzsi08zQ6DS0TItw/3B/dw9
WAPoL3/AXEAT6dJCQEIW8fxHkvx/JtASBkAT8VwG8UAqx08g3RXLFAtoeWojbRbYHlFLewHF7YVG
x5ghqXv6gZSyULNn+R3FukJEr6D08BSwa+p+92nI+iXnjvMruDc6vfCTHyDjS/tPL0vDzcvx0Xc7
QdrXlqQ0X1Dv5s7NTQe/cH2xm5mgTwtY71oDjRcX7lShBrjLa4XkJDj94e3Tj0wgb9Z9H1YZpDKk
GBOh0abKZZv8DJXnFPKt+gpybkcfTjoPDT6vLXXvBXc/i3v9+BU8bHzPsvUlPA12rHVegKzn+uCn
Q8F3DqppBlQvXu5co+oQ+FF0WmA8BLYJDvTtDBmLXg/L/hjSVmcbxTJ4surh+8lVQTTUDpkngr1u
dlbMF+BOUv1ykyCrNNdffgRAgz+7kXt4eHh4eHi8HW8vcZb5j2QsgBxMwD6pGU9B11KMpCe4Q7Wr
LgMoy8VpcQ2UG0UrFM8D9Ssxz3UTlBOuXtnvgvhYP8DkD/JTLU10AVFbbqvrC1J/OZFZoCXkTc5U
QLtg7ZjSCXS79ZW98sD+Qo0XI0Hrmzo8sTm482zz7FnAFGmZcg3kfkpTjgIxhrG+t0F3TzqiLwu+
u3w+VIqAs51zl9QdXIW1EWpncC9Qi+ELhjVimzEd3H21QeIGaA5CpcngU8ynqq4POHJsy3O+Bfmq
a7s7DbxLKXvlpyDfNl82RoNcSM2USoK0ylHT1Qhsu1wt7UWBjVIfpSU4JuXpLbdAn6pXcw8At7zO
hJQHY3d379yh4DrqeMETyHbnvpveHbyrBA9I/xz0ZSK0UgfBd47/+oCf4d6Sh4mJraHUsiJbQ0qC
7nOdj+gA6iTxgWwEua7kLX4BcVtYUQAFCe3/+AQFLkDgT2FguqgnXoDcTFYYBHnxeZPsNeHS5BuV
b3SFpDJZpxLuQF6dvFdaJ6jyuuL7JSeBqadXw5BweL4oqffT3vCdbf8P23aDrppuv3ULuCfrv07r
C0V/De4TkwJ3v3h6128hOHe7C9tegO+15Bp3KkFUaGCb0p9C1lFHi3Q/KDwuaGnDb+DlyNe1DkyF
d9c0d7foDX5pjk2GsVA2trR3kZUQVyIx/aEfvExO3BOfCZab9u8sveCZ7XWRw5fAvVbMVY5BYDlb
WtIFEBtt6yI/h9J1y8SUXw4hwSEj/U6D9y86zfYQktclXk3TQfLmrGUvjsELOSnqyRcQEh9xkV8h
e8XTiIxVwH69QzoI2aWzThi7gHzbr7P3BKAGY/7sRu7h4eHh4eHxdrzdxFkG8Ri3eAVSOaJJA2Fn
mhwG8gf0kuaCqOLT07wNpIsc0k8EeZBsk5wgPzS0jQoGKQi9LgfELPzZBpJbHBG7QRtnTUhdADzR
hfgGgHzR62LQl6AG5nR7OQwki1RdrQuKGlQ+cgZoPyRZnmeD1szdWJ0Eyh1vW1g8cMOkel0HkWH9
Vh0Porz6qbwQDDbphRYHUpSWqyWDlOco5LaAu4A8zLUUlIZKBTkTdAc1qzIFpOfikZgNQlJm6EcA
p6gtWoM5U3TW2oCaRDe5FMi9zQ9Nd0Ceq3yr8wHctghRB2zt3O3UGaClSuuVT8GeZAm1zwXDSdzZ
q0FZp/uYZ2B+Ynhs7goZMZmrLEVA9z3PtXWQY5O6GKPBLzj0cawEecNsbd2X4KU+Qc6YDcXbFB8Q
WgnUNMcvajiIJ9J8AgE78F/9wLoEaICKJhUGaRefi5UgDms9xXdgPmpaaDRBi9C6j2qtgUPNz+29
NRJ2HDy7aus+OMydxae6Q81rxUaU3gi65pLqb4OYkf6FI45B2Z1FaldaCqnFrF+8uASv5PTQX2pB
aIPAl64i4DwvNbItgcA65lHm90Hxzb2TnQZxJ14Pc/cBi7etzKmbUHZpgYKRdyBhd8alu+kw6GS7
9/uGwapjm/Q/h0FaL/uaBwOhTnzJUp1Hw6OPn6XfvQd5FcU+78MQPdinn+4S2JvmVPV+CaW9ix2p
9gtUXlbQVHIVmH8w6ryt8HpJcs3Mp/C8ZPLu6zth/7VrE3fth7D7/jpXOWh4omhIy2kQlRL4SR0L
GH8xlZZqQPbLwB6WlfC6ovVMQq1/Q4utQhWqwKHZh2Yfmg3bArcFbguER40fNX7UGNTl6nJ1ORT9
suiXRb+EDvs67OuwD7qkdUnrkgZKDaWGUuPfUC6P/6tq1apVq1btn99uUotJLSa1gK6zu87uOvvv
4xw9evTo0aMQEBAQEBDwx8v5ZNuTbU+25b8uVKhQoUKF3v558++uh4eHh8e/y9tLnAUCGTBKYaSB
SBAPpY+AI8wWn4DUVzkn1wAmSJP8QkG7onbJ2whKnlRXqQ2MkuqZRoJ4JtKkGUBz6TSrQNyWNmhn
QYowHPGuDnygbDEVB+2S8/Ocn4A5Wqj4AOSC/iLYG2RLpLc5HeSVerd8ClhvmuG9BqSz8kZzKXB/
mfW5ZSGIQQ4fRyOQBhjjlSSQVMcRdxgovzhs6gZwRDpjXL6guhxXnR8CC9RNogLoJkmlFDNIn+sm
SL1A6muy+vQBkSY6aM/A3VANd2eDeaV6VLaC+6a+sDIflPm6C+o9kA9LTSQ9aOWt3Rx9QH3k3MVO
MH6syzNPADXOVcUxEnK35o5IbwZm1WdwQEPwn+vv8t4KedNyOmV+BpRIC38+GhzTjFWMvmB47h8T
vRker3oRnf4dFDlZZHdoBEg/SFdFVeCyiJPLA+WQxAvACx0BgB0nNkCgYQIpStKjgTggbiOAGPrL
90CpqntfzALXTlcB568QPMhfUitDY5+KjWLXguVDw/Inx0BXWzsaNwqkJtmplTKh6oBy22pWgh8i
fmnx0xUI/zB8gKk61BxZ5oN6Q6DN5+VOFZgND4tkT3yVAjvfO3zh+2pgGKfcSCkOtiZqsP8MuJn0
0DvoHgT0NKT7r4Q476fSpT2wrMfmDQYnhPQwdJKngK1/1vPgHaCWUkT6CYh6FbS66DHIG2Q5G3sI
LLKlwbkWYOrgJUt14Xqhhy0uroVHdeMNcSVAbmnO8jJD4vXXN5PWQWS695Pg+1A+LehAs6vgXzSk
ckI/CHQV6FBqEWjNdKVSnoG1vbraEgD6MLH7/mZIK5eWmHwegOJvs8HOOzHvxLwTsK3ptqbbmuYv
17v1br2bvyTW973ue933gvvd73e/3x2uNbvW7FozmDt87vC5w4HrXOf6W/428fjdwqaFTQubBsoI
ZYQy4rfX8xrjNcZrzH9fuXrM6zGvx7z8139JaAkg4M86WB4eHh7/g7y9xBn+oydTLwQ+QCZPuQk8
xyJWAuWJkMwgwrUMbQxoC9y+1lEgTZAPmC0gzTDu5yuQForF6jwQGYSKYBAGubKuCkjVbL1z8sAt
09JqBGWW1yj/fiC1Cbjo3xt01+Rucn8QG9wztM0g7SxaJaIsSKV1pXSFgZ7qOrcFlOoyiXXBcdg1
K+0dcEVm98+NA3ea5aA7GGzVbNfsfcG6zPaN9QW4A9wZIhekZdI2XUtQlshn5PlgrG+oZBwAoqyh
jzQQHONdqa61IB1W57jrgFpBK6GEgVRb6yQagOyUHrgbg3uoc4QigbefyW50gHuLY5NjJ2iH3IVc
v4K8XTdTPx/s8fbv1CPg0Iuw3FJgOu6XqXsFxrL6X3WTQPF1KY4t4BiSOSHxCfhc8Z8btBVsJ201
TGUg54vc8/YM8Mv2TTTcAnWnOlO8BBrhpC6IImK69j1IVmmj9Bw4Li2R8kBkESnuABq3KA6cpZl7
BGinRbxyAuRzrDYWhfTOrzOzLeBfQp7lNID6jtQwKxcyIrJUKoKqzx55NxMO5F45+fAcmF6a5LS6
YHigz4goBJklcueYJ8KpNin7bBmQvDj9y5s7IDXX1T7NDGrHvE+FD5juazUyaoN23j44+QaIW6G9
wipChbTogbXmgvOEbad7PWR3kd2ujlDoUNSgOsPhYfDD3Yk/QkR48JLAppAyMHd+xlhIrW6JSGsF
hm7WI85pUL1dmR5NTOB4lJsU7AOv47Jbx/WAKQ17mgb6g66tfqL5A3jpSm2VUwHiDM+PHDkFv5y/
OHHzRWj2RbWu7wwHv68dx8IewdF6V6ZfrwW5C7WX3t8Bu/jqbTStkydPnjx5ErZ9vO3jbR+DsY6x
jrEOzEickTgjEZp+2/Tbpt+CdFY6K52FU9mnsk9lw7TwaeHTwvMToDO2M7YzNqhPfer/93zHePwX
NjXc1HBTQwh4FfAq4NWfXRoPDw8Pj9/rbc7jLP3nrX6LVBDwksqJ7oCZu9IXIL2gtDIA1HDn9PQ6
wDCLKed9kAWZuqOg9aOVHAnSKTGMrwAvab9yGChi751zH0jQ2cxPQFnp7RvYCaR6usnGPiAdpqmi
glZAy3NdBvWJ/Np5D+QN2mk2AOucs5zjQVQl0PU9uMIcL6xxINUQ99QpoIvR3TY0A/uVvF6WXMiu
l56TNR8cmmWMUwNxT80Rt0E3Xs5UKoCXn+FXcyp4v28Y4lUc9K2kXnIiaBfFDeYB/ZUN+l9AF2aI
MBUB2knvyfPAPcud5XoH9B/oz8q/gLGx0aQ0A5/x5iTvu6D/RSlsCAKxUp2nNgT9HmWVHADaFrfD
oQeHj8UrzQ6yS77hNoO2X2qsHQb7+pxemQch43ZC8Xu7QM1xbrbtgrzPLfedz0DaKGVLrUBbIs6p
F0D3k5KobACzwTDaqwYoc2STcSmwSYRIXiCVF3OlvcBJ2mEFBolw+SNgkTRMGgDZVXP3ZSaA+Zy5
Bn6QW0gvUoyQNcxpyjgPzzNeHU5cDO458iRrX8j8wlU8+SwUXB8wNGY3uKdaK/lLcO/d+F+vhcKh
p9dbr/8IXkxP3fqkMDQtW3xd4/fBEC2Z/TuD9KthutYITFn+LfVG8K3B2GqHwX2aqtlJkDvFNfXR
aXj+dVKrlGhoVLWSJeIylDwXUDRUBt0h5Z2bUyE6POiy4RgYxzm8g0dBu5J1slp6wVjfwYWHLIbg
V2Hf+ayEppNrFqqyDySnz2oxFg70u3h0/0b4+cSx5t/8CA+KvDC9XAVFZodXDz4Mj7Y/fH7qFCTb
k7++2Rhq3CoxuXRrKHQ0aOOLJ2+vcW3ZsmXLli35r4cPHz58+HBosbPFzhY782+lyyPkEfIIaPyo
8aPGj2DCtgnbJmyD1mGtw1qHQd6pvFN5p/4+fuKexD2Je2DcpnGbxm2C+vfr369/H+p71feq7wWf
NPmkySdNIKl9Uvuk9v9FAf+zp/tNT3inTp06deoEtWrVqlWrFnT8rONnHT+DreO3jt86Pn/9N7Ky
srKysvJv4b/5e7/+/fr360O3zG6Z3TJh/b3199bf+/v9btiwYcOGDfnHo3lQ86DmQXCi+IniJ4r/
fdw3+3tr9f8f4p+th3pZvaxe/u2hJM2aNWvWrBncMdwx3DH8/XHfPX339N3ToVuRbkW6Fcn/vJs/
a/6s+TOYf3z+8fnHwV7GXsZe5rfLfUO+Id+Q/z7OwEsDLw28BM+aP2v+rPkfr+8fPt88PDz+f+/t
9Ti/GSObA4SBVA8H24Fh9BSdQe0itZIXgAyPWQTqrZSnj1+C9tycHdYNZG/TF1I50OpTiTLAAHFd
GgBSNX0nb0DyNuyTeoL0UPtMew44tCB1O4im8gldQcBLOyf1A6kDVZX7QLJcRcoCRohRuiHAh6pL
Gw7SZp/+QTtAPzggK9wB4j3RX90EgeND24ZtA/OM9FZZMaAdtC23dQI5WZpMFlDCmWjfDbq2cjFl
Ddi93bHCB/LGOTq4GgPXXVXdgeDeqI11xoHLqV5SqwGPxSb1GCjlmco7IH2p/GhoDIY9tNFWABZz
KFHg7uk8py8C9KGhKQuclV3fO+eCNleMdpYH903nYlsYaD+4Lrn9QTquK2EoA8Zu5iy/M2B/lFky
pR9YXmYUT/SC7K9zEqP6QqHCBZoHjwTlJpP0n8GLW1kBCVvA2tnaJuEJBFz2uuQ/F0Km+lYo9jO4
u7PHHQZSOZEoFwWENJJ+INXTQlkChhomnSEQYpdHJBXzAcs34oh4D5Kvxf3yYgiEFgpYaSsEhsbe
/VI1yAnJmGgPgAsLHw5K3Q7Gocaa2U/Au4TS1vsVmM9oU/RfQUhr0+kq74L4QJkt6SFor1evoK/A
a7eSFXMY1OvuHOMyqLKwSpnSD0GJkjYUOgdnBp4rfW4SdPapltyiO5RtWe1wqZ/hmeXl+ZxhkGZ9
UUH4Q8Dp8F+iJ4JfuNfhh04wDDcN9Vbhhwc7XPtPwp0N8bUvHYSslOx5AVtgbbv9WdsKQmBAYGff
3lA8O7aN/0jQhufV1Jxgbua1L+Ip6Pbrrzoy4JfYy62OVgZzcoDsvxjMNXVrAxv+8WYlhoghYgjc
+uHWD7d+ACpQgQr5ieE/0j6qfVT7KGh/oP2B9gf+/n3rIusi6yIYdmzYsWHHIDk5OTk5GeqOrju6
7mhwlnOWc5aDEzknck7k5A8B2ZK3JW9LHvj4+Pj4+MD2Hdt3bN8B87rP6z6vO+gX6xfrF0MVrYpW
RctPjOYPmD9g/gCQd8g75B3QjW50+7+Uf/y28dvGb4Ok5knNk5oDP/IjP+a/vzdpb9LeJFi8ePHi
xYvzLyCKxBeJLxIPM/bM2DNjD7CIRSz699X/n/Xee++99957vz12uFSpUqVKlYIvunzR5Ysu/zje
v1qPjcU2FttYDAp2KdilYBeI3xW/K35XftwCBQoUKFAADA0NDQ1/dT7/9PNPP//0c375DDMMMwwz
oKpaVa2qwtOaT2s+rQlbY7fGbo2F3CO5R3KPwGd8xmf/RfmnTp06depUiCKKKPIvAG+PvD3y9kj4
zPmZ8zMnrGUta9/C5/avnm8eHh4eb6/HWQMkkArgJg/EtxSkLYgazJe2gPwuYe6LIK+Vd5tvgHO+
tbB1EohrqskVBHJP6bFUFcRmkjgIREtVxVSQjsrPlEcgHovK4mfQmmrfaXuB+aRJeSBZuEoGUFeu
oysMUlFpqSEKtERtkKSBVF6U0MJBCZKijWNAmRm4xrsNUMYrUH0P5Cp+dQ0OMGthJ0zRYJ5nXute
Dr6jg/sqqWB86POVVhzsDV2jLUMhc2JmhdTDYHmaPfF1N1BfisKugqCtYLM6AlxLHENdX4L7M/Wm
6A/OQcIklQPxqVxM7gbKDXmlbimYvzJuNbSDgM982nuPA//Tful+48HU0ljd7AuGEX6Fg34CbY22
QnoN8g5RinjQrZbv4gViubuHUwdqZcf3uXnAJ8qHpvqQ9WuS/tEgSN+VXi+jBjxLebk6eTEcmfLr
u9+1hA0nD/dfshGWfL/l8PeX4Ydjx6ZsrQgvBqaMSU4B/T6xUfctqHmiv/QpaG20FIqBqb7usq48
nAm9lX2lL9yomtDrYVtgmjtT+Rm8w5TRASvB7Otd1PgxGArrIxUbpE/NXJ92DJQdyjTDIfCerG9U
oCtYp1qmeQ+HyCyTFLMJArf4TdHHg/Erc+e8U9B2SY3x1fqBGsZ16w0oe6hY34AOcLzB2bBrR+DQ
kcvvnz0JdWdU+LHnFTgz8Fbh1x/Dms/XHTg4Dp4Hxk+MGw/GUGNDH19Qy8rfODZD1cUlR7WeAmkZ
zxfkqXAh70bbs82gQXqVvKIHIWh0sLv4IjD3N+50zgJLRVuvzEHwZPqz0YlTIM6W1u1BKJy7dv/6
zpNwceRz96654IgWpdTT4BpgK5x5FZ4vSNYrv/zxZmVZZFlkWQSuCq4Krgr5y0NCQkJCQv5+/YWW
hZaFlvyHyf7279dff/3111/nr38w9WDqwdT8xOOdd9555513YEm/Jf2W9IPll5dfXn45f/mb9fZ/
tv+z/X+VAa2/v/7++vv5r98MIfm24rcVv60I08Onh08Pz39/U6NNjTY1+sf1r/dhvQ/rfQh72u5p
u6ctdD3c9XDXw/nv/3jvx3s//lWP4JsEbLPvZt/NvjBUDBVDxW/Hf1v1/2clJCQkJCTkJ6p/+/fN
fn6vf7Ueh+YemntoLuycvHPyzsl/H3fdunXr1q2DEgtKLCix4K+Oe70f6/1YL//1zPYz289sD98M
/GbgNwPz7wDob+tv62/D4S8Of3H4C7Db7fa//GDWX3nzEOT2p9ufbn8KS8suLbu0bP779+rdq3fv
r/b37/rc/tH55uHh4fF2xzjLgBtFPAVCyMQOKOwmE8Qz7Yi6BMQ0Md3ZEQyz/GaEDQLlU6WtXB7E
QtFXfAxSipQhVwEGiTvCDuKpeCC6A1dpKp8GOUSxEwzMYZ0YDNjFE60SEI1QBoNUVNQXLYH78nvq
WNC6UF7eBtJyeoqRQIOsEokaWLWnPe/eB6c1c312fbDUf9ku7QPQWusivX1B+9KU6X0OrO/mtlWX
gTinjTEUBNmg62FMANdwtZrzJZAlXbP7gOsUYUpdkE4F6H36Qdr5XMmaB7mROVnpg8H+Re7ynKPg
+5lpoNdYkKrIC+WSYApUlujeAbm77pTSGPSy+ot7Gth76p36wuDeytfiOhjXu2c5WwG1lLJEg4hx
v5A7g+O284F1PJg+0s83xoISr2UYd0LeqKxjuZth64r9z84fhztXMq6uqQVeJw01iv4KSk91bmxr
uNH7bvlLn4B1rD3P8Q1M2Ndj8MyiYGgnj1G6gtJC11NbB/dKJaY8mgW6ccaSGYkguzXfrO1wZ/bz
9TduQOpFu3fqAghvpfMNjAP7xLzJ1mNg/NbntnEVBOR67XLNBK/a6n79ZnCc0x2wfwKmk2EOaQAY
ZpkmqgmQ7G05nFgFchLcqa9eQA2fYmrr3eC9XrfX6xzU7li+293DcLXLrwdsN6DqxBoFDQ3A2Y/J
JUMgwNe0J8Ufis8vV6JmJux5duzp+qag+4TotATIft/wuIkRXD1tv4rXUOhCeP0i1SDeN/G4tTec
SXpY6roX+IeYTxungeOqrXDqdNAOqDMN08C/p88hS0Nwl8uc4f4Q0pe5jKbp4Lqom6odhazOjvOZ
5SCvoLW8sRUAWX+kSZnvme+Z74G0Wlotrc7vgc7sltktsxuE/hT6U+hP+eunxabFpsVCfOH4wvGF
/z5eWru0dmnt8l/f/eHuD3d/ACKJJBJ27NixY8eO/L+/5c12tiRbki0JXt1/df/VXyXOjcY2Gtto
LNCKVrSChhsbbmy4Mf/9l2Evw16G/XYi9cbI70d+P/L7v+/ZfbPd397Cbzah2YRmE4D1rGd9fo/7
Yhaz+P9Sj3+1/sxjHvP4p73tWST+u+rxZsjFm8/vjdqG2obafzWUI7hFcIvgFnDBecF5wfmP49b5
tc6vdX4F2tGOdlCse7HuxboDQQQRlD+k5G3Vt+XklpNb/hcXCr91vnl4eHi88TanoxPIIJ5JESSC
9Kn4VuoBoqDUXmwGLYomcgJIn2vFrUkgjwy6Gx0Iak/RUt0HuuFsZSGIU2TjAg6QKh6CtIMJUhqI
9ySj0IGIooEcDBQTA7XZIK2iGg+AOBaL/UBleRkLQZSyz8vdDlzXv/AuDLKqDJH7Qm6RJ8GPykCK
7kSvC/5gW+80iWVgX2n42TwW3L/IP9oagUFVfC0xYDro/VGgP8h19KOlOSAFSDrtOSguqZnuErjX
qN8bvgFTYb9vzV9DZowtMasX6ErnDc0eABELjdfNZ8FWwf2BKADSD0ph3SXQnotQEsA6yOKdVxXs
3bMbZE+F3FG5X6Y9AdtCr42+7cDxjru7+zmIwS5dXk/wOmuM8n8OIlaUVweCbjY+fArG0Y5HVkBp
LS9xBYKuiL1f3hcQXNivcGgt0I1+9bBcMyBd65b6FUS8G2p0jwfXdePHLz+EZ5sf1LXHwNfr18/7
oTkMOt5lV5eykNwq6X7OKrgWkRR+MwqOfffMZ84j8NsilgUVhsx7aU0cQ0FpqNyV50FCqDRQaQ2m
NF1NcycodbrkV+bLkNUoda/rZzBeCJ2eGwel64iCqi+8eiepzqv5YEyS9uqDwXeYj7nAM3CqtqvK
HWi2pH5Wo50QMMMnOLAwvLqZsT70GZScX6Cdbie80r88ZxkJTc/WTi20CR5EPegnn4eKY2vMLvUZ
WFc7vnq3PlztHjfh5TQIrBxy2W82PNbiZl2NglZbm63ptxQONrgy8E44NKxUtJTeDg8/Tyh5vz94
TTOP890Pyn5d+kMZQjvoN1saQUo3XUnfa6ANE5O9w0FapV7P2w2yW1nCFghuZ9oq6gBn/lizenMr
v/S50udKn4N73OMesG/mvpn7ZsIABjDgr9afnT47fXY6zGY2s4F9+/bt27cPPv30008//fTv49vP
28/bzwNd6UpXCJoUNCloEvg+8H3g++C3y2VaaVppWvn76yFdl65L/9UsHm/GOp/nPOf//u3fSmC0
5dpybfl/sXyINkQb8lfHb7gyXBkO+OGH359X/3+3/656iKqiqqgK3Oc+f3WhpNPpdLo/8L/Jm6EZ
f/Fm1pdmNKPZf199PQmzh4fHP/I2p6OTEECgSCcI+BmZOOC2iJbagRTEV1pxkFuaKwZ/D2K3XDjv
OLBIVGAvoNdmEAk8ZBIHQYwmQEhASyLkxSB9r83RDoE4JYzaUKCjMlbuCyJJtJUSQVrIKW0IiA+U
GOMzEBOsiVnXQOuf1zu+Pkg/+A7zfQ7Wx9fu3wgFscO3kl8/cKao2/X7wXo6vVW2FSSH1DevGTiX
CsWyA7J0WTVSd4Fuhfy9NBF0D5QbBm+QAuX5us/Ba5bv84BNoMy0tgyQwbQiLzpnIAR/Zy5hHA7u
MF0L/UZQQuROyiGgr2uSqycYhsux0iwIPmS45V8S3FHep429wXra+X3gL5C+yl5GfwNSvnHNtkWD
vXha/9wjoH3jdjjqgylZumy6CIY10jmxHbxuy+WU8mBs6nI7okFdcq/P1cHg6yg1vcQp8NscOdX1
HqTMz57t8Abnqew+eVGQ2yxJX/QylOkRU6/5YAj/zrdcgQ2wb+Wx1cc6Q+pV6Svbd/AsMWn6hTkQ
dNNviHEZFPoyqIGvBZ67tVdSLDgtbo1tUJzQs1VOwoUVcQsv+EHCs4x71nkQsUBfL+ArCBsZtdr8
ERgXyA3qfQN8oqxJrgMJ47NrPGoCBQO8jkVPhvIzI4y1zkPC+le1Eq/ArUlZS19Ug2cfJtVJXQsF
pxSODOkKJX6IORVyDQKLB8oBGyGwatBa6wcgWsnddClQqGvpHwv1h7QPLB/JydDxZZvWFWbDoQn7
CiqPwJhsmmkbAfUCqw0qvga8LiubXT9BmQqlLoZ2A4fkOG8IhuPiUsvns8GxQm5j7g36r4x9pEeg
K+0clzsYwp/7NQqS4GWsvWLiNSi0zO+s/38MTWj5NppXj2M9jvU4BjOYwQxgVbVV1VZVg8BtgdsC
t0G76e2mt5uen4BccF1wXXDB4j2L9yze89txC3Up1KVQF0BCQoLOMZ1jOsfAiK4juo7omr/ew3EP
xz0cB8+fP3/+/DkUnFNwTsE5YO5t7m3uDZFJkUmRSfkPYZ1ceHLhyYV/6XDm5IKTC04uANrQhjYQ
3SG6Q3QHME03TTdNB3uWPcue9fuPh9d6r/Ve6yE0ITQhNAFSY1NjU2PheI/jPY73gPZJ7ZPaJ8HB
QwcPHTwEdKc73d9+/f+n+HfV480dDrazne1gvmu+a74LEVERURFR+UMg3sz60qpVq1atWuXf+ejY
qWOnjp3y4x3vebzn8Z7/c+vr4eHh8Y+83aEaABIqEuCSwtADu4REIZDtfKdrA2KoNNKrPiibDYuU
lSAeCh/1c1D7kqveBemRtELbCnItsUP5CNgsMqRsEKWUrVptkD8UNdyzQJuv9pbtIDeTP5b0oJ0T
E3RrQZmurXGdAVcD0VwNgDz/qzUvfQyijpjjOgHKlKgxoT6QUzD+Zno5SL2Skpd5CdR+7qeOXyBv
Qtqx1Cnw9MPUPTmvIWe/bqWhEyj7jY28C0LIM/l9YzwUCDEX9eoBunJmKWcmyKd0iS/bg392wAQ5
BOzjxTD3GpAa6if41gZDReNKn13geKj1ohuoreSGxo1g6GQ8aZwK8gW9QW8CKVxncn4NhgS/B4Zy
YGokfRw8AZJy1KWWbqBVdUiZ88H7sqGaSAdzTVFZqg7m1/IitR8oH8hz9NtAqnmnaNx5CDoQUMY1
FPzejX2QcB7iE5LuvfoIcucY62V8BuULlz7QqTb4T7UFFrsHv/omDr3/NaRkZ3W8Oh4M/qFq8m6Q
T0kfO3dDYG3fo74B4Hxg2yA9A//Bhm3+6ZCb5pwrnBCSbT5pKAqRI7x3RauQ/CjeELMaDFVDVtg2
QPbcxDOPf4bYIaHBIXHQq1ezZ71aweHHVxdsLgrPJ+Usf3QOki84SmctgrsDcuIv/Qi5uTlfG3dD
UGW/b63V4dQHxycn9IXsHyvvcKdDJ//m3SP1ELIu+J7vp3Bq4IUf7z+Hlg+aSOX94Nmsp51ed4G0
+RkXc6aArqwhQtsGAT0Cy/ilg9fx4EWKN2Q8Sc60BcI1x9WJtxvDs++y2z0WEDhKfzz0A7AcdG18
ooDPQV2KfRI4G4kvFBnydjq7ZlUG3wJax9B3IPeiMkhEAZXeTrNq+3Pbn9v+DJf2Xtp7aS8c6Hig
44GOMGvWrFmzZsFcr7lec71A9pK9ZC9wLnMucy7Lf8jsLz2xf9NT2GF/h/0d9sOGYxuObTgG3+u/
13+vh0fej7wfeef3JL6Zxo5rXOMarK25tubamkBvetMb+pXpV6ZfGfiy6JdFvywKM6NnRs+Mhj23
9tzacyv/4cA3+tn72fvZ/7lj8H/4zx7Jrmu6rum6BlasWLFixQqY1XlW51mdYVOJTSU2lYBnQc+C
nv1fHqJ8W/X/s72teryZ5tBx3nHecR4+n/X5rM9nwdiEsQljE6DA9QLXC1yHvuP7ju87HuYnz0+e
n5x/R2NP5J7IPZHwtMzTMk/L5Md5M8b+Tfw/vb6veIVnGkAPD49/wdtNnP9jOjoXJsCEt3gOwC4t
CdgqDacWUE7U0TQQ3lKclAqijLRGlwc0lyJFL5B2i4WcB3bJ8fIUUH/OGfJoMjg6PNtz0xvk8UGB
hd8DfbbpsUEF9y2bzv4u6L6PKFeqI2iy/lLwCdB1pJ5SGZxRrxdZG0HGw/RhL04A7pgn4d9Cwp6E
5JTu4PjOcUXbD2KsOOoOAfu3tmWYwK+yd/WA6VCofeHqRdMgOD7gUnQaeHc0fuVnAilel0MLcF3V
TllPg83XdjxLADcs4bnRkLs541gyYNT79TLGgTHBdFhuC7oHumJyC5BuyhN1P4J0hCJSS5BaipNS
VdD1VTeqx4BY7ZJ1DHg/9x4oTwHvIL9UP29wn8k7zjUwjBcRzqagX6DG2Y+A+bHjgHof9FO9OgQd
BRRlfuZB0C4/6Z9+HdJiXAXkJqBPNrT17gHKEktL90ZI6Gdac648EBp0yboavLZbqhTfDD5N/D/y
iYJijUxHG5yEJn7VblSbAy/LWxs/2Agbyx8vsW4DBHj5OEPPgb1S6lbpO7jdxOHy+Qq8C2jXa4yC
2q3qpj1IhZQCyceye0HewNyx7lx4uiNXf/4YqM2dx4xRUG9T6WeN+0Pk0kRHgfrgZ/RLCHkX0k0p
tsRB4HO+zIRoL8hpkjc8vgSY+puuWx6Be4EjPn0nbPl2d/Wj70EBQ0xMpC8UbxcVUGgBuBc4flZH
QTm1zJyoMfC09PPDr8+A92LfLw3FwVjQ3NI3EvRr3e1Fd8gW0gtnfTA8DChWZjS0kUuOq78ecrtm
1UuoBC+mpaq2b+C5nLMqzxdkbwbpp4LJkVfK8QNI/j4DcnPA7EWOKeIttq3/TBRnDpk5ZOYQqBxf
Ob5yPOyYtGPSjknwtPnT5k+bg9FkNBlN0HJny50td8KYgWMGjhkIY+PGxo2N+/uwERERERERsHLF
yhUrV8CSskvKLikLF7+9+O3Fb0G6Jl2TrkGVSlUqVakEI6QR0ggJSllLWUtZ8+N0K9ytcLfCoH6s
fqx+DJtebHqx6QVc239t/7X9+fvp86TPkz5PoOuhroe6HiJ/TMm/aECFARUGVIC8Pnl98vrkT4+W
fC35WvI1mOI9xXuKN8zsMLPDzA7/vvr/2d5WPYYylKHAmvVr1q9ZDxcvXrx48SJYb1tvW28DC1jA
AuhxtMfRHkdBfiY/k5/B5i2bt2zeAtdWXlt5bSUEVAmoElAF+s3oN6PfDBgxfMTwEcOBFrSgxZ9f
37+djtDDw8Pj95L+44tRiJo1a9asWfOfD2CzORx2O3+ZVQMvwA3cwoIEYjFe0mmQz/Gj9A7QhZnu
SNC+Vjc4MkCKl5vJLUEqJHsbewA3tEClPmjf6faJZqAuS71z6wRYR5waeuAliERdpH8vMJSOfBGW
BaJYzv20uSAP9F/j2wCM06q07uIDSn3pfV0HyI4/Pe1SC0jt82Jo/FJ4HJCge5QC2XMyX2gx4PxJ
/U5LBsWuBtsfguFH2WBoABGNgzYEfQGRI2PnRX8KbFU+1llB+1keJY0Cd0vynJFAZUew6xOQu+gb
63tCwKHYSwWLQuKhx6eefw3SJXmqPATETXmqaAX2Co4b9sUgYt0WdQlIHUU3uRZg1EzaDFDXO/ba
fgJtjvoVT8DxSJ6BBV4/t36SPRBsN7Pnp38O/uGGx1JJME9wdGUzmMZoZQxFQW/3v+8vQJDUKzcM
TDZ1qToEjo4u0/hlJsR9LW+/Vwn8BjjK+3wCWbvF8SwNMt9Xd6qnoPAUn6SaZ6Ckd7hS4RjIY/WT
rb+ArYYjQ78egtqb3hM94epPTyOuLofYRN9x1edDesbrUS+vg/6ht6tAYUjZku17uyAULhTexN0P
DJ/Kz4I+B26L4+54SF+f+SpjNIyu2n/01wVBv1pu7J0E8T6vVt9fDsdq3uq5Yz7oTzs3GDNALedc
Y+oJT1+8rpkhILJosK92CaRM02c+ZvB/V/dd0fOgfWNvo/SGGi0qFaw1GEJ8Aj/w7gmRFwvcDWgO
R2ynLj/4HrL6pZV5cR3qB9Y7Wf5LcAQ4C8lHQAnQrZGWQundxb6I6Qy7rIe2X2gF26KOF9p+DMK/
CwlwDIeM2VnVrfcgsqb+ouUYSGO0s0ICERXtl54NMReje/uWhIlK7++OfvNnN/P/fd70qK+surLq
yqr5y988HFj6TOkzpc/A9WHXh10fBkOvDb029Fr+UJZzZ8+dPXcW9Gv1a/Vr/+zaeHh4eHj8T3fp
0qVLly69zR5nBYEAsiQvZJDqiWtIIH3ONdaB1gmn8AX5DpvkTiBGaJHurqCUlcZ5ZYO2WTRTKgCD
Wag+Aqmb5i+mglTDeYLrwHKfQQV/ALE7JyVrBdg2PP8gaRRo05zt81aA1D+1U1Y66NJjzK/Og/RJ
zMvSZ8A7puruUovAfjA9NPlDCHnXb050XXCNMGiWXaC1tgtXKgQs964W8xOY7yrJagiYjKK0cIN1
ie1ZzkTQeevHGp+DfqNqV5eDb5bSS5QC0/shCaFPwbQn5kLhb0ApHjjJqx6I8lkbLech513bYeuv
YKvoWG93gu5babvuFKgFpA9FNtBackjjQZ4nt1YsINppI3UTQOyXBqtfgmGhkq20gqDPTeP9MiFv
rWN8Tl/QRbq+yzWButre36mAVt28yO8jEDjjcueBYvKdblgLyHkvxSegjcku510XAicE1PZOgMpZ
ZT+IjYPn0x5/VbwZJA9JLxnsD4qX2kBaC8nb7F2ye4HpuY9dCgd2y1OLrIEnWYm9bdegYAv5Vp3e
oNXL3aI7A+Jrd2zITlDP2o/nJENEXmCLSp3AFpSbld0RnHWkYKyg7qNP3mawfuv60G6B48lXp5ye
BOZH5kPhc+FK04fbfq4FFT4puDzKCcZI28CAWLjW83ZydldoeKCiaPwEUhvnVnocA1kHbCtuFQaf
675nQsZAiaqlg2s3h+J5JRZH/AzPLj+5m9gFTMOybhm/grw7iafib0LJa+VWR2eCa459imyGAt9G
3wxxwK1qN5XHFUC/z91LeIPpgVIobR/4fOa9O/EZ6A+ZKygTIeaK85jTDvZt3ltxgnGgLtE1AFwj
lIvmWZA4y3nB+QSY8Wc39f+dDGsNaw1r4fLgy4MvD87/4Yr1I9aPWD8CwqPCo8L/agzum4cQm41v
Nr7ZeNCn69P16X92LTw8PDw8/l/zx3ucrQ6H3QVoaLgBDQMKSFGk4wKqEc9VEOPwpxJILmyyA7TL
2mhHexAvpOn6k6DMkRIpDFJRlmkTQJQQIZIBxEjn2txvwNbm6oPjD8B27WHH+6/BXdtW3DoGDBX9
+4XKYJhaYli5b8E90/FV9iLwm1L9XouaIJeUexqs4Hj4otfT15A39ub0683h4sEMo3UrvNbSCmYU
gZgUn68DW4But7O7IxdMo6TXSicwnjUV11cGYxyJ7iEQGlvgaewACHpefVW1cyDLkWrIPZDc+j5a
LbA/ubbi7hbIO/38XNJnkF4ob0jeHrClOB44y4E2n+laHjhfO687b4GoLq0RcUB50VurDnzpTtYW
ghbheqx5gxiiC1GuAhOMpYxpYDtrO5EzG7K2JvsnToHc3Jt1b8sQfD9kTNgB8G4RfDBiHmi5/rvC
9oPtuNbAuATu7/V2O9qDZZ7hnrsdGBaJO2oP0J7aVshmyNnv+EYNAEubrJ+1AeAu4J6etxHUTFuc
azvYJ7pW2puCzqp3K1+D9qurgaMXuM+r9+UIMFTXxxuHA5WUTiIQjAdNY3wPgPc9Q2+5J+jeNc0T
s8FZWtw3+YJq13XWwkCJ0M2X0yB4o/9J12nwcQUc8F4AFdeUnNl0HCiv3KlaAXgQ96j/oysQnB4U
bm4Mia0Tbz54CvULNAyr+Qu4X9o+Ct0FoTvC65nvg2+8dze/0mDNcAymGLy68lzJvgLaMZv7xRko
l1V1VsUseHA7btHLjvDc/1X1eCOkfpTi96QwJOxO35PwISgWv9wMDbxNptk5+0Aek9nX3Q8cG7yC
3AMgqHrguMDPIX2eu2/uZLBNkPvINSAvImteVjJ8d2zChvMZf3Yz/98rY07GnIw5sOjMojOLzsD5
cufLnS8HOb1yeuX0yp/vunmz5s2aN4MRNUbUGFEDzOvN683r/+zSe3h4eHj8v+JNj/MfT5ydDqv9
KUglpEipNIh74rVIAJJIlaoDKhlkgNSFEFEEqMpS5QiIH8VwdwVgsjxdegDSIBEtJoJ7MQt0+0Bu
qn+qvwnqtLjXR/fAs22bJm2MhYxf8j4wbQTzPe+P/UZDYG+fWIMNzCLoF2k1eN2vdqqBF5h9ynap
WQTkaBKU66B+bTfl3AH38mspN76Hx9qj8Tf6gnWqliV+Ad8fpLlhN0E9yxJDGvhO9d3pXxS8Yo0x
Xv3BXNX7mVc8mF1VkoqPA34IdfrHgNhhL2e/BLpvLXOyZ4E15P7RFzpI2/W8UnIc5PrYPrBVBlcP
qZ2mgLAwQswD50PnMud34BziNtq+AnkaoaI4cFa7wE9AtBarVARtt9RX0YB0w0tlA6hVxSBSwH7B
/o5lBGQPef3QugWybmV1sz8BZUv40qDJIKabhPcPkOVy7rT1hoxX7pzMHpCelyIyS4FFlzU5ezXY
n1vqZD8Ex1HnOncm6DdySz4HelnX0rAe5HP6AXoNTGFGneE5SBtkh1IHFKe+mH46yE3k/nIVkCfJ
48QpENNFKTkatKZqFuXB9bH2lVYQtDq0UH1B3NG2CifI4+RJ+m6gTDYWNz0HY3HTA6kOGD70M4au
BX0zf6/AOAh4GnQ9KBZ0hc2ljIvA9TQ14Vl7yKpte/9hOBT1itbpb4K61XnHqxY0mtkwZkBDMI/T
dXO1A9ddWScmgdzaWdj3MFgrvK74oAlYX0ofyc2BXdpVaTuoJtHF2AXul37a4YIdxEab9+PtkNM7
b6z8Duj7mda7h4OtkPlm/FxgjPMzaTHYzK7ayidg+iWgpS4OXt7PqJtZBNIbpvTkEuxxLm59ttaf
3dw9PDw8PDw8/oi3N1TDKgVJ00BUFcvEQZC8pWIYgF7iNh8B6YylK4hyUq5QQKorLKIOEKGslAYB
R7RB0moQSaKQ9g3I3ytPpT2g+zRnVXxDuL9/s27LVbjywdMtogcUfli+bmUTlE6uP6TKeXAFxa97
eB5057zXyZdB3zUyM3o9yJH6OT6fguZyX3csAuUDQzXv2WAd4bDop0HhaxHNYluB7YA2Oi8dkna8
sjmrgxxq3m9eC4YN+nSlFxiK+rczfwEMMnSRk8BdM/fn7Aug/9Jvq/ERYM48kZULedsfvHhWBqwz
k5blaeDqpZ4WSSC8JT+mgXZYHSUug3aeZlokSIflynIbkFu4g7SPQQ0X4c5SIEVIB+VDIPeQJ8ip
IHcXqWplQK99xhRwFtDN9D8E1tHev/jcBevQ2HWuUpBew7+MdQzk1c6dn7ERMr9PGBe3DzK3Jj1L
NkDe47xW9jCQ4+Vb2hbwSfIZ4xsJwdcDbgR+DqZc3zM++8G40yvctBh0y00x+i2gU+R18regrRHx
3ABxWdjELpBiaCOmgK6U9Km0D6TzyjHpNmCUZupngBIlLyAa5JtiidQMtAitt3IHtNbiY3drUMc6
CmsOyNvpyLbdBntzm6xWBuu11yHJrUEMS7+Q0hpyC72uFuAC0wc+tQPCwPd9Y2VnGgQu95oZ2AJu
dXp80iGgjhprkSLh8Q+3F51/ARan3NtrKRRYGr7BOxZqb6x5olFRuBbwcGLcGrAdN9q0dVC0cHFr
yLdgXCdP9LGALl1NLtsXAsr6r61WC7zOBHUN/gJOlL50deNqUFOzP0/qCsHXvT6XRoJXQfl5la/g
9o+vD10qAsHNwj42tQZ1gyjreDN7Rfyf3dw9PDw8PDw83oY/njgPEt+xHqgn3ZEsQBzNaQHcp4d4
H/iB0/IaEDEsUgaCVFd74dYBpUVXpTwwV8rhZ9CyaUwp0P+gj9ElQN6Xd7yuxEN68zu5qZWh4MPK
eXWToey4lh0qzgH/DeEx/g3BVSPwWbHlILZoT6zDwN02t3dOQzBejNgk+YDUVFSRc0Br7pzjOA2i
kiuQVMg94nwQshvsm3Iuu6qBq1d2p4RvQNttH+meC5ZS6pfS+2AIVRrKO8D4XhlnrA9I/mxxXwB3
n+fnXtrAeSrleOYc0LbmmN3vgLu2fFW+DO7xroNaBRCZ7sMsBekTTGI46BrJu+Vu4PpKS9PaAysk
Ve4CzNDusAxETVFCawKit7rJ/QlwTz/OewbkNJTmeL0PKbmucpoF0oWtec4HkL7w1faEcpBy4GX3
F3sgQ7z+NKkDaOfVH9ydwPtS4IagBRDrXaxoITd4mQMUnxug/9ZwUjkE7uPuTzQbOHvZv7LpwJqe
/X12RxBjM0eJyyBvE1MlI2hb6Ch2AGPkeMkPdAWU+bptYEhV/JQioJRSchUNdGbFX/4RtJLybnkB
yO2UFG6CLk+3STKCobpuvm4dsMFcWu8H3lk+Q33yQCuuZMrVwJXlXiqqgyPLVt9dBawX8t7NKwX2
qmn7clpB2nxltuEYmFf5bDSnQ4kxZRvViQTjs4Ag34NQ/kjx/ZF1IDQ+4lhYDzBtM103DAJjN8Mw
MQMqBTdbXt8XTJ+bm+sOAMEspy4o/YmUt4Kho5cxqBHYX4tW6rvgX9X8vXE6lMsu1aXPWHgc8Czn
aQRY2zr1L4+CT0SwzrcuFGrqG/9oHuQU87ZmX4OIqAL1fcoBnrTZw8PDw8Pjf4230OPMJ2oa8K44
KG8AZlJMSgIc0gp6gLZTjFF1oFvOa11jcL6WptIKpA7itAgBuavSRx4LulbuyfIq4NZ/hHXXSs1M
qwVFetbtWPNjiB0xvMT74SA98algcIC19LMG98qCGmHvnbUD5Kfyc3cMmLYU2lp+Imhd3avtAcB6
/Q1pOmgtX27LmgLuho7dqhuyfsqdmdsRsve/np62C9xbbEH2bhDax79y4DQI2RrUwicClB+UAkSB
euTVwvR0EFMLPw9bDsoWo13nB5yhkO4YiMJSAXcsKI2ZJBlBOaTNpjdIRumZNBmkw6IzUSCqaPHu
BqCck2YKAyirpCnyT6CVlS4q74PYaNjmdQscA/Sf+SiQ9ok6UqkFr5dZN1v8ILle4otnpyFtxcPX
949A2vXUeynHQWlrnGS0QuDXUUUjvwTvFaFtQ1qDnKSPwwyuzpZr9mDIeZL6OD0anN2dQ7TyoNSX
K+mzwfSx2W54DV5B3lt9hoHXdO8a3uvA+ImXYmoChp7GZcYs0G3Tz9OfBJ2sVNEngfShsh9fEDWE
KqwgjRAGrRtoF9UR2q+gLdWOuhXQFrivOPuDWOas7B4KWkG3Qb0H6F17nf1Bl+Z+V7KBAflj3VPw
veVjNswE93bfX43J4GrlsmsJkPehJcLVDCzbrFus4+Dx3vPvnqgEDmvUocjLUMIdPrxeI4jUxUwJ
/hS0dSLI5QLtqvs9swt8ennX4hjk9c/zt4WBfFb+QL4IWWsyels+AtNA0zCTE6KXBX3hmwfqWfdg
bT5Ueqf8VyVXge5X08qCpeFSv9uRTw6DPVtZ4JwMZcJKbC6+Ea7vj8ve8x3kHXIufbAU+B/063Ie
Hh4eHh4ef8wfTpx13fTvmd4DtbirsKsFMFz6nPrAPNZIs0FO5UN5CzhbuFs5jeB8njr39XtgiDCm
mFwgrwsKCvoV3Bucvs7KID/RqVItMKwsVbPEBAjtGetQc0H92Mfh0weYlHM76TUoNrmb6ytQH9iW
53QDJaLEklrXQN5nmuY/GqijFlQngghVyzo6g7XvszrJRcC+NOdjewFwt7anaJOBq9KpgFxwH5fK
qjK8epF4IDke3EGOJIsRIopElyg4DOQUd2/XYtCXY4LYAaJ8dEroO6CPDpvvewbEJnuCfRoQkHvT
sQnEEP1EcQV0D9TzLAR3E+d+dSAIWbpPfRADWUh10B3QfWHsCnaHcbnvNshebDhqHg+pmv2CMxmS
33nV5flESK54d/VtX0jxf+l8MRm4aarlFQ7BbYr4Fp0C5rLBJQOag7OUq5RrDOSOS7mfPhjU6vbK
aiqYmpqHGi6D/zfB/gHfQcDasIYhlyFgVNDPgX3Bf4rvVJ++YF7kXdjUFXTT9c90TUHZLxVXxoH4
kcFiCWj9xEAWg/yuCJGSQQxgD62AUaKzWA/qZXWK9i6wk06iOXBSOygs4P5Ru6btAHdTdZvaBDRv
7bp6EESSa4TrCrja2wZbQ0Ht7ChuuwPuH9WjzongTlMXiClg6KK7J1UB0wL/zcY+4FfJT5gksH7v
KOAeBq8Hpg9ODYYfh21o+VNfCDwf9H7IVgibF9ohpDRUia84sOQvUK5M2d2F5kH2h+m7pLvgHCTd
dV+F1zeTTqQvBsNMQ4j+F6jgXS2waAxIG3SfyO1AsWnXXKuh5MKi/oZDcPvprx2cH8Cjl7f33Y4F
v9MVppc9DPXVshv7HoKTDy5+sqsMAO/82Y3cw8PDw8PD4+34w4nz6frnR10cDbXLV7tbrQ7IV6XN
IgnECpGi3QSOSSPkNJArSD8p5cBrRVBK6FVIqZLULTUN/AuZFjsuguGCobT0GWhrVG82gqFLeHrR
0aBezumduwZEdafO8RNI86QX0gEgR+5iTAD98KJNqn8F+iUhIvo6cMxxw/oriLE6b/1ToL/1Ey0H
lOuOmUIDOV15ZNwB3lu8Uww3wMfbt2FwY3DliE9ifgSLV/LihLKQ8N3j87c3g21rRnpaXYj4KTak
0Gsw3rB1yIsFZW16RIYBdNF+bfzvgdbH9ch9E+SWciWpKRjeEY3lWHDM04S2HXQ1lX3KPHA31Opq
/UGti0G3GdyJAUcChkG6yxWtSZAwM3Vo8jeQtOqh/vZ4eHnlfti9VWBb5Z6hFQT/dbElCrQB447g
T/x+BpePa4P6BaQ1SZj1airIj9SrREJo/ZD6wUUgPKP0iQJuCG8YvSL8C/D/MdDb3x+8TprHm7LA
UEa/QvEGvUE6J4WAIgkdXUFcUZuJSmB76J6hfgfaQ+1zrQlIT+UHsgG0q+4X6gRwD9Js2nDQyot9
ogUoTURLCoA0VGoklQXlvrxC9AGlCkJKBeUCq5UaICHnyoCunF4YXoBzkmmZ+SC4+6o13GEg1rot
Ths46jin2geBu7ytlK0mOIc6FriGgTJelbRsMISZKss3wOsTU17AO2C7Y+viLAUZ/bNLZHSA1GI5
/pnlIXdGni1zAWRcSa38Ohca3GxwscF1MPzk/zigIIR0DdkWkA3umupIdSboYvROxQlqS3eiiAe3
4i4h/wzppBrzvoW8kVkXk05DtjN56pNv4fzjvB3xfaDkuBLRpR1QZ0PZXk02/NnN28PDw8PDw+Nt
+sOJc26bzFhHLdCNVnKkEuBurlbUAkDuJX3IPhCf4BQzQeom15eugNLEW/KKBlNQ8ET/ieDq6rzp
igfvZr7jAnLB/Uwdp64GscZ8PWQI6LJNkYEmcBfPeZ3eEvRfmsqYr4BSI3Jo6bkgPaW+sgTA+aG1
MohPlQHKCxDlpFr4g2itPdbGgdglzxYVgVA+1j4EeZT0obsj+AyXy9mOg+tDLcq1C4xbA5N0RcAd
Z4mM+hZe65Myn3cA11FbalxNCP0s8lDwZPBpFnA76kPQYmx9HO+DmCW1V+6Ba4P7a9clEMu15cIC
0m1ppDgI8gBXN+cvIDXUfaEvAo7S3qNDwiA+3PHAHg/x3z7/8GF/eJFz49H13ZDc4hUvpoGSENjL
vxn4fxxdNioelDqil7QGMku+KpniBN1ozaHMh+ivo2dHVoCCCSUOFf4YQjcVSIlcAf4F/XN9joPp
sv6AYQfwI2uUxqC2VlX1BchfaPWFBu6JjKImOGao69QCoI0VYRiAJlKg/B0YLDqdXAB0Q6ReWEEL
lr7SRoH7jHut0hXso9W7ailwZTNDHAZ3V/UrdQC4OmtGcRKUTfKXUizoXdJBaTOopbVHHACHpKa6
fwBRjuqMBClKbJWqgHJBt970LYi+0gdGMyjv6R95JYHe6j7v+AT0y211bXfBnejIdNwBXT31vqsN
6DuaSynZYPjUdMTPC3I3WVMdQ+FVm6SdKdFgH+eY4uoOPDc2NHWBwIU+X/qUhdzsrK153cFWzzIm
7ydwJDnrOb3BOsQe6MwA6wvbJmsleJX6ek9mO7CssnRIPQD+Y/1nKdPBVsIRqbaEX9+9X+XO15C6
K63xq8JQnwbU+wPt680PeOTl5eXl5UGDjQ02Ntj49+tlFckqklUE9nbY22FvB+hj6WPpY4HV1VdX
X10dhg4dOnTo0Lf/BbJq1apVq1b96/H/6PYeHh4eHh7/nf5w4nztp6fa7ccQm3i/dfRKqFKqwqgS
kyCvpH2Sww+URqwXM4G1JIqD4P7CZXFdh4BOfkt8dwA7xUnpS3DmuBq7PwNplKRwHKQWylmlIohg
lugegW6jX7LJCPjTRNKDdlDtp1pAfo8yzubAUKmP/j3Q7ok56mmQDxCnvQKxxVowvQ04NmdmpT4H
xwvb6cwMoJnbnd4eHqx6WfpJIqTXTu6Z2AEKzAr7LKwWBG4K/CJahWwf80vvEpAZ4O4n3QN351eN
MheC71DLkFwbBFYK8Y88Dsbt5pr+ZtBqqcW1VSCFinDJBtJjZxdtBMjzdXb/lmA55t/S9x48/CKn
UUY0PMu+c+Tuanj64fXtV6yQm2p/YikLXvHRG2OsYOgYMMD7Ktg2ZF/OfQJa8bxaju8g0h7VIOob
KNq7bNliiRATU/BFzBjwPe4/1O8oyC2VQ/IEkD6TJrIDRLR6SnsMopPW310IxA4+oy24q4udYgSI
srxgFkivZL18EkR3zVcbAdpP2iDNCO7y7OUi6PZLL5gD+jpKGakViD1itHs/iDLOU6IpuMLVsep5
cGeLX92FQTzRrpMI0iN1EvuAIURK3UC8EBK+IMaIHFEBxGvRTBQEYRXjxWUQm7UpWl+QvsBFf3Bf
Ea8lPxD9lWXGKJDLeVUwJIM+yvDYMRrkO85f7L1Ap3eud9QAJci51fkV6HeZOxp8wXpfN1JfGzJt
Od/numB/k4O6k1VB96n+tHkt6E8qV5RRYB2XczrrNWTOzriRVgzUWlKi6xZoflp5dyq4L4vVukVg
uGzYKVUBd5jm5R0EAbrA0j4mkLbSQq0HKRczvsueANSiHMv/9fZVbH6x+cXmw09Tf5r601SoV6le
pXqVQL4p35Rv5q/35ie3i8wtMrfIXJBMkkkywaDLgy4Puvzv+wIZVGlQpUGV/rzt/93EVXFVXIUd
zXc039EcumV2y+yW+Ts2XMlKVsLt27dv374NcXFxcXFx4KroquiqCKHxofGh8dDoQaMHjR6A4Y7h
juEO2MvYy9jLwNF5R+cdnQe5J3NP5p4E3fu693XvQ4O4BnEN4iC8TXib8DZwreq1qteqws2bN2/e
vAmyLMuynF+MkqdKnip5CurUqVOnTp3fLu6RwkcKHykMWceyjmUdg25FuhXpVuSfP15/eyHkuTDy
8PD43+YPJ87P1qf1fXQWThW8WT3IAqXfKbkteiDo8uQX8gIQ34l2UgmgC89pBDiJww3qac2o6UFq
IM1nOEj35a8YD+wkVwoCllIWE1BBdNBWglgoLVSWA24xR/0IdHc4KiqCOIBFfgTirujo8gX9PP0R
707gMqX3etYfcgeeL3byC1ALp/RL6QLiunrKWhmeNr279ElpuP7p/R9fBYC02dFQigN/UXqsb2HQ
P1NOpbwL6hR8fMuCwRWgRP4Cuiu6otI5yN7uPpLRFpzrsoJSLRDo7VpnGwLm44a15tsglVaDDaNA
d8q3Sug8SKnvkxY0H+5NTnr9SgdPLl+VrvSFh953Dl1LB2eM4jLowO+rgrML5oGcoQuVBkLO0lcr
0m+Cv+JVw9wEShasHV35PBQ6U2pikSQIWRJ0Jngn6Cfq39X3Amkfq6gJYoEqaZVAZGhJuEDYxGBh
BlnlO5aCMpV5kgbql9ImPgJaa0u1b0B8I0K0KNDXoI3UF8QhqSzTQS6n3RGDQFwUy9gG4gB9tW7A
FlFArAKlulxEZIBpihSqWMHxmXpI1AC3jFHIoC3SFogvQD2pfqI9BK08hYQBqC12axqINmK61A9I
pz3bQdor2jEGRBOxRbQG8T0yQaDOFbVEDNBOpEkpoLWVBxh8QAox7lM+B30FpYK+AogD0jvWicAE
Vz33zyANlW5RG5Sbyk7TdMg+aykofwSOW+p411XwDfE/7BsHhjneqldFcOyXVOV7yC6dcSPFDDyS
78jVQOwQU9QgsHW173EPhpSv087mjQLjOcMg5SX4dPJrYl4A2iuxW/0J+INJq5+fn5+fHwSMDxgf
MB5eNnrZ6GUjKEhBCv7Vem8S5/rH6x+vfxxoQxvawHc3v7v53U0YWmNojaE18hOZWrdq3ap1Cx75
P/J/5A8tJ7ec3HIyHJt3bN6xeWArYytjKwOFMwpnFM6AW7pbulu6v0+Afit+xYEVB1YcCM+aP2v+
rHn+BUC1atWqVav299s3CWoS1CQIrl+/fv36dRBDxBAxBNTl6nJ1OZQ5U+ZMmTNQaXml5ZX+wIXI
7/Vk25NtT7bBg40PNj7YCJlfZn6Z+eXv3/7huIfjHo6DxMDEwMRA6DKxy8QuE0GpqdRUasI5+zn7
OTtcqnKpyqUqUJ/61AeuSdekaxJEz4yeGT0TKl+pfKXyFXgR8iLkRQicHnx68OnB0K1Ntzbd2kDO
iZwTOSeg5fyW81vOhwKfF/i8wOf/fH2fTXo26dkkGJIxJGNIBlCEIvwLibOHh4fH/3byHw1QeLBZ
Fz4OXooXl5Mmw88X9h09/QRMhwx285eg1RTNWQJEkch9kL6UFkoLARU3LhADxRS+B2mpOCLVAAmi
GAjiuCgq3gFpkrReiQN5vTim9QZuUYIVoJWU5uteAY21HW5v0HZIAYwGtaSlSdIccO5LGnl3Btjq
Pw+IOwTax+6ozO1AjtbZcQRMP/qUNa2BuoNrN6rkBbXjmrgb+IFxRWhedGVIa2df670XJLfPvMCt
4P3M7OM1EXSqzyc+G8C7im+l6GUgVij1g4Ige1l2EYsfZL1vOZv7Ezjue33iVwVSX/l2CLwC98++
avDCAHFrz1Q49QDitt1YeDUCnD2Nh70OgTky+kj4O+Cu6XQ6VLC987pJ5h0o8lWsKWw3NK7RYk7d
NlDpTI2bFb+D2OtRw6PLgM8zw2SjDZSW2hltNegOi+JaCzAtknvLq0BflaLyN6CrLj6TqoEUL1ry
NbBXna2Ggu4d7YwaDUo8c7UHYHxH6Sp/CHqZXSICpE/du9w3wbneNcDdDWxDXd+7M8A6zqWoa0Ab
K1ZQEIz39Q7xCej2SQfcg0HurDXSjoEyVTvtPg9KiJBFcdBdkXuTB8oFuYfIA+mcFCKVBemyNEbU
BjmCpqIj6N6VE6UBYNgk6+SHoG8iPZeqgrG3tEbqAIZBUg9CwTBHuio6ghIu9ZRGgHJOl228AAbJ
67HvCjDvNrf2eg1en8ubpDJg3iB9rfYDfy+fmvqq4Pu+Lk/ZCDmV0mLT7oGjsiPHdgzCb0VMDr8H
0aejqhddDfJtccnUB+SPWSO8QddfmalcAvso50CtM2R2yJ5muQPqTbWN2h1kp5jrin57DbV4TvGc
4jnwZOuTrU+25i/PPp59PPs4uAa4BrgGQPjL8JfhL39/3C5dunTp0iU/kSuaWTSzaCb07NmzZ8+e
4P/I/5H/o3++vG8Svw5JHZI6JMGt7299f+v7317/zqg7o+6Mgqorq66suhJ6ZPfI7pENnV53et3p
NVwZcmXIlSH/fDnsdrvdbgfXRddF18Xfv53vA98Hvg+gXLly5cqV++f3e2/DvQ33NkB1qbpUXQLd
SN1I3UiQqknVpGpQo0aNGjVqQJmzZc6WOZu/3Zse38LphdML/9VPgkcfiD4QfQCyi2UXyy6Wv/xN
j7TPOJ9xPuP++XKeyDmRcyIn//W+qH1R+6Lyj9vRo0ePHj0KG+M2xm2Mgy2NtzTe0hiOFT1W9FjR
/PV+7+fwe+Pt2rVr165dkBabFpsWmx9nz549e/bsgdOnT58+fTp/+ZsLlRPFTxQ/URycTqfT6YRD
hw4dOnQINvtu9t3sCwc6Huh4oONvl/vNhd/tkbdH3h4JOyfvnLxzMjyd8HTC0wmw/en2p9ufwlb/
rf5b/fPL/6Dhg4YPGv7zx9/Dw+P/PX+4x1k2yKu9BkGjHZWM9W5BDXOVzCIdwOZyPnK0AzlRPiEd
AWkk20QeiIPiqagF3OISF4AvpKnSpyCuaXW0l0BJLZEc4Af5oGQF2vKhOA7iIdWk/sBDbohJwGby
xDXQ0qT3JCPIm93z0/wgffz+mut+Ac128cu75cD0fe2NNWqCKO7bwn8QSCl3e94EAhcbzxsWQ3ZV
ffnA5uDcYdSbksGV7pzq/Q1oUaZ6htZgbmDQjCNB11A3w3sUqB/xrWsHGJrKfsIIhvt+/YKWgjXI
8tjQGmxLTLWNDcB6Lqhv5Pfw68GXdxLKwJ33T9877YIn5gefPzaBq6zfFa9B4F08qFrgR+Dqkhtt
Lwn6Ldox9y2osLxyy7JAqeEVV5RMgBhT7PICJ8Brsa6LfiLknbGMsKwBRw8xXHwNhk26CoZjYPpc
v99QGpyTHfUd34FixYgPKDPkID4CzaYZte3Az9I0UQyc5dzB7p6gTRbnuA32VmKAexWIINUsfMHd
QoujPMhPpKnaJJAKaAXEenA9F8WkWqDUlAqJwmBYqW8rMkDOYJT4HJRg+oqHoOTJx6SWoLYRjaVB
4KqqJpMFVBODpdsgbUdTl4AygrbsAcNBXRN5PkgZ0njmgPtbNU77FaSZKtQH7bF4V9QGrSEPJRPI
WVJDkkDtyCV8QJwXZ8kC6RvpphwNan1DqGEtaF15T3ofjCb7PbsNcDinOb4HHpqvK81AZNOOfZBb
xNbM8gKMmIXRDWEfFFgRNh+kPUoPw6fwelzC+w/mg/smoY4DoM6TDwkVrGbrSbU12HfaTM574JWn
DJGj3l5DLfpl0S+LfglXwq+EXwkH9zfub9zfwLNRz0Y9GwVFBxQdUHQAMIxhDPvH8cqUKVOmTJn8
RO6V/pX+lR4aL2y8sPHCv9pvj6I9ivaA07dP3z59+/eXN2pv1N6ovSDHyXFyHKir1FXqqt9ev2OB
jgU6FoCkvUl7k/bC3bp3696tC2mH0w6nHQaxSWwSm4AqVKHKP95/aufUzqmd8xMt3S3dLd0t6Gbt
Zu1mBS8vLy8vr9/ePmxa2LSwaX+1YBWrWPUPd/sXmd0yu2V2g8SViSsTV8KhDYc2HNoAjvOO847z
ENkusl1kO2gwpsGYBmOAhzzkIbSNaBvRNgJ4ylOegqZpmqblJ26h9UPrh9bP38+bxPnU1VNXT12F
1NjU2NRYCNkZsjNkJzQc13Bcw3EQ2CywWWCzvy9nY7/Gfo394BGPeAS0j2of1T4KjnY72u1oN/CO
847zjoPea3uv7b0WpGwpW8qGy40uN7rcCM6VPVf2XFlo+qTpk6ZPfvt4nO17tu/Zvr8/XoxfjF+M
H7xq/6r9q/YQeDnwcuBlsFqtVqsVHP0d/R39gUwyyYSkfUn7kvZBzOuY1zGv4erVq1evXoWoqKio
qCholdsqt1Uu3P3x7o93f4SLAy4OuDgAGm1utLnR5t8u95sLy3W119VeVxu6hnQN6RoCftl+2X7Z
+c8evLnwLElJSv7+08TDw+P/QX+4x9l5zfA40QKPveM/PdIWfEv49PGpDPJlMVnbCZJDnBPLQPQW
F7EDebzgKXCPxzwG+VvpkjQSnPWcL109wbHdVdpVH2RNriK/ArFdLBYRQA45IgGkygSQBZQXT0gE
+WMNlwzWrMvFTwWD1CAzx1oNpBFl2lRyg9/HTX/tvRFCLW0PDnoH/Ie0iu1aEkL7VO1dKRfC04NW
+b4Dxk/4URkC6gemk14qKFt1V0zxoOzSvTQLcFzWfGyRoPZ2fqKeAUc7x0RLUbB3tbTM2gk+JYNH
hNYAt0+hc6VluGt49dWrWhC3+szu03fhSfcH9eN6g2OB727jQzA99Ksa0AtcXfLCrNHg80iZLDeD
mqNrvazqgCq/1F1Y+WeI6RXTo0AF2G04UOPAM1iVvuHXH5fDD6O2bt6yDFb6rJ22diWc+PXcodPv
w6sTKacTvgPDIZOf3ABks+64bhK4r2qnxKfAMXmRrg/Irw1j9SNA/66phX4DeB01vKMfCoahjJPO
g3RP+KozwTRYzhOXwNBU/kLaCXworojioDZUC7rHgW2be5lrMNi+ts9xVwJ5iKgvlQO/bPNL5RqY
5up1UkHQ66VJagUwFJemqEvBq6byPTFgXiy/J/0K+o1yLD1A3aE+UreD8xuX5r4GrkNqstYZ3BPJ
0fqDezZttXhwqWKoOwvcV7WRag9wW9SFYhu424q22s/gbC8aiBRwp4iRFAf5pc5b3wMMm0xfeXmB
6ZHxjGkjeC0lVJQFU5pptdQBfMNMicoUyD2R2TT9AVjGW47m1oeAQ2Fj/PZDkYIFrxbyA1MV/Rlf
GxjijNO8skGbIQ8zVYC89dbhogG4B7t3mae/vYZq/MH4g/EHiEyMTIxMhPjQ+ND40PwhGsWOFTtW
7Njvj/emB/QN7Yp2RbsC8mp5tbw6f7k0VBoq/QtjU/92DPY/8qZn8NHjR48fPc7v8a0ypMqQKv9C
T/OboRVvhnq8SVjzFuQtyFvwhz+Of8jtdrvdbrCcspyynIKuhboW6loI+p7ue7rvaQh+Hvw8+Dkc
L368+PHivx3nTc/siV4nep3oBRUqVKhQoQJ/GUP9JlGsd7fe3Xp34b2l7y19bynEdI7pHNMZTp48
efLkyX++/C9/fvnzy5+h8uDKgysPzr/A4jrXuQ6VLlW6VOkSvPjpxU8vfnr78d7U603inHow9WDq
wfw7GfIIeYQ8AmxnbWdtZyFpZtLMpJlQoECBAgUKwPNJzyc9nwSlepfqXap3fjlKW0pbSlsgoW1C
24S2v13ev72wjJoZNTNqZv7n8GZM+ZvEuWWLli1atvj3n1ceHh5/vj/c41y+TcyW2hPBIOR72QHw
qkSyV3JLKF6+2MbCtyCnel6n3FGgP6q/rx8FfMIGqgD9CaEucEFc4ipke2VF5eyDoOnB3kEW0LqL
MlosSJukKGkUkCkuiTogbjOGzSBtk1fI3uBuml02VQFbg/jIxGvgSsoItt2A0Av9lw/cDvozoT2i
boFrpCPdYQPjxoKHyy4G8Z7jc8dVCOxWbWZABnhNOb/xUTN4Uev5udQVYB9DrFwL3FWdQY7jYNhj
8BUWkF+7nqixIO1TjzkWg1RRCGkD2I/77Pd+F56+TLmfMhkeOC5+cv44PE59sOLeZ5DT1WuJ8Qr4
p/g08FkKcpqtseMW+Nm92pimQdT9YkdiBkH4l8VOFPgGDLf0W43D4Na9O4fv9oQ7zeLyntSFl4nx
p145QBmpbNS/BHu2+sz5JdzWx73zNAcOfH2k9vEAqLqjkqX8OCjZqNj9IlZQ3tcVMjSA5EHJ1uR6
EOITsjdkEeiaisf6LmCeqVdVHwgrHT4rrDN43zNPD6wOzg8cF52fgWunO8K9H1yfuvO0LkBDuaXy
OSgTRF1pIMhBuo90FshIyTtgKQ3ZjXP0qSfAv5vv+wFLwbDduMSUBtxRTHwL7o/dldw/gmuW+ywb
QO0mBop1oH0oviIV1P7iU3yBPTzSvgHtY4G4ANjI5FfgI8aI1iDXFu/xFeAtDotmIIpwT5wFqZxQ
RTlQh4qHYicItzgj4kCeIr+UjoNUyFjCNBQM32lZHAefwY5WtiMgUg3FWA8UFiFKGci5nf48dR14
Nw8c7BYQuDCoQ0BpCD8izkjrIOVo8uXXR8GZJoQlBbKCcoo4KoP2Qv++996332CL9yreq3gvuLH6
xuobq0G9rF5WL0PQ3KC5QXP/9bhR7aPaR7WHR3MezXk0B0pTmtLA422Ptz3eBpzmNKf/9fj/SHJy
cnJyMvQc0XNEzxFgTjOnmdMgISEhISEBOMABDvCXhPEf9ay/uZCwGW1GmxGMdYx1jHUg7FTYqbBT
/756vGG6a7prugvVjlU7Vu0YGOoZ6hnqAXe4wx2o7KzsrOyE9aPWj1o/Kn875zLnMucyMIwyjDKM
gj7WPtY+VngV8SriVQQcP378+PHjUHhx4cWFF0ODYQ2GNfgvjkOFixUuVrgIN+Qb8o1/oXtErBQr
xUqQ+8h95D7/xQr/efzfPDxJBSpQ4e3FC0sISwhLgPSH6Q/TH8KrsFdhr8IgomREyYiSoBxUDioH
84cuGbcYtxi3gCnVlGpKBct1y3XLdVh3dd3VdVfJv2OgoKCAdFY6K50F+tCH/6I8f3th2TK4ZXDL
YEj/MP3D9A/h9f7X+1/vhxsvbry48QI4xCEOQWta0/rffnZ5eHj8mf5w4pxYL/XTJ0ehhVfd2PYK
nL156cmlMLD7uHs6akLh+AJqbG1QQuU+yh6gm6giNoP2kg3aaNDKqTnuXUBj0U/7FqT3RSV5DMiL
WCBPBdcO9zbXDZALyilKS5CipFgGAS7JgBl4aV9kGQ2iu+2KowR4naxYvoYV9F6RZYvVBO2l/Vdr
D5CClFvGkyA+wCIvBbd/eqilAxjLRPYvUhMCO9WeXPpncP2Y+6U9GDKjcxe6BwNNjF/pMkBrrvo5
2wATXEWyDwMl1fbqC3AcjupeaAI825P70lESHhe6GH3+ODyJutP9Ri5kDNOX1q8Ar1amXH8TuL9x
9XGWAnm/fF16Csomv736pfBs+quFzztDwsmUjxJzwL7HXsbdAxJ3J/+Seh3sZWzlnFVBlyB3UuqD
miaaO4NBtHFnievgjhB6cReyduTGOr6HvT8fPnByAJy3XMq+WhvkJ/I3Ohvk7bW+Zz0Lcl3pQ6kU
mGNMwebaIPayTWoLfm39L3iVhh6vOvq2qw6Bfv6DgwaBoZu+utEP9D8athrqQM7I3Pl5qeCc6Vrm
yoDXjdO6JYfB5apX690cCekrM0anB0LoqfCSQS/BlGMqZv4FvPNMm8z+UEmpUKOCG3y6G/19L4B6
Q/tMawVaG3qxCbSxYqZWArTBmsxmEDdFS1ERpA+kkdJJ0EZpH2nNQfijcg80bxEl6oF2WLzHOyA9
p5ZoDtIw7UeGgjZIBIsUUGtRQ2wFrSlrRB7IFuM8w0XQV6en+iN41bJVs78P4mPDZLkAmGtqDZR+
YJOyUzK+ANlqnK0vClGdChJeFkofKvQk+l3w+9xwy7wIzO94ldX7g5cufGXUPAAa/ZFZNf5WbGxs
bGwsnOp1qtepXlBhToU5Febwu4cw/JZ69erVq1cPjvkc8znmA79u+3Xbr9ugSJEiRYoU+aue6KEM
5d8wO0L1G9VvVL8Be+ruqbunLpimm6abpuf3sIdGhkaGRsLFdhfbXWwHtahFrf9LvDc9khWpSMW/
fqMUpSj19suf2yu3V24v8N3su9l3MxQqVKhQoUL5QwMq1a5Uu1Lt/B78+/r7+vv6/Nkx3tgRvCN4
RzA0P9T8UPNDENoqtFVoKzD9YvrF9Mtf7e8/h2jsidgTsScCOsd2ju0cmz8EJT4kPiQ+BEJfhL4I
ffHP1yemU0ynmE5wq+atmrdq5o/VfuNm5ZuVb1aG2F6xvWJ7vf14b2YHCZ0SOiV0CtwveL/g/YLQ
cV/HfR33gW62brZuNpzvf77/+f5QIrdEbonc/Hh+jf0a+zWGJlubbG2yNf84vjluCV4JXgle/7jc
b2xvvr359ubQdlHbRW0XQRl7GXsZO8T0iukV0wt2Pt/5fOdz4AIXuPD2zy8PD4//Of5w4lymfPHW
1aaBdZbzYe5F8B3r9av5A0jdlrgn9SMo4BXmF5gIOe/aDkud4cb0OzsvLYSQOv7PI4pAXLWXdc91
hajAwHKFWkD0ubxTJXVQMKHYjkIdwLhGn2kaB+KeZNXiwSWpD90zQf9MZIo9wGjZgg8Yvi7wRbgG
Psa6c5p0BHcrOYi7IKvcE3uBEtzWQoEORquSDrqGgU0DAS1TX9prGJiDSt4uORICSiZ+kZUFWtsz
l665wBav/SzVBfe9vNfpQWD5MPepKwjcawrvK/MaUr/0nupXGl5Mu6W/cgSelbo197oF0p5qkxgA
uiM+j33mgMGidGcT5EzLrZQ3EjIbqhftgyFxfFa71wXBPcrpp60FZ0W1nLYXlATDVIMF1MJqL9UC
2mBXF7cd5CXybSygbXAvdXcEtbU4o7wC8lDUx+Du55qtZoK5uqmBz2aw1LSFa81BHeWyW0eBaZBx
p+k7cGdr/dRAyPHPbWnTgZrtbielQUrZdFNOI1g15sesbR3Bb7xfKe+zUH5PyYSS74G6XFur1YF7
T+N8HpwB3UC9RW4Ethr2d+xnwIbVx3kcMItS8lDQuiot5RPgPOl8lLkbxD33IOcHYChhTNd3gqLO
gi+LTICAe/53gmaBmKXe14aAdAtJnAP9UqWbrgW4b6iLXVNA66i+piCwQLhFWRAOToklQAuRQzBI
4/EVA0D7TEyX14Boq2WqX4N0iQrUBC1cbaXOBbm+cpbboM6VToscoL9eMQSAvpc2SNsF5nj7cFdF
4DNDmHwDtF2igW4V2B5klk2fB3KK7y6vAVB9Wv3lVQZBtVfVq1e+AZyVylIFtFhRgjtvv8EqNZQa
Sg14r8Z7Nd6r8Y/X/9tZMH5rWrD0QumF0gtBq/hW8a3iwfSh6UPTh/m3wuNMcaY4078e//cuL5dd
Lrtc9ts/bv9uO1vubLmzJbzHe7wH1NTV1NXUwdkiZ4ucLQKbfDb5bPIBNrGJTRDWOqx1WGto0rNJ
zyY98+M03NhwY8ONcLL8yfIny4P7qPuo+ygoN5Qbyg1ouLbh2oZrwTfWN9Y3Fqo1rNawWkPYe3Pv
zb0384em+DbybeTbCBr7NvZt7PvP16e+V32v+l5w5tiZY2eOwea0zWmb0/Lff5OQ119ff3399UAz
mtHs7ceLSYlJiUmB1C9Sv0j9AnxK+pT0KQm6RF2iLhEsiyyLLIvy1yOCCCKgUaNGjRo1gtPvnn73
9Lv5Q2fejHWvs6DOgjoL+M0e579VaVClQZUGwZ7IPZF7IkEaL42XxoPUWeosdYYG1xpca3Dtzzr7
PDw8/jtJFy9evHjxohA1a9asWbPmvx5IC3EPVq9CenrG2pQL4DXY/DhgN9z+4f7TE2Mg3h3vzOgN
RXXFNpc5Csndcjs/+RXuzn1a5FQoRKZ5r4uJgJdFkiYnHoZW8fUO9CsBvuE+7U03IcDo9zSwEARe
CpkR9gzUhaKlmAHqqrSzvz4ANUPN1VUDw8TIbWWng3zD8VSVQI1TpqljQchSOXkh6ALUr6UHoPY1
tpWLgO6ovFm5CTaf+2tv3IDsInuCDybA65HJzbK/htxKjsXWx+B8bp1giAZdcsHypWygZlbeUSYI
nux/MOfWLLgVcbjAzlHw6HLKkCwLWBt6mf3Pgv9B7yDvL8HRw7bOVhXSCmdNT+8Ali7OINs90LXX
5+jvgurQ0sQp0LXVXTO0A22GXEdLA9qpelEXnDMcs1zTQRwWDbTeIEVJtQkELUI7JkqB8BWh7AKR
I45pMsgP5a5SI5AfyLvlDiCflwdK1UGaKi2W+gA/Smb6gHOc85VaAQzH9G2VPaBK4pV2C6SxooXS
DCS39Bm/gBQuxWj9we1LipYDulTZoWsAhsH6C/J0UGerx0UzkO9LR5QY0P4/9t46PotrXdi+1sw8
Fk9ICAR3L+4uLe7uWqBAkRYoVlxaWooVihWnuLtDcXcvTiCQEJdHZmZ9f7wnX/Zv79O3m8Le3e85
uf5Jnpk1a+51y8w996yZWaNnkSeA5kyRGliO2JO1DSA7mL8YwyDnhOwlsx6C0O2hGUPWQtZPMx3M
XAAyv864KVMMeFI8n5kDIM4ZVztmC2RYlOGbDNdBWEWspQMoxZUB5iQwrhur9YsgLbKhZSToq42K
Hj8QHcUb8QOou5RfFSd4arrHmIVALa4VNEuBs5NnkbwEspewit2gLaKi2RP4zFND7wL6aFdJ1zVI
WeLWjOHgXGLEkBcSergmeLqARbcPdgyBnAtz5sp2Cqo8Ka0U/x4Kdyq8MN8cUKO8m1ivg6OfNYvj
/4FE8Hji8cTjiWBfaV9pXwmlZWlZWsKVJVeWXFkCcd/FfRf3HdSpU6dOnTrvv7//aWzbtm3btm3Q
rFmzZs2a/dXSpJNOOumk86E5d+7cuXPnQO3Vq1evXr3Gj099qOJd2X78+ISZZcBp9ZRL2QailnLK
+x484vnQ+3fgov/t385vgJAf/Mw8sVBrdfURVbPCa/mqyYtB8KLBy3pPCsHbBbHzU4IhanBSicje
oD0Se6PD4cWDVwsj14P5ccrblE8hx9zsD3NmB09BxmpeoPY3BzrngjW7PTHwCZin1Qo+Cggf1ap/
B4qp5vGaBTwTX7AKKCsO6QZ45t0bcb4kxDU7tf/oXYgrtmHAnr0QPfS33W/8we1kXlB1UOp7Ncs2
FKxlsozJvx8C2lYsWPwJvFFi4p/9Cjc+O6zvbQSPU55lf/klxPbTvvZ+Bv6zvU37FZBT9Ir6bog5
nNA7tgokXEr+IrE2MFG9I/qDFqA8FA/BNtC6SRsKor24pZ8B5brcaa4AT2tPO0MFvbBxW28AcqYc
JZeBcdK4p38K7EE1BYh2SjsOglTkLbM8sF8eJQLMG+ZpMy+YunTIHGBMlUJ+AnqssUHvCbKCfG7+
BpZjWkFRCWRVcVTeBnld1hJOkMuNpkYPMK3majMITC9K0BHYZ7Y0z4EhzSzmGjDj5Ha5FmSwnMx+
MDOZE8y6YFaQx83nYJ4zw/UjILOIAWoYvGkXOSvhHES3jv7q7U5w1/d0SHkIxjk9yBMOISdDnoXm
gIj2rxdHOMC6xLbFNhAsYZZGdn94vvJ56ycGKKvVKuIKJOVKKedeB5fPX9tydTpE5Y66GFUFtILW
1dpy8I7yLmhvD2+yRkXFVoTzX1wucbUhRM1/WztiI2T8LWPrwAKg3VJvOaKBCGWv8grUnBQw+4Ax
3FyqDwHC1XvKz5BSwTnKfR2MK3p/41eIWhY/PyEK3PlSarhegM9Xhl3cA7/uGf2DRv3V4f7HhJwN
ORtyNu19zafnnp57ei6Y283t5naoGls1tmos2HLactpy/tXS/udRsGDBggX/BVNA0kknnXTS+c8g
PDw8PDz8A0zVOP/zBb8TAp6sz9HgejGwDTESio+FwHY+LQOj4c1E5/NbVyFojVsJbA1PDz+d/fgY
xM1zPUow4MKsJ4efV4Us0bY7gRbIuzW4cfHb8Fp9UzFpEdjC7QPj9sCtQm9an/eDQmPyni5cEQL6
Z3HnPgnO+dr3vvPB9JGfKetBnSZKGWcgOc9NZU93sCzP0Df3DtDK+T0NvAvO06+q/+YE1+0nJSL8
QRzXgn0iwTtfdXft8uDnyZiSZQfYJwZ1DOwMMWtO7b6eH8xRgaP878ErxcwevRwe7jtf+3QUvBj0
1P9pPEQNxVDPgVeI12G7CawQPwkdkloklk94CImhyf6Jz0H5wjpDmQv2+fY9lu4gRxvh8g24OxpT
XT7AIA7wFuhg9hKfgHxoFtRrgzJYfMwsMPrI/zM3d46WVSkFYqTxyPwcbINt+cRPYCbK6mo0JMcn
JeomKMnqDAyQU6ir3AdziPHAvAjiCy4pD0BZJZbyE3hyuuLMSDDuUpJCwCHu6l+Ap5J5WtYDLZaf
lZbAGFbLImB62CCrgJhpnhGXQPwgXhMIIposZiGQL2Q+qoIsQj/OgVJCbyh6geZnCTBmgHlOVpFz
ITFDEvo5iFj9uuTrVeBldyyztgd6PjypbgL7QK8GXs3h0bdPsj69Bm7N3dssAc4bzoUJX0HipsTq
we3g9dOYUzEKRH+fMCN2FbAufrC2CB4XCp/7zAYlTnwk8u2C8GPPpyfvh0jfmNwxNUDUjV6nDwWl
qTpJngG1gfKVzRe0Z5Z98gbkcIW+ybwVzE7MMXKAFi6GaaPBXkM7IfJCgh43M3YqKF95nXC0g0sJ
d1s9eg1PVz4r8nISfEqR+Lx/KrL+vXhX867mXQ2a0Yxm8Df//BdZycqfuLBOJ5100kknnf9JvHfi
7Oxoq+RW4MnXUZ3fREBQB/8+Z/rDw7HP7qXoUOx88KNawXDQfbHJ+tzgrm8cNTdCdrL55a4Fmfy1
oxmAuo1K923UCWqsr+WqcxCenn5a+pEfuE677iYPBCexWY2a4OmpH3J9BfoNOc6tg/LU8ti3HFDc
2Kl/CSKbGO2qCu6g37g/Hd4mrZu9MxmCa7fP2j0H2OfkzlnaAbZduSp5JYJ6w1pJnQKcUYppT8HT
Pzr/y2hIzHyxw7mxoFW1bkqQYBzMfDesOzx5cGXB1T3wvNTNUtdzwpscKbNdB0HOcPj5vAZbE+sv
6o+QXCK5SeILeFsr4ZfYX8F9Sc9jnAQxQxxVa4E73JnJ/SXozT1rjcLgWWTml8tA7pFxYhXIDNJk
Iki3TDH7gEgRbQkAEa22l+NAtGGZWAO29rbPVV8Q1c2c1AapmIFGPrDO8XqoXAa9hWuVUQbMLPoT
Ixy0cC23KANyjexmXAQ+FXfFGDA+ltHyDuhL9ArmEpD9GURbEIPUIC0TmJXleClA2S9XiIkgN4sZ
8kuQlc1xZkVgNof5AkSMyCZeA4bYJGaAvsiMNzuCGs1gtRyYdd31PQdB1SyFGQRqnNZS2wUx/eMy
JvWFy+Wvzb19E3IuyH43wQ6yj7xpbQFv20c/i84BlvKW8eox8Mvr+7VvTnDv8uyVQEJiUqH4OEjy
JHZLPAXGFPkNa8B5zOWfkBdO1jlbL2EWiJmymjoO5DEKqgVBKa38oGSEh70e3wm/DdQUE2UKmBO5
ZfwIbzK/rhyRGfKIrA1CW4LfF75fhm4DUUAtqVUAdP2u2QES/CJzRn8BHBTH1MPgaed+60l9y8Dg
vzrM00knnXTSSSedD8H7J87rzTEEQNKot4HOOLAYMSn2q2Br4D0/oDy89BV1r3vA8lFoD70BpNiN
TW+/gMRVry0B4fBZXIsM/UaDT1PrLu+OICYz15wOeXrlblrQBVFP4qe+9ILLtxNi9vwC/ps9k8p2
htACajHrx+CKcW/RE0As1+y2r8HowzLDC9TZfj19kyFgVeXPKuwH+/FidaqHgyhrWj3lQXYyj+m3
wdzoKcxIcH/8utydcRDXYOfI7b7g7hB7Qs8EvgvLba1eH145ksbGx8Mzz6UhZ8ZDxKbo2zEVILmI
eKm0AL9fHIW9M4H0118adSDhQmKGhCXgumacNQeCXMULcQ+El3nH3AiynoihDZi+cgHtgJ9kCbKA
bCHvy74gKrGf2yCq0RInyK/kUakDS8wR+IB5izlyOrge6oP0RNCei+KKL4hu4iPswPd6Rr0SmBbj
kdwC8qZZjFsg/JVnSj6QveVZuQHoREklDIzfZGazObCBsvIlqK1EL0WAiBLd5QYwm0tv2oJR1ogz
zgCSgnIzqFOUzOoAML+RbcxJIDfKrXIiiB9FA5ERLIdEW66A1tfSgAFAfkx+Av0bsxR3wVXSlWhM
APnY7CtrgsgjNioV4P6B3yq9iADdafQzMoE6QmukngclQcmnHIdoS+ziuK6Q1RI2J6QpxJSLexub
DfS2ZgbZFtynXQc9MaCkqMXUpuDO4B7kugg0N8eI6aA8UC6rW0Hz0YSyDZQJogJrQNxQs6kmyIYy
QmyBNzverku6DY7vrUvf5gTrcMtgrytgu2CL8s8C0qqFKj3BFe/akdIcUirHD4/bBsYerzBrRWAT
kX91kKeTTjrppJNOOh+G906c479+Wz95LGS6ZGlRpBj0DmgcObQ9WB8FLvJUh4NLrxZYOws8nbza
O2+A9xF7QFIT2Njs9NBZ46FzYa8iXzwD597kLeIMnO2+M+awBbzueS8M1kCvruwyJkPeQUGX8lyH
F/PjVkUUhpCC/rNfXAMfR2Dr0HAwG5nDjSWgbBT9bKfBMjFsae4BoPzgWy8wCRiuFJEC5B33EU9N
kGWUg9oxwKmtkW/Bk/w06e4ScM9+MzX2FKijMscXqAzuxKCrvi641//X40c2wItlj3c9HAhvyus5
zfygzXFM9W0N6hg+lacg7lZSSvwhSLziLOUcDJa2NlM9BPp1vahxBBSrEi8ugmzLWjMGPJs9242v
gQNMFc9BjdZqqwPALGAU1EeCPkkvqQeCYlP6KAHAUjlMzAHzvpnb3ACeI3KM3ANuKVdigOJQQsUV
4BeuiV/BXGc+NHeAGCUziGLgiXGP1E8ALURJsRcoJ07IlmDEyNVmFlAHq7HKHuCSGCbLg9nI+Mwo
DbK27IQC5jJjtZEN1CxaN20HyA3ymClAqSymsAu0rFpt9T7IoTJUdgR1v7jND6B+oc3ma9DbGV/J
/sAamRMfMJoYNY1IUDZrmnIAqMIccwfofcxLUgMlQpuvZAU9UHrMvcA0/bSsAXqI/tpcA0/aPPV+
8xZ4qGyRL0EsVz4xQ8F6x3pT/Rg8DzxuVwEwjhhdzUWgHlIba8tABkp/ExAbjbbKQDCXiqHUArUb
KXInmKPlp9qXIJ+Yr6QKET9GDY8tD34hvqW9l0KmL4Pa2eygZOGm9XNQ24tM4kvwJCWtSPwBtA7W
uz4T/urwTieddNJJJ510PiTvnTgXHBw6puJO6CfbNBseCt5+gQUc30BUv9en3+aGxOyRuX1vw90u
T+88yg+vX7/xfvkIlLXWvBlywC7LucKH+oLXFPUX78EQ+71n7LMM8Kqeu/lvZyDpl8SQ5EkQn5h4
9vVa8I1zb/GeAtl6Z6mWqQEElg81siaDa0dKB3d34A3d7U5QhwUfyaUBtVNmvt0HynnjmBEKenFl
mCgBygH5mMtAObOI0wPaQP8471hQ1dA5Pt0hw+1K35dqDW+9ndmSLPD8wuWDF9tDRO94jzMLpHwu
lmt+YCtjjjeeQfKF5DOJOsSmJI+LXw7upuYooxuovfRYqYNcKdfxE3iKeCLMruAZaTiNJFBmEqgu
A5J4Ql0w9niWG0fAfGPG6DtAG6ecUz8HEaYMFdPAU1bvoBcBsZkqohiI5+YLaQfZV8SJPmBkkiPk
UBBjGSjvgyxDD5wgr4g2tAJ1uAhAgJnT3COXgnysrOIZ/+f9oxtB7FCaiXMgdoop5AJ5XX8qI4Da
shU1QHNrm7QgEBsUqygIVGaavAOivMgv/MH81CxqNgExl4/lCjAmUJuV4Dnm1GQHMIvKazI7WFdp
K5VcYP5qjhAbgayyAWVArhDjqQ3ymZwvg4A+Mrd5EcRNuZmiIDOZA+UxMLtymZngWWjuN2qBulr7
VAsGidnL7ATmx/KAUR/kPDO7fADyW9lS5gR5Uq7RZ4PSR0wz5wMT1M7aVbCUsJRRAGr8n2/m6hX1
N+4uYFtp3aZmg5Rzru/EIAj/6E2XyFbg/dD+kbcLfEyv6KD14I4VE0QQmPk9ka7zYJ5MOabcAVrQ
8q8O8nTSSSeddNJJ58Pw3olzTpmtbpaf4Fyva4knGsGx+xdsh7PDi5Ex34b7g2NthkoxU8CvQ8Bm
R3OIUV4Od88Gn85eQ+0BkJDVOeNFNUjYZJ5NALI19+3jfwP8vvFPLpMAPvsyJjuygHDwWtqg7Lji
axtfhvuWOzku/AY5nheYkqcE0MNywNYSqKkXck4HLdY/NNPPIKfZFrEWpGls0KuDKCvuKQmgPJLD
jCYgC0vT8QxsZXJ3LVoHMizKGJzHAO+hmfbmnQHXJ6/+eclYeBX+ZMzTAxAz1ijMJ2DsFCn8AK6V
KSOTRoAepIyiOriSPA2NxWBuMqMZBfKp+YW5HMx6Zoi5BoyJsr3cCkYpM9RsDeITpZy8BSxlPIXA
7CMLmm9AbmWe6ABmHG9kKIiCsixrgRCyUxekD6VlViC3mMomED0oJCuCTDD7yVjgkJjAS1C6yRQi
gduimwgF+TX5lW/AbIlVTwE5yfyC6kAhBoo1YJzSA+VFUH9Ui4lAUF9aqioPQG6THUQkMFAOlX2B
PTRiMsjcpl3uBpooGeQaMC8bFc0nILMYJ0RnEBm1rkosWEtZQ4QN+NZ6RnkKSnV9n/wSjOl8Z+YE
OcV8q60BztCTGUAVspsZwGhpPpa/AKo8rAWD2I5FZAWzpyylDwQ5CjdzgOJmrJEdxBhh1XKCvlB/
QRtQCgt/kRtEGT41PwGRXWY1PwVzBA/FfTCmm6WMFiCK6boMAVM174nOYPygD5SlwF1NdMMCynqt
ppIJ3sZG+6YMhjc1fIPfxoDXVHuU106wvhRzvE5A8udimZkT3AdSDrr8/ytI7rx/oN67d+/evXv/
jkNCOumkk0466fzPpUCBAgUKFPjz27934nws2631u1bAsyvRi+MGglcBa3ftJ9CfGkfMLiDCYhda
DcgYkuG1fzlwfp3R/rIGZOrkzlGoBLwKS5gS0Q68H1qDrafg0fo3HxnLwHd+XPkIDSxdtfm6AzSb
l0juAe79D3vL9XB35Q2vbW0g47gsCXpDKH+l+sV+X0NykRRryjBQbWoRLweIhl7jMncHXshwWR2U
6gTTD8xjwiIygwwn2vQDsUE7GRoA9i6hz6yDIL7z83GPP4KrrY/nOlEG3n6TksEdC8lrmC+mg9de
W4CXP+jZxCbhD0klnDdSfJgwd38AAIAASURBVMCzSF9srgTRTiQpZ0CJVLNpfcFsp0917wflktnC
jAUlUi2u5ASzkflIngSyUYnhIBThFveA2XKa3ATYKMrnIE1ZVJ4B8Z2oqIwB2VN2kc1Aq22ZoNUA
Y6HZ3/wYzNlmPXMGqJVERhECyh3lrtISzJdmoHwBZmNKsRUsCZYetoKglzey6NnANIzJZgugnbQz
AkxptpJvAJhsZgIlXqmo7gNljHpNPQVGbqOj0Q3UQiK/2Awyi5lilAW5Xr7iEmCqlcVF4BthoS/I
ZEoTA3KBu4gJmEWNauZekNGijboCuMVRuRzkefmJ7AeUopVcAfKmURQ/ED+LzHpREL0URbkIVJD3
lA1gHjIvmDWBrCKKH0GMpKaxC+gqY83N4PmIOeZHIA7I5Wom4DCFzNMg9qpdjTkgB2ujtKVglDD6
iI2g1lc06QPmchmsJACdRV6egGWlqKDUBk9xfZxhg+j1MYMSS0FIh0B7ogV8enthfQrCqk8nK+in
9fLCBXTmxX9CoKeTTjrppJNOOu+P8r4dONe590W6oJgth81sBiXqlGiT0Bgy/5q9tPgVIiJTbriH
wb1+v42IyAjeTZ33NV+Q5/x6vT0PuRsULJC3HERGJJeWHcAszM3kbyFqSeKl+xvh9Z2Etk+/gOiS
ydtenoMr16/1PFYUvPsHl8rbCM5ytdr+ipCwNWLAo4GgWG2TLP3A+Fpm1F+CeYi69gpAHXqIbEAF
6ssjQGnq8gUo5c2VYiyYlXlgzgRmM90TBI9jz646GwXhTZ/4PrdC1DD3Uvk5aF/bHnnVBv893h/7
jAV1ufKzchdMf6nxBKzxtuy2caDUUS6rj8Bcam415oGyQdmoLAUtRCugFQalv9JBOQIiCxaegbgn
9omvQPlE6ap8BSK7Wlh1gCWLpaj1Eshn8pKsBpbiluJaTrCfsp+2XwNrN0tjqxts1W2X7AngOGfv
7RgJyiplh9YP1Gpqba0TaDc1XX0KYo/IRWlQDiifqWvBYbHNs4eB10b7PVsxsM+x3rHmBOtLdbjl
LCgTJEo7YKeRz5wDorb5g1wKlkzqVnUcSJPqXAQjSs7lLpjfMob1IB+bIeYpEIlUoToY9fRMMieY
rVxhMgrMI8Zo5TrIKvIcDUDUEnalErCIA3wGFGGheAPiRzFaTQARLnzETmABi1gFtKGzvAmiovhI
GCAnmIVkCzCtZhGlFSiqYrF2B0uytsXrDMgK5j7lLhhv9FLsBSaxWR0JzDbXUAmM9Xo5MxwMoceb
FuCIfC4bg5Hfc0x/AsbPnlBzF+gPjOF6L4jq/XZWYkmIeRIXntgYaCXtrv6gfal0ZS8YNc1Mepm/
OrzTSSeddNJJJ50PyXtXnB3D7BftYyF+q2taQiMIS+YTry7gPUG+0j+BzOGBDe3xEHJNG+i3ELK3
zGBVnsJvm+LXvF4M2QbYy5X+HIrML7EmWxQ8Lf383rXHkHgm3vQeBRqWGZbcoN6zdEoIBOWEa7Nt
FgQe9FP8V0LE49hCyXVhb/UD1ecGQ9vVHa5PzwNJT+URrSEoLUW0HAgyq3go5wEZiVY6A3tEW9kK
zHK0lX1AOaC01qLBUz/2elxpuKle6Hm2MEQNSQpJWgpJHjlM+QG8ejlaeIeAsle+Mk6DZ5zrtCs3
4BDjxVZQroiuigAlTqluhoM+331LvwXKOHFLcYJoppVWqwDdZXvxI4h1xBlfgbRzRDYGatFNnADz
C2khHEwvs4xsBsqPygr1Z1AV1UutC0IKUzkNhmo4jSGgdFN3Kj+B2CaOKWdBHWIxtF/BPGSWMs+A
Pt6oo98BbbY6Xl0ExjIzybwCTJb52Q+WCWoVJR7EMyVeqQxKfaWzUgWMm3p76QbKM1kmAb+JFUwF
MVUMEtdAm21rqfqA8dz50H0ZzMN6Jj0zKBUUb6UckGB+J6LBLCGyi4ogZsuSHARZWu2pPgMtk7pR
c4BMkvFmLiA3K0UoaDeVUdrHQBeBzAPMFMPVUSDmMIbaIGzKQNkJxAtei6cgeqkLRG6wXrIV9/UD
uQq7qAzqAjoodQCPXJB4CTwz3SNSHoI506ivmMBw82vzBSjb5XX2ADbRTzYFM8Bcp08Fdb3aQUsA
cVrmU4qC45hjiH0ZKOu1xra7kDAlKb9xDtyLPc2MAFCbqn5iH8gIafcsAdr81SGeTjrppJNOOul8
KN674vymW2RoyhawBtqm2XtCkAiOzNUCnHYlKu4yWLpQRI4FfZ11acoZiIh0fRuTC5L7JudJ2QPX
S79af/Ae3K/+YvT1WhAf/baOLAuWKMc4+33wcgSd9VkKbNIvqOdBdjR6Gvfhcf4H1udBkFAq5pra
E14eNi49jof7qx4NWbwEvO7Yb1rrgfkNdQ0nsIyr6hHgqngkTSCjXM6PwAqzjbkZrHMtNbVkeDP8
buVb1+BZx4c9Hn4Gb6PcJ3U/kIFiukUDm7/trdoUnBvcldzXIbmGrrm3g5lLXjet4F7pLus5BcZU
44BuB+205al1IXiW6RWNDSClcc5cCrZmluLKE1BOaF00G6iaWkO7CJZxlsaWemArZPncEghc45qs
BhSjhGwPDGQAdUHsEbtZB7KmzG48AOcvKSOS34KnmyfA3QM8RfWXRh/QDSO3sR3UMLWomgLKTXFR
mQ7K5+IOV0EqTDJvgbiijFdyAmPkGjkISKI4Y0AsUVK4CnKnCOVL0JZr27VToE80fzC3gtpYLhfV
wTbMWtI2BdRm2gNrDVCDNS/1R5BlZGFRE6TFnGguBzOcqeQC9ScGqQpoz5RmFl8QaymqfANmjGml
CRh7jOemP3j6ejrrW8CyQuzVCoFlieJtuQzWvdYvvJ6A+a3ZWBYGs5i+09wH7oEpdxJngvuz5IcJ
ZSG5ZlLd+GFgfORZqlcE79q+akAKZL6bJTJ/AQhcF7Q8xyWwdfTum2E9eAUENMz4KQTvD5maYyYE
fBfcMVsecPT1Hx/cF3yrBPbP3BQyHgtdGGYDyzeOVQGFwdNF36KWAsv3YrmxCLSOooo25q8O73dn
WK1htYbVgjaH2xxuczht+fQ80/NMz/NXS/e/hzJlypQp8w53LP6+/V9lr3/VfuOOxB2JOwJfbfhq
w1cboOqdqneq3oHKAysPrDwQBt4aeGvgLXg57uW4l+NAfio/lZ/CrFmzZs2aBTX9avrV9INKKyqt
qLQC+i/tv7T/Unjx4sWLF+8xmep97fSv5vfs8Z/iL3/ElbJXyl4pC4MHDx48eHDa378n9VP3qeP6
vb//W/mr/fR94/Gf9YN/F+9dcc52LmNb603IvCjrTt8gCP8x+n7MFXjmfrov5QgozdSZzjHgfqyU
SPka3raPPeg3HrwDlQ6OupDyo2ya2AhcdfRNRjZITvQUt/cG+4P4PHEhoPT3O+GJB6ODNkcdD+4U
09ecBcoF0TnxCSgfa42TRsHzrm+7hGSDpR/tmrppLrRrUNbXkQ2K9616oftESFzvPJyQE7TTtLBq
IDPIEjQH0Vz4q5VBjjLuuh7Bb6Uvlb10HqI6x5ix7SAh3v2KU2Apbr/hWAhqiLildITkMym1kz8H
Vyc5xwwEsiuRWk2wTLIM0nQwpxqNlKlAS6W7WAXW2dZR2jowV5u/mAfAPCrni4GgndQ2qGVAjpJT
8ANlvDJamQBylvzeWA2c5hmTQJwRx0U/MFeYG+RaUHuoXZRIsJbV6trmgzpXWaINBnOIXEdH8MTp
o4z9oAareZROoLiJFutAb2SsNrxBG6A91uqAkqAq1jygTVG9FAOMFOOxEQ+ivrCL6sAZDNkfrIO1
stoIkOW5xXeglBVVRUGgltyGN6hXxFS1HWgj1KVmIzACjcpGd5DD2GJeBaLwkt+AdlKLURuBGCSe
sATMfkYBaQUZae6Ux0FUYaLYCMSJEcpvoF5WnqqlwH3aU9y9ACxH1R2aP3gqu844X4HnqHHEOAfa
Te2q9guoNdS8wgfMsmYL/WdgsXiqeUCpo+XXnoKRz1wtX4HvVd9aPh5Qcwe+zZAX5DV9pXEELDWs
irYPvHxsObQ4YL55VD8JXKSTpwZYvlUmkwTqYjFLzQnWIvaF9gqgVVZuKsVBaS+GKa1B3a08EVMB
6PrXhfe7czT+aPzReDh///z98/eB2tSmNmwI3BC4IRCGM5zhf7WQ6fwDp7ue7nr6bzztr7LXv2q/
qSfcwy8Pvzz8Erp169atWzfI7JPZJ7MPTOs6reu0rjD6zOgzo89AD08PTw8PrK62utrqajDo7KCz
g86C+pn6mfoZ/JD0Q9IPSfDtkm+XfLsE5p6ee3ru6ffX+38av2eP/xR/+T30j/SP9I9gauLUxKmJ
8Mz9zP3MDcZ547xxPq2dp7unu6c7hI8LHxc+DgZVGlRpUCUIeBjwMODhXz2K/xz+aj89Ofvk7JOz
3z0e/1k/+Hfz3hVn/a4lybkQ7jV+9PqJFa5Ov7v07k4IrZq1ik9+SLkkk9+8hMiL0SUc5UF5IAJt
2yFyRVJn8yLE9I/L47cTPE2MNhkOgK134OdxDyG5oqdn4jJ4e+BZliQF4k69meiaAOY447ZcAk7v
lKlqZXiTGNsxrhlEdIguFT4e7uUNfxU7AFZcOtx0ShyE2+72OjIZ7FntrX3rgJnNzK93AbFW7Jct
QXmkfaUsBefDyG0RBeDJg1unb72FmNYpc13RkFjbmMpCsFZ2fG/rDe4xnvzGFUj5yb0oJRT0SpQi
EYwl5h5jKAhF3KQJmKfMxiYgOrOOB6Ad0PpqK8HST/tUk2C+MSvK30D/RG+o7wIjkxFkNAJZQ9aR
/cBcaP5irgO51Bxk7gI5QNbiZxC5hVs0BxbRlfXAGK6bScAisV5WAJYyQx8MIozdhgY8kq84BqKz
Mk/JBOoy9aHaApQl6ix1E1gWapu1mSB/lrupCGyWS0UJUAwmK9dBOCkpdgOjZArHQRYwx8k7oK5Q
WimDgI0oygMwpphLjXUgOoiBigKim+iu3gDchIuqYFlm2afVAyWzEq10BesN63XrSZDP8TJiQdym
vGwKMsj81jgPeqAer18DudZ8LuuDZ5MxxFMSkpa4puvzQV9mjMUP1DfqOm0CoCHEJ+Bp4mmn7wbP
bM8C4wTIitJubAC9u37Icx+Sf01uHr8RImq8uvy0JUQvjBoYPheSOyQ0jXwJZoKnaOJ2SMqS1DLu
DMTXi88e1x6SvJIeJH8Jzi9cYZ4nkFAgqXdKICQ4E6skjIK4q4ndE+PBc95o4t4FtlbqLPPWhwvU
g9EHow9Gp1WCm2dvnr15dmg6senEphNh+9jtY7ePTWsfGxsbGxsLI0aMGDFiBDTY3mB7g+1p7Ud+
MvKTkZ+ktRsbPjZ8bHja9n3L9S3Xt9w/Lu99qfel3pegU6dOnTp1gjtV71S9UzVtfa9evXr16gWT
J0+ePHly2vKdL3e+3PkSvm7wdYOvG8C+ffv27dsHrVq1atWqVdp4GjVq1KhRI1h2fdn1Zdf/UQ+p
lZBVt1fdXnUb2ie0T2ifAImJiYmJiWmViMZhjcMah6VVMlLH+Ud8aLmiskdlj8oO/dR+aj81rTKW
uv7Wylsrb638fXmmvp36dupbaLK7ye4mu2F+8fnF5xf/x3aplZvfs9e76udd5f69/f6ztJzacmrL
qb9f6YqIiIiIiICQrSFbQ7ZCn0t9LvW5lLZd5peZX2Z+CbcH3R50exDYK9sr2yunxUvnTp07de6U
Fgep6Lqu6/o/L+fv6T1Vf6l3bOrUqVOnTp20ePvp/E/nf/qbE/2f9ddU/cxxzXHNcaX1v2DBggUL
Fvzz9vgjf5m0Z9KeSXtg165du3btSlufmrDUf17/ef3n8PbA2wNvD3w4O6eypsaaGmtqQM6cOXPm
zAlZs2bNmjXrP7b7/yuUpSlN6TQ/Lb2w9MLSC6Hh9obbG25P0++78q7H0b+3U2oCmLpd58KdC3cu
DC8yvsj4IuO/3g/e108/lF3/bDz+s37w7+a9E2dPYSPcbyJ4oqLtlv7gncF0+7eEjNe9CP0RCoWG
bA1+DI6M3pbYvpDwROn7uj5oq6ylo6cDTxKHRGngKq33TGgCxIrvk51gzPEpF3cNfLbZ3Y7X4B2q
1rYOAUrp25y7wLbPt6dzJLhHu0ta3kJ4g/A7ykVwfpUy11kZtFr+jYMPwpKKWx8PnQUJc8L73D4L
2nDb597PwAzR+3iOA6e0wYo/RNd9XPRRWXj+9KXfiyMQE5sS7KkAxhulvHoGLCnWC5Y+4Ex093K9
huQJnmKuJiBKC6eYDjKXccN8BYai19ELg9mYVuY+kMWML83HQKxZ1xwAymDxm1BANJJjxGow85gO
MwdwgvOyHZi3zBtGBRBDRHcBqJFqiogAxaA6LUC+MfIY1cA4r8e4T4H+1lxjNgWZVXpkdmCIzMVK
cNSxafYosG6ztLUEgTWbRVqDwdrKUsRaE0QB860sC3wsi7AQ1N5qf7UFiMfK92IxKNFKOWUUqN2V
IGUP8At+/AZmf/OR6Qc0Jgs9wbwud8glwCZxgyNArJhKFdDQnNbcoPXQytrsYKtns3mngOM7R6Rv
FXC4HL39boKjjtdO3zpgG2Mt6LUT/Kr7HAksCL5N/B4HNQZjgpHBeArmde6yH3xX+E8NmgVaG1sZ
+36QRXnEZvD46O31UDDOGQVMF5iRZhVZGZyBybeTuoHna3dAihX0tq4cyZ+Cc3vCb7Ed4LUjYsrL
W/Dk88dLHtjh8XfP+z29COEtIhfGTof4Lq6tnkIQt9J1jngIHxjTO6UCRB5Lae4JhpjmSfH6aYgK
iuvqOggpp9wtjf2gPMJi1vtwgTox68SsE7PCD+1/aP9De9j6bOuzrc9gYe+FvRf2huMdj3c83jGt
/bQD0w5MOwAhz0KehTyDXS93vdz1ErY93/Z823MIGx82Pmw8fNvm2zbftoGJWSZmmZglbftFpReV
XlT695dXtFa0VrTCxYUXF15cCO657rnuuRAVFRUVFQXXll5bem1p2naX+17ue7kvVLpR6UalG7D2
/tr7a+/Dp6U+LfVpqbTxLL++/Pry6/DThZ8u/HThj/WyZvWa1WtWp50wUg/cqYl69TXV11RfAzN/
nfnrzF//uL8PLde3eb/N+23etKkF27Zt27ZtGwxYNmDZgGUwo8CMAjP+L29LqVmjZo2aNWBp+aXl
l5aHVatXrV61+v/iJ79jr3fVz7vK/Xv7/VCkntD3ZtubbW82sCyzLLMsS0vgI3ZH7I7YDUW6Fula
pCuUvVL2StkrMNx/uP9wfzg0/dD0Q9Ohu6e7p7sHsr3J9ibbG5jQeELjCY3fX77UC5yAgICAgIC0
C7CtIVtDtoZAQvuE9gnt09q/r7+WFWVFWQFLriy5suQKrKi8ovKKyu9uj99rV69evXr16sGBXAdy
HciVtv7s2bNnz56Fgh0LdizYETJ8kuGTDJ98ODunXiCtqb6m+prqMKzmsJrDav5++yebn2x+shmU
vkpfpS80bNSwUcNGaReajcIahTUKg+v9r/e/3v/d5XnX4+jfE1w3uG5wXdjTdE/TPU2h1rpa62qt
g+lHpx+dfvRf7wd/z7v66YfiXePxXf3g3817J872SZ6unn0QtNhvvXcTCHb47bN0AyWfudYoD3Gr
jCTHEdAamw9kXQgYpe3PkAVsi22rjEvgvKhki9gO7pKeHbFx4E5IyuabAXJc8uubOQHsFeRDvQFY
fktcoEaB46KR21YKLFMcG+VTyPA68yRrcQgOzlBWHwZhrqC53oUg+VyURbFCeEvntJQzsObehjZf
9QFik2RsdRALLEO9moG2S1amGURceN7wfkF4WyCmWaITYt/oO83ToGa0CK0viAminDIbkvKkvEro
AK4VeoJ7OojhRhPzF0CnplgF/GIOFuVAHcIXyicgrzFdvwRGVvNbPRKMtobH2AwsYhRlwWxkdpRr
QbEpCUoQKF+Jj1kFll7aAFEV5A8cVkqAmlu7YOkD4pYyQs0AxgMzO9OAUGLlYRCtRT2lCjBETFIn
gVFLLqAbyJnmVOxgbNHHeDaB8kZsFztB7aeOUUsDHanPfRDdRBvRGdSVqku9CXQRfuwF5Se1otoH
eKLECguIueIeTUDZwHkWg6qrczgD2nplr3ITxF1ZWgwGrYX1R+0qhE7LUi/ncMh8O3OzfF7gO9H/
WXBOCFgXnJixDoS4Mv2aowqEZA0rkt0PAq5lLBGaC0IbZw7JNQrs170mBCZB6I+ZZ+dpC8oyzaGO
AeOAPsc1CfQRngjdBPNr47T+LZjfGLs9h0CuMY6YV8HcwDSlJIjcxJlDQE8y/PT64FXC737AYbCO
svV3NAejvqxoVIekhwn7466B+3PnquTSYE43vzfWgGWf5YBtAjiaedUInA/2ZbYi/pnB/ES0cjyF
pJH6cdsmSFzvzsR0kP7K5+qgDxeoqQfIsTvH7hy7E5YvX758+fK0A8yM72d8P+P7tPanu53udrob
9Dzb82zPs6B8pnymfAZisVgsFkO3ud3mdpsLp7qe6nrqT9zCS02ALy26tOjSorRKX1mlrFJWAe2a
dk27BtHToqdFT4MryhXligIVKlSoUKECLK2wtMLSChC0MWhj0EZYP3z98PXDYf6F+RfmXwDzJ/Mn
86ff33/rVq1btW6VNq7UKSZNdzfd3XR3WrsWkS0iW0TCufnn5p+b/8fj+tBypSYafy9X5eWVl1de
DvO7z+8+v/vv95d6Qg0ODg4ODk67Nf2uvKt+3lfuP+LvK1RPtzzd8nTLP477HypYpShFKdjRcEfD
HQ2hz6I+i/osgtwHcx/MfRCmNp/afGrzf9xfjik5puSYAlW9qnpV9YLnGZ9nfJ4RFl9ZfGXxlT8/
jlRSb4WnVug1TdM0Lc0PUi/E/qw9/p4yfcr0KdMnrQL/Z/3i90it2D766tFXj76C+O/iv4v/DnZP
2D1h9wRo8qrJqyavPrydZ3SY0WFGB+jerXu37t0g49cZv8749e/3H7QpaFPQprRK7uZNmzdt3gQr
K6+svLIyvN3/dv/b/TBp76S9k/b+Cbu+53G0cebGmRtn/hv7RrWIahEFl/tc7nO5z7/fD97VTz+U
Xf+eP4rHd/WDfzfvPcfZNl67qpSGxOMuP0sLMP01P6sLnLP0V0YSaHbb7qSxIPfqZ+QsEGXMe855
4JULC+Mgor/xm/1TsA3SDqcsBtsE5UfrIkjYEjccPzDPupol7QZjitLKKzP4jggra4uBhDuJpb0r
wuujzldJfcH/qX2NuhH863HO+wTYb4QNjYsEZ6v4br6RcLFT+ISXK6BIhwOtlpaDqgXrNuy9DcTn
qkcMh/Ds96c+DYUYZ0qysyq4bupb9dzgKOHzlaMImJflQDkMnEOdMc6HwFO2iTNglJVTjKlALzle
eQ7mDnlZLgQxnI2sBA5hl1tA7jJXytbAG9FArgNxQHGL5aD10eprX4A535wtA0GVWnPtMzDHmEnm
PhD9hJcoCupqdYPSAsyz5ll5AhgrD5AflBEcUL8FJatQFA9ol7W3ojbob/VR+nMQBdV8agIoyaKM
mAnKNOWgeAO8El7qTeAL0Y/XoAqttJYdlEeGMC4Am+UrgkEeVrLIpyDKy75qPxCFhb84DcpxypAT
5HxCRBMQT4TH4gSfn/0f+F8B+3lv6bcT9Kz6OeM+xA2I2/D6KrDeiEoqD64fk8pGTQVhUbPYX4I8
Zd7QO4D+g17APQXU/mpY7ATwneKzz94fXC1T+qXYIaF8/BcxfcG85C7hmQVGUT3ENQzkx5Q324Gc
IKYqK4GrYpRyB8RRXstyoPsbn4lAsG3yivE3wbbA63u/kZDcLplIC+hXDX9PdQh86ufMGA0B3wR2
zxwM4ms1F5+CKKJhvw1aRUsZR0mQybIodUFL0oppt0DLa85K+QT0e+4eyVdBb2soDAG2vGtE/ff8
UOCHAj8UgHsP7z289xCuD7k+5PoQWHpy6cmlJ4HBDGYwzGEOcwBZSpaSpUDbp+3T9v1jf+KSuCQu
gfncfG4+BzrSkY7/vDzFzhQ7U+wM3N99f/f93XCx6MWiF4tCyZ0ld5bcCdYL1gvWC7C/5f6W+1uC
7yrfVb6rIPB24O3A2/B5pc8rfV4JQvaF7AvZl1ZZrVKlSpUqVWAHO9jxf9m//bb9tv122u/IHJE5
InNAzT0199TcA5ShDGUAK1asIKaJaWLaH48r9Zbph5LL+Mn4yfgJzJZmS/O/+YZk6oVPTnKS87/p
L7Wy+r68q37eV+4/Yk7ROUXnFAVPB08HTwf43Pa57XMbvGr8qvGrxrBp06ZNmzaltXeddp12nYYx
AWMCxgTA0ddHXx99nXbrd9CtQbcG3QLbcNtw23A43/N8z/M90yrS3Yt1L9a9GHzh/YX3F95wcOvB
rQe3wq7YXbG7YmE0oxn9HvoVl8VlcRloSEMa/jfr/yveCCKIoPf31w/lF79HaiJVa1atWbVmwY52
O9rtaAdXl15denUpTPx64tcT/4lE5l3tnDoV6Gj3o92PdocZZWaUmfHfJF6p7WY8nfF0xlNoNLfR
3EZzISQ6JDokGkIIIQQIeh70POg5vPjsxWcvPnt3PXzo46iyWFmsLE7r99/tB+/qpx/Kru8aj6n8
s36w1net71rfd7fvn+W9K84xXgkfG13AHKdmcHcDz2d6B+Lh1fbIYSnfgf5DklCzQWAl9XTwbxCa
wf+3RC9Qw43zYglkPOTTwH8KZGyY4QsxGyy1LLWi+kFISNAhS2Hw6uqb0dYHfEbb6rMdouYnnY45
C3pGP3fcMggZnHVaioQMH/kv8SoEynb7SGZAYt64zkwG52uXn2cAuI857qW0gnX+57us7wb7iu4M
XLIUXFVfrXnsCy8bP3W8CIO4Dm5/Tz5I3m18Y44HtbGls+VH8HTXc3sOgHOkO8U9DGRhhqhzgDV0
UsqDaZNzzOEgexMr+4L0kRfkQzBqmZFyAzBReaG0BHFU3aF8AXIRRfkSlJYsEDVB/CTf8Aj0fPp5
/TyYQ6SvfAzyqvxVngBjjTHdXAR4kYwE86J5zNwHspfsZfYAdZI6VxkKSkulragL6ih1gjIPlF/E
ItEV1NdquLoDlH3KPmUaKD+IySIfWEpZBlq+Ba2Fsl3NC1oRdboWBZqXVk2rBVqSFmMpAdZK1lu2
/WDZouW1+oGcJiJEGFiz2nytGnjX8Xvmew2sA+377DlANjCnmTMgMc/bpRGXgJ6e2UllQbknsmp5
gcnylvIc1BtccPcDpYJcYIwHy32ll1IQrN0sb1UVvGf52QMvQlCt4KsZV0CO0FxDCryB0ObZNuUF
shXNc/+jAMh+Oe/8UhUgbFquAcW/gix3cs8pPgcy/5h9XqGjkK1MnviSpSGXlm9hqTWg1rbmCqgA
PneCBmd0Qb7yHw2uegoCM4X5FboPjsVBb4OTwDvQr3dgIRAfay0shcB4xlq+BHW5tlLdDdI/qVXk
IUjMGf39i+8hpVPS4JQ9YFQ0FknvDxeobb5r812b79Iqoa1jWse0joGvHn718KuHcO3naz9f+zmt
feqcthUDVwxcMTDtqebUv8uWL1u+bHlaQvjPkrp9aqWiUFKhpEJJsLnu5rqb60JJs6RZ0kyrWK2s
srLKyipQ8UbFGxVvpPVz9erVq1evQv9r/a/1v5Y2JSC18vD/818Vxj8iy4QsE7JMSKs0Xbx48eLF
i2mVyZEjRo4YOeKP+/nQcqVWXP5+DvoFeUFekPB1pq8zfZ3pw/nJ79nrXfXzvnKn7vd37dUkS5Ms
TdLmLlqXWZdZ/yYBSF2e+jf1lnZqhS71wi3V/w7kPJDzQM60W92pU4bmFZ9XfF5x+LHHjz1+7JE2
/sjmkc0jm0O++Hzx+eLfX8+pb/dInVKSOlcz9Q7FIrFILBJ/M/4P5K/v6gfv2i51ysZ8Y74x34Ba
D2o9qPUAtOvade36H/f3rnZe92Ddg3UP0hKv1L+Zd2bemXln2napd9hSH2psl79d/nb5YeOjjY82
PkqTN9XOFStUrFCxwrvr7X2Poztf7Xy1828q81tCtoRsCYFSF0tdLHXx3+8H7+qnH8qu7xqP7+oH
/27eu+JsvxMaHlMWxEpPbXcoeK57dHsvSNztGhZngcDP5JOQRZC/VaYFmYdByC2f5hm/gzsRlu4v
A+F1/IMOZkawn1NK+ncAMVEkJ9eG18uTXhrDQDsXW866BYI6BQ3TzoG7bNCatyMhPPKJI+UkZGju
qOM3HZIq+FX2KEBCQi+fH8G3v59bzgZbx2Bhnwhur4jv3wyH2LOeSq9nwcny9z85UgCM7UlRlikQ
vi6+knMlJL1yOTwXwbSIHOY60KprH2tjwPmzntvdGDzFjVqeb0CfSRkxD8QwY5HZC2R9sYmtIFfJ
ScSDOd8caYSAslLJIXaB2dzsZewBfaT+tT4XtP7aQstoEMPEVVEFjA3GAn0mkFcxxREw8rr3mReB
60jqgNJbTBGtQeQXMaIhUJ5JDAbjuGxiZADzrlwrN4F8QknxE5jr5MfEgrpWfCHvAKuZxEgQiMvi
Dci6sh5vwTihz9NXgfKlNl47A8pN5ahwAZPIKk6B/EQ+k2tATBaKWgh4pIUoK0ETlsLWJLDMs71w
tAJ5XyywfgvKPTFOKw/OiUnZE1uB+RGb3dtBllLLWJNARCku6wLQNokn7smgWVWrGg5qK9shr2Ug
slueWCV4f+O9O6APqPW0nbZaoEs5xEwAszu9xVdgfeO90G8giCv4KQ1A7aO1slqBtuRgO8hfCZLr
QQkji2kDTbHcsw4F57CUpIQrYM2v2vW+4N/F79esP4M5galGflCeqcvVYiBHyrIcAWOAKWQ1EO3E
Btkd/KTPLOs10C85B+rnwflCC7OeA8fT4MVh3cES5pjjUxXEeDFEmQIM+zCB2vVU11NdT0Gvkr1K
9ioJSqQSqUSCulJdqa6EMYvGLBqzKK39qAyjMozKAFNHTx09dTQ0vdv0btO7aesL7yi8o/COtIdb
/ohCJwqdKHQCOp7veL7jefiFX/gFqHSz0s1KN+GO9x3vO96QOTxzeOZwcMQ6Yh2xEJk9Mntk9rSp
HZSgBCXSHn5JfZgw9Sn4UmYps5SZtr9ZC2ctnLXw/y+o/y7jx48fP348TPpm0jeTvgHnVudW51Zw
rHKscqyCL7N8meXLLH88zg8t16iPR3086uO0RHNd2LqwdWHgNdhrsNdgGJtpbKax/4LE+e/tNb7i
+IrjK/7z+vmzcv+en/wRm0dtHrV5FDCKUYz6x/Vn552dd3YeUJOa1IQbFW9UvFERbnCDG/9Nf6kV
rruz7s66OyvtxOvu7e7t7g3ljfJGeQNG5hiZY2SO99d36sNjk/XJ+mQd6mesn7F+xjR9tdrZamer
nUAXutDlw/nru/rB79nj99oVPlH4ROETYK9kr2Sv9M9P0fizds7RIkeLHC3+cbl1qnWqdWra77AJ
YRPCJkCv/L3y98oPL1+/fP3yNcw8MfPEzBNg+dHyo+XHNDsMnT50+tDp7y7v+x5HH3386ONHH6c9
TBmUMyhnUE745sE3D755ANG9ontF9/rX+0Eq7+qnH8quqRdg/2w8Zq2ctXLW/2au9u/5wb8b8X/m
sklZvnz58uXLv3sH3T8a+6DYXigVkHdXubrgjNIvun+F82fvvjh9FfzXew30Hg2ZSvuVz/oKzNfK
XktXePvi9ScRF+HuwsfF4+pDyMxMpyy3ofjN0HY5zsPTpm97uTzg15zqZj+IbKFNjB8K3ragIXoL
UG4a5eVCeLkqrpSrJgT2EoeyLgDzWeL45OMQOi3z6Ayx4HfLuivlLsSWSHI4XeDZqh2InQ65rgeV
qNAb8j8JctZxwPYrS3ovWQZXSz0r/uQ6pAyQHaxLIOxs1vG5YiAxOmlj3GZ4Pu1lvad7wcgn8mqP
wDxh2GQXQCG3vAGiLbdYBmaINM1CIPfJc7IbiJyimWgL5inzgLkTlBzqYKUiKGvFVXUhyLvGl/IV
4BB95EswP+MbMRnM4+Yt4xwo3+GkEVBWrhPNQFRSLooRIFzKPXSwFNCwNwDxWCylNyhjlAh5E5Te
ygF1Cyjh6lbbJNBOag/VfqAFa3dtnUBOIZe5AeRNmSKdYD9hv+r1BKyaLaNXa1BfKEXUkqBkVAdb
z4El0fqFLTMoMdpLtTMY+0VXtoNSRjy2HAHumCHmPXBFOKslzQZ2MdH4DBy97V3sr8FcZZxztwB9
jHNEyvegVdB2WAeDKGvZaR0D4gd1lXUuyAWsUruCaZhh5mqQp0WwpoB4rixX9oK52zysLwDnspRn
Ce1B8WGPjAdZCz+lE3gizEZqCUiZkJAj5hK4+nlSUgZAUK+gisGfg88PPonBX4Nrrss7pQjo58xX
yRPAskzZru4DSx7H8KDa4Ip2tXGvhoAvHWgLQTnAj56xEFsjwZ34HagbrM98n4GaV2lINCgHuabn
gexlMsbZfGCJfemVxcf//YGdTjrppPNnSa1AXlGvqFdU+L799+2/b//vvyX+/yqpd2xSK8jp/M/g
3Llz586d+wAV59czY3OrHjj748OwO2dB7nY/TRgFwf29v/PyBUX3Pamcg6g31vuRW+FSwrnIt5fA
p7zjtDgFtpayvNoaMswlMMMEUPP55DAnQO6rXqrlCrw49+xpdBzo26xTkrJCXL/keZ7qoOU2T3iH
gNcQVVrmgTuvK0GuAq9tAYPFEUjMI5a/ag6vfWNv64XAtsvWx6co+A43s/tMhbIj8u+p9gIMJbaF
bQrEZIs/njAOnF8aZYzaoGzWKoqPQexSz8kz4LK4PvE0BqOivkxaQEZqRU0Bcrk5wWwCMlhmlddA
lmewzATmOXlMRoN6S8xTLUBWDtMMZF75mCigh9lTHARjrNxsCKAGTglwV9YXM0FeEEHYQBmoHKMV
KCHic/UE8FTeETEgfeVpcxnQQpQS5cH4SGY3s4Kjl+2yVxCoU7UeqgrWcfYB3r+B30/+r4J/A3FQ
fC6doAwXfS0KmFaji3sVmKZx1TwJtt/sVvtC0PLZhtqXgXwq2luagpqsjlAFWM6qW7VPQI8zC7sr
gXAZddyfgKwkDaMaKFU1H9UN3md9R3sngjnQs84YBUSbHd1dQAieMxRsd3xaBnhAy6Q11YJB7an9
Yn8K5knjZzkMxFnRWN4BswXH5CTQ6+vtjGpg3tQvpBQCc7WrcPIRsNaV3sYtcD8yAokF19eehXoO
iFWif44pBEkzk4/GZAatP43lGNAVZ/ekX8GsnPmB2RHsxR0F7B7QD7kNuRVEGWWbnA+eTUmZ48aC
nCZ7qEPh7V5XlSQnmMvNAnpzED2sF617wZrZmOzcDMZY/Tf5GgKy+8zwKQVaX7zUO8DyvzrU00kn
nXTejd0Td0/cPTHt/bpT506dO3Uuv1/iTyed/0W8d+Kc/XXocmUAxHVzno7oBf4H1FVetSFDB83b
sRJiLMlZE+uDa5R2XP8Cipr5A30MSC5rLJH9QItXN9ungO1Nwi3LaDDLpTg9dSDADLjm8w3YU5yt
jMng7StmZBkFrvX2z9+8Atc1Y3bKKWC/p76jBYiFDIqJAGc5vYt2A7StSjFNgcAhwW2CToLzjtd1
52Awx8QMclyF4K/9rTmD4dfbpzsfOwzu08xnL+jt9e/N8WDZbC0q2gALRWsCwDPVGKgHgTXAYXrP
AstNr0DfWNAjPEPlXeAKDuEP9okOu9dFsA2z3bAXAzO/8ZveGzxHdOkJA+WeOkHtA0LSS/kFjHlG
e/0zUK4pH8tksNy1RvpWAdMqHpllgDUyQmwE7SdLHdsq4K3MwxEwgjxhruOgDhaljeKgLbN4rPlB
i9QqWHOD+pVmtWjAUkUoX4Elr2WcV2Mwf0Ua+0EbpOzWPgPRiZ6yA6jl1PlqIBifmRf17MDXPFZ6
gxgvNnAV2Caryxcgm8reelXQ2nBdHgDVYe3hKA1GrGytPAMxR22ingf9M091T3eQPxJDRbB+bhlq
KwqOw/Z21kvguqv/JOuDucxM0C0gB5nfGSGg/CZa4gIRzQPDD4yPSFK6g/HQ6Gm2B87JqjIX+Jz2
DvJ6CfInfYf5HURciLRHjoRox9uBrzuDu6WrauIjME8aB80mkHLJk9V8AeZSDiu+EHUxsmXECPCe
6zXQPwfY2jsy+PwGcWcTvonOCfaPvTzWkiCeqxPtG8CT4Drmqgm2saqvpSNYjuq/KucgOcaTJWk+
eOX2Key/AuLmJnRO9Aafy2qAZeo7h1M66aSTzl9O41eNXzV+BY1pzAd4W9//OrY92/Zs27O/Wop0
/lW8/3ucDyRkcGaBHJ2D1mUCfPLbCnk9hcSSarweBOpC/Tc1CjKEa7m9a0BQjhxXjc/BXt6eSakH
wY2zhIWdgCjVEh5bCF7neV3QehzyPPArVjwYMqqh+QOWQQan7z2XCRna25JCe4LyNZ9a6wMPWSt3
gudtSmt5EmxjLT9pvcErl62BOhNcu+1V3iyE6KaRdx8fgI8K5XpYciuIsYov9eF54YhLD/uB5yvz
huEA87ZZjZ9BfKnUV+LAzG3mEj1BidI6qa8goFzwqZCdEJIr0/JcPpClc64H+f0g7HCO0nl1COyY
8XnWeuDtDPQNXQ4+8zJ8nvkh+Kkh97M1hoDjoWVyOsBPD6mWfQD4N8vwY9gK8AkIqBviBb6dAvdn
2gK+wQGtQ4+D35XAmyFlwFHB91bgC3B84ds+6Cz45gsclvEweI3y/yE0H1gXed8O3AJqmKOZXy0Q
JawdvHOA9YC9hM8BUI9a4x1zwVrLds97FajjrE6HL9DA9pPXr2CuV2qoc0Aprx6x9gKlhfrCYgHb
AMsz2xqwv7BHOg6A0co8a4aBmKSV134EUVk9qOwFLcISpu4AESkilECwT7df8RoP3s29M/kkgN3L
2+L/KcgeIotlFygDjZ7mC9Ceikiigd3mR04V3OGu/HENwZkppXfiPEiqFrcodhA4O6S0TfIB5bmy
XJkDykptj3UUGAvMqe7KENI+4KpjGWTKF5w/sAYoA5TlNg3sT+2dHB0g04McPjmskPFqtvPZRkNA
w4DyAbvAz9uvsE8FsLywPdYyQEC9gFJBLyG4ZED30FpgNZQb5lHQ8mkXlRJgXlXcIhaMWaK/Pgxs
fay1tRXABEbTGPQxohcbwTOEnfwv/sRrOumkk87/VrK+yfom65u/Wop0/lW8d8XZ8rn+XcBYMFtF
H7U0gTdtXctS1oEWHOhMKQEJuTlg7AHjSMT3rsMQWNZroRYLtm3qL4oPxI6Vpx4ngiODfy+vQ5B0
wjk1fi2cX3LzwkVA+9I6Ue0NjgN+tfgUnOMT4vTGoJemIj+Dd5TPK6UGWOo4T3sFg6d98lN3Mrgy
BbbRGoBlUrKfz8cQbNHmyfZQoEDWLBUaghyUMlxJAW2veVRUAVdDvbeRAzyF5Qs5ABxN1VG8BJmf
1bIUkJtz2jjQzluX+30GRmVzg+cNeBYnD06+DrK1bCRvgPKjNsjaB9Rz1oc+WUBdqhZzLAWlv9rC
pYMcqN8wGoEoQ0OjFYgmak4qgSVRXeHtBXKt/MVTAszyZg2zKCj1hEVbDGYKRY26wCRRWzkG9iT7
p74WEDa53jwLhuRLvIHvRBFzLGgf/Z+3bqhTxSTZAXiNl8sA0YpV6ioQt4mSzUFrbjbTfwFTd8cn
zgIaK19aH4OSV43VBoAxWQ/DA2ZrGtILmCT7yUZAHblfZADjmtHAyAhGBf1hyiAw6us7GAbuO55X
zimQPDsuJjoj2G7ZZ9o6gr2bvZ/jGHhr/tuCe4LwE9O1KaD0Nju4RoI5TO4SucG8LPvzKdgmqRmV
Y5Bc3lXF0wdirHFbEpIAp28zx1Sw3FZ/UReAzwXf4wE3wH9/8A+ZroDq8HodOgiUp1ooDUH9yDbE
Ug7UucZICcjaopScAsoczccSBRhqP8dQ8ASmLEnaCs5zyU0TbBA42bep7zZQ86lFrN0geazr++R1
YLQlQt0HegHd4BtQ86iV7ALUZdZZFAIKazu0vgB0+quDPJ100kknnXTS+TC8d+L86nL0zwnz4fFY
9XB0G1A3+xbhc7B3Sa7r0xFML2dXeRQSt7otKXFgOp1v7B0gdILjSQ4viPo2MebudchTxdbVngeS
M2hVtawQO86V1+gERmJCt+Qj4Fs0W0/3RHA0sv/iug1Jx69NdO4ET2VrEU2H0DW+bwP7gVdz6tnX
Q4b26jqv45D43N03ohlU31bKVfc+5NqdYUiBjfDEfufF3UzgGiCvmgoYoWKEUQiMlazS74CsZQ7V
DoDMI4eKuoBT+Kl5QPnYssRRGWQPJYd2C2wlHHN874NnnSe3expo9ayhWlVQKopnWn0wi+mVUuoA
AUQYDYGvzUQxGpQ7aivRFggXs7WeoJ201nf0AWODjGEXWPNYJ1sUkHf1eOMeyJ+N1jwFza2tEivB
/bN+ITkCzDnyuW0IaNMZKn8G2doYnFIJPOXM657e4B6vT3BmA1FPOSHngX2QbatPb3DOcIUljwQ6
KbmoC9q3tLNFA3m0zJ7cILyNrnQDVVcza8PAGGy4PO3A/FT/yPMA1OLMMu+As3ty0cTGELcursrb
w+Dq4ZruLAjGcr2aMxdYs1jaa8PBNd11U5SEpOC44coIcN1xjUvpDqZbMWxTgEZmP09PSKmfGJ+4
Gnxf+p30XQK2p74EHQLbCts9WymwBFlyWUzQj8gKRmlw5HP0s38FWj1HV5/HoP8gj5Edgh9krmWd
Ca4lyXs8n4OnuifSuQlEuHB5SoKrbUrNxCpgTuCkOA3KJuV4QmtwVU2pnVADfMsEDve3gFd/n6k+
ZyEpX3zjxDsgjhkJ+jrQ1ggrAeD61GWjLrg/TTkf9wBMt5qRFPAdqBb0zvwngyqddNJJJ5100vmP
5P1fR9fFq1liA7Cl2As6voCUWL23uR/869nqeheHPPtz1vMqBPczP78V/Racp5N/VB9DYgtncMR9
sO6wb1TCIPZwYpC2GfRGKXOMO5D0UCmakhUc+dQividB3H6+JdkO8R1SXns08NzR9/mcAJfdKOHM
CNmTAna6H0GWruUqBG4C5bKjSczHUKS33rjsUyjToMCotvXBq5RP0ZBIsJ+S+v1wUFtd6S6egb5S
HyzegLrfzC5ugtFWjHJPAzOrLGb2BdrINUZ2kCvM7eZ9sHxrya81BvcAs49RDNR69gn2GFC2afUs
n4CYb86Xu0B01DN7YkE/aXQ2b4CpyMn6JVBvyoyWfmA5af3Fmh88Gz39jInABrFf6Qf6CXcLfREo
bcikrAHjU8/LuCXgLpqS390R1I7qW69JIMpa8ymHwCzriXR9BXK8kdtTA4y73DCXg5Jdppi+YL1t
WW8dD05Lim+SL+hheuXkQ6D10NZbQsC9zrgqvwP3DtduTx6wLtQU2zhQLivF1bNgLNavug6BvaDl
uroPnDGJ/eOnQ2LHhCbR48FcoC8xHoHew907+TdQXUqM9huYhcgtLoPeQz9k2EE0kUM8WSF5xpv6
rzSwhXqt9X4Kyn4GCw8Y4Z4UTxxENXr7NmUXeLXxjDICQZttqWoPAGWkslNbDraOtglWOxj9xFJt
GMSXc00yRoAZKH/DDZ65+gRPJtBmWbdrz0HsM75WKoD7a8+v+n1w93cPdY8DV72UsgmHQc2k7bEN
AdWjZJSNQP/CLd2D4dWa1/feBEBSYLwS2xys+dVyMg/Y1tkf+HQHS11ttLcXuMqn3E35FrRnamcb
oOwyz7vKAU2AD/Ce2HTSSSeddNJJ56/nvRNn45y+0lIcQm46itpNeBmb0MqzBTRF2h3NIaWVp7d5
CFK+ifnJIsDvil9uvyR41Ds84/Nn4GmZkqh2AV9v33l6B5Cq+UQdAeKR0SF2Lpg71HHqQYj+9uUU
pSKEfh74s30Z+NTIttIsB8rDhP5ePcG3jTU8UQNP7qfFzYnQvm6jipM/hbw/56hUYzq4/fW8fANq
LqWfkQHEiehJvi+A3W+Pe/KAtZ+lrPURGCvVx/IVKDeMLlpnEPsZLE6B+dAc5TkEKYcTLkRVBj3Q
XdkRAEpvJUqNAnOz9sLeAMyn2njbTyAnGlVlAbAttte2lwRroDrN+g2k5HW2ij8NsjFD8QXPDWOv
cRxUYemlZQcxw5zg7gVmLXdb1w3AobZVR4IzOfF8wh0wGxkP9MdgjbQXlrHg9iQ+elMJbPPt1ewv
wWeqX5fAXqAeUYpbVoM+ynho2MBdx73OWRDUZ5ZYZSaI0lwzDoEyX1tquw+eZtKRch20OjRT2kNs
o+j9EclgqaPGK+fBzGTe169DyiJWSQuY1cxpRh5Qv1ETVF+gM2eVziC6iJ/QQS9sjjROg+qnXxBf
gqeOvsDIC2ZTc6dnGpiR5hMxBMxwVomRQAnqi9VgvWHZY/0cjEeckBHgGSKvIkEdJBoo00EmS2RF
kOFyt5wL7iauGM9cMFsrEYYbrKOt52yPQQ9w1zDjwbVULxM7A0SEvsVTHpQyanfxBLQZwqVlBm26
f9OgCeAVEOAKPQI8Mr+Qq0CO0KfrVcAs6P7ZmAyOOV4bMEG4qeAZDbRXfrUmAY3FCrEVfHP5Pgr6
HjyHXPeNkhDf5a399TAg9q8O8XTSSSeddNJJ50Px3g8HavXtN+VRiK9njI/sDfpq92nXBYipGJ0p
pRvccN8blpgLkhrYdlAf3j5213s5FcIyB26RYZCpcIa7ylJIeuM1NfkesI+VshMo3VR/yxMI6mI5
7JkCtmZqfnMcPKmaGBB7ExLGJgXpDnB1ZKarJBR7Fjqs1nPoX6zVzHW3INfE7HlqrYDkx85HHh9w
Z/V8HPczvHj0otq1ZRDV7HaW8KGQMdn2nVdZsGnqTNUGymDlFI9APhStjPMg1iq7lDkgNTOCpyB3
G831uaANV9dan4HXbt9LoeHg83XA1yGlwaF6J3vXBetFL7dlNNju2z5SS4BAeiXeAccv/kcCSoHP
fb8qQS3A64qjmi0n2AK1+XoZUIcg5K8QPyLuk7cnILFM/M7oqqD8rL7U4kFvoM/xOCClbHz51w4w
9+j1PY9AThDhqh8YraS/uQr0kXoP50Uwp7NePgB7WftFR2XQsltqW/eDdtxy0HEa5E3lF8tbkF+J
WIsEd09nVfc40Ot4BrrLQGKWhEdRl8D5KiVDfCgk13dOS6wO8pnQzdVgrpX35QYQjcUW6Q2coLnY
A6aP0cJYC+ZkI8ijA+P1Lu5hYPT3jNBtYL4yV3iag+eQZ6arE8hAs424C67SninuumAdYr/i0w+0
7cpX1o3AS+khG6g7tLpaF/Cc13vqP4A73L0uZTSY/Y0Y/R6Y5fiOimD51TbSEQHqKes3viWB/fYL
lmdgL+2V36cWeC0KeJ7hOXhX88sXkgVsPS3xtgJgmWB5besJLh93PuNX0AYoTdS24LXJ67G9JXjn
8W0RGAX+1YOswV3AO8q/ql88WNrYm9hOgHZQNvcUAnW1rZLlA3385D+Z6Xmm55me5x+Xp77H9N9F
6pe8Zs2aNWvWLKjpV9Ovpl/al79SP2zy4sWLFy9e/NVa+3+H1atXr169Ou0DBqlfgBx4a+Ctgbcg
KntU9qjs/z55/tV+9Xv+/D+df3e8/rvY+mzrs63PYOrbqW+nvv3H9f9p/p3O/xu8d+LstNlGxe8F
h2/Aee9nYHniXVK2gsRIo1yMCVGfR//wdj1kXWRJ9D8PsRXiCyrrwSeHbX/mHOCd3f6dchHy5wh+
6hMN/rHeKcoiyNnbt2/odNAStELq12C5IldYF4M2yePyLwhR51/fS2wEH80Ithb4Etrc7X5v6lnw
mhGsZckLrh+dMYlzQOSQkXopiLv+Kuh1L1A7e+77XwNlTUKYsQAyxWbW/TaB0lg8MCuB+lR9bHsF
cojR2tMCRJispn8C9kG2p9bZ4D0zcFZIZ/BrGNoty49gm+e3yDcjqAm2p7YzYOnicHqtB98LgfaQ
5eDurs9PegWJXnEXXm8D9YJnfmJncPsn141bAK7BybniqkFyicSv4w8BFrnRPA8+um/VwJGg3lLn
sQGUO9blagOw7vByOfzA/pVjr1898FkZGJMxDLzzePv4nATZU3cZm0DmF/3UbqBt05LU/WDWMnt4
akPS0KQR8V9ByiKXTC4J0fNf939RFl6ee1Hg/gtImep8Gn0AXB85y6YsBH23Z59RA8xNxjGzKLBG
LmUzuEu4Y91TwFPao7ivgGE1Sui5QemnhCiNQFQWFtELzLaUE78CzZVYZRYQILaINaBNVftbN4J6
RIwSXuAp56mU/BEoh9WsqhVse225vK+DhlpJqwGiqFBEMijztUbaEVBT7KvspcD62NrNHgJqD7WF
MhpkXf2A3hDEaRnnuQuW8bZk1QTHAa/iGQeB2USZrbYFpZ11vj0crBktgfapYGxyX3I/BOfXiVvj
LgHV5VzPS6A8o5xdwGVxNopfAsl7k+/FtwTXCefFhJrgupQ0OekVmH09O1Niwdbd62vLRxA8Lvh1
6Hd/dXj/60n95O1fzcnZJ2efnJ12IuxxtsfZHmdhwNIBSwcshXPzz80/Nx++bfNtm2/b/NXS/udz
7NixY8eOpV2IVP+i+hfVv4Cha4euHboWTnc93fV0V5hRcEbBGQX/amk/HP8p/pzOn+NI2yNtj7RN
uwCadnDawWkH4dLCSwsvLUxr97/Vv9P5MLx34uxtuvpmnAwBpo81xx0IK+t3Kqwh1LqXY02ZglBv
e/XH5c5C0LDARyIFSn+T91DWziD3a3UMN/g88v4m6AE8y5s4K6kZxOVK8bY0A6OMGJ6SC5TNYp09
GTIuDyiQqQ5kvaX6xlSFBlcK7igxGHr49rk2px44A2UHswoY19yPUvqDNkeLsZ+AlAlJxeL9wdHT
vkQ5BzHRz/O9LAa2n6x2axQUGlQqsrQAWw/tR/ERaEXFNksVkM3MCDqAESkaqt+DYmq/2leCsk15
JO6CfGlkc/8GhrfbntwFjF+ddRPegH7M2SqxJrizJDdLbAjSMDJZloPXfG8zaCW4Mif3TboHKRmT
38YZYHynfyTPgtJCqWctDa6bxpiUMaA9sq3SnoNXngBLcALYLng/850Mvg+C4kIfgiMp8JfQxWDZ
YXvr0EFP0hX9UzCHGheNJSBM85H5DTDRKGFUBLfbud45Aqz9bDUsNUG7ou2wxIPvuKDtwX0hrGZW
R6HR4DvE+7fQL8H8UR+ZUh+Mj4zNngXgGugOdN0At+o+62oGxjZ9sX4CTI+UemnwDNe7eCaB7mMe
MgCjGzXlczBS9CXu2WC+NC6514CapOwRM0G5pu6xtAQtlzXWZzX4BmWolPE1BJrBn2XNCNam9tm+
BUAsss/0+gLUzNYwWxxw0fhODABrJz6yjgCZTUSpm0BOwkvNB+pj7bjlOMiS8oi4B8opI6/+BmQx
zxCPBlQ06hq/grpFKaFkAOLUz+25QZ1qvWlTwb7e64T3OAj5NOOcTJXA3s/xjX8Y+PTyPxhaEfzX
+F8JDQElSmvkdRfENTWXZR5Yr9nOeLcGc6020pEbLIXtG72qfbhAjY2NjY2NTftkaoPtDbY32A5N
Jzad2HRi2idfU9vt27dv37590KpVq1atWkHz7M2zN88OjRo1atSoESy7vuz6suv/uJ/fqzz9/fKx
4WPDx4an/e59qfel3pf+cbvUSk+T3U12N9kN84vPLz6/+LuPv+XUllNbTv19+eyV7ZXtlaHN4TaH
2xyGzp06d+rcKU1Pqei6ruv6n7fDP6ufv18+o8OMDjM6QOOwxmGNw+C7I98d+e5Imt1S35s7p8ic
InOKpG3/Z+34vvrc03RP0z1N035/Vu6zcp+Vg/L9yvcr3w/2T90/df/UtE8Sv68+556ee3ru6TR7
dS7cuXDnwvAi44uMLzL+43Z/5FfvGi+/58/v2k9ERERERAR093T3dPdAs2bNmjVrlmbXP/KTVbdX
3V51G9ontE9on/D+cfyh9ZqYmJiYmAiDBw8ePHhwmj+n3tFJ1cM/O74P5a+pnPGc8ZzxwOtJrye9
npT2BcS/yr/T+Z/JeyfO/jn9D3rlhMTIxJMRq8B9JeluVBvQL4LnRxg7qGvSunLwaetGu/uvh5CM
vn4pyZC3d5a6mYdB5gXaAN8zkKmhVwvrCsiQPWMn4xS8MtyB1tvw7OPEe1GTQcnrKn2/L9RXy1ra
1YDOHfooc4uA0ty/hJ8AUcLzjVoURFs1UL0J+i05yjgF0s/81P0Ukvp5Fjt/gNger95EjIQc35c4
VfUNeC8MyZF9LDgSLGu1ULDn0XwsAWB0ljvM+aA48DY+AXWi6CdOgOtxcj3nW3Dlc+7Xn4Ocb97A
Cbp0Bbk2gLTp1TyzwNinf+u+CVo2scHoC+yzVnbEgHbX7udjAQde1fwcwMfWs8ohsO5wVHEcB58Q
v4SgkuC46L07YBLYxtl/8IkAS7isJ3KDfjflN9dcEKO08hYPqPusdR1VwIKPLSgIrL/4FAg8CWKA
us3yFbjnmKvV5mBp5hXvXwKsv3odyTAMvKx+/cJOgc9h3/wZC4JPh8DSIcXBq23guND5kGVg7kkl
v4KQxCwLcodD0M7QEdn9IGhb6MnsP4NPu8CoTNXBUsiW5BMASqKlrvcc8K3rfyC0PAQuzFAp63Vw
9PZZEaqB76OgvNl+geC2WUcXXg7BubO3LbYJgkSmoDzfQXDW0JF5n4C9lfepjJNB1FbKqMXAUls9
Lj4FZa70Mn4FY69RKbkkpDxN6Rj7GXi+SukWPxeYpddwdgIj2N0uOQyUrDLArAlGDX29kg3MbAS5
F4LZQpazKOCu4M5qRIFnrfunpJ5g9HW7UyaBUkAWNOuAWMhd5gF3hCnbgbuYa5e7Eeg7PFH6apDZ
Tbc5BxRvZYz8EfT8rk3GRlCteItL4JXDYpERHy5Qpx2YdmDaAQh5FvIs5Bnsernr5a6XsO35tufb
nkPY+LDxYePTKqpr76+9v/Y+fFrq01Kflkq7Zbn8+vLry6/DTxd+uvDThT8vz8QsE7NMzJL2e1Hp
RaUXlf7HdjVr1KxRswYsLb+0/NLysGr1qtWrVn84vaRS9krZK2WvwHD/4f7D/eHQ9EPTD01PS2Cy
vcn2JtsbmNB4QuMJf8EXHWoPrz289vC0RGf98PXD1w+HttPbTm87HZb2W9pvaT9Yu27turXr0rb7
V9vx93j+4vmL538zpaVbt27dunVLSwTbtWvXrl07uON1x+uO1/vvL7hucN3gumkJTa11tdbVWgfT
j04/Ov3oP7b/I79613j5PX9+136mx02Pmx4Hnzz+5PEnj2Hbtm3btm2DbHuz7c2295/Xx5rVa1av
Wf3+9v/Qel2wYMGCBQvSEtidL3e+3PkSqq+pvqb6Gpj568xfZ/76z4/vQzN6y+gto7ekXaj+Hv9u
/07nfxbv/XCgWBt0MGoZ2CtZdgS2geSNsTvdL8D2kgUOb9g9cdeIWcfA3OLskTAS8j3NdKPmdLAm
uZa5h8Nj3Th5czIUuWUfUzUMkr8R7phKcDTsQvXoXFCgYvDonMOhy+oubb/KCZnP5Vtbxgbuvp5v
PT+D3sW9Q18CyiP1jTwFSg5C1WjQ13nCnAEghpmRhgd8VtnXB1WDvHfL/Fy1EPjty+IVWByS2kbO
ck2GDI0C9vtWAK1u1I/J/UDWc61zuUA+NtdSBpQb2jB1MIg5KYedRyDls4Ta0QvA7bH28DoBlmLa
K+aB00yZ4VwHWgPtmuUaqFHyqswJ5ljpMuqC2CWCxVbQX+l13L+CxWq5ZnOA8aVzXcIa0L9NijWG
gNDVp9o6sA6y9/D5CcRQ9Y6lCKgJth+U5aDf05e6+gEVjRvGdGCB/M3IDSJcCdWWgXFPvlXHgZJX
OW2MAvERzzgExiN9j7gKSrC1o8wC7FXOqNPAnKPnNu6Bdtfaz/o9eGezbAidAV4tzMiQJFB6WHzV
1oDHPS/lGnhmu18nfQ6cNybLz0B1a91EP5DzxS9KGbBMUcaJVSDd8ifjMhi1pSJKAQhdrQDSj+dK
R9Drm20pAkYL3cvVA2wFrS+VosBNo5vFBCOv4XSVBftNLUyTYHxhPWxvAMpefE3A/omlvpgLxiXz
uqwDutRDzCgwi4koIxiUSco6yyhQy2gFHIGgmuKOdh00f6WWHg96Ic9r9xAQ6/lSDQettJrd0g9c
n7iuGR3BGe2+a6igtFYaWOaAoZoF5HZgqnSKGyAqqx779yCuWqqZPcHbozbWN4HdsHZRY/4rSNq+
f6Ce7na62+lusDPTzkw7M4Hyi/KL8kva+m7tu7Xv1h4adm3YtWFXOJrvaL6j+eByn8t9LveB9bHr
Y9fHwr0L9y7cuwBmQ7Oh2RDoSU96/usOMKknWEuwJdgSDJ56nnqeesBFLnLx97dLrTA93fJ0y9Mt
v99vKhcvXrx48W/6yzElx5QcU6Dqrqq7qu6CXzL+kvGXjLD4yuIri6/AaEYz+l837H+g+Lzi84rP
A7FYLBaL/5vlW8VWsRU8ZTxlPGXS9LO0wtIKSyu8vx3fVZ+5onNF54oGgggiCAatHLRy0ErIvi/7
vuz7oOMPHX/o+ANMyTElx5QcsJ3tbOfP0zhz48yN/+b1jS2iWkS1iIKfx/489uexwElOcvIf5f09
v3rXePk93rUfWVKWlCVhYtaJWSdmBe5zn/tQd3PdzXU3wxSmMOX/oofWrVq3at0KlNvKbeU2LD2/
9PzS83/e/h9ar0fjj8YfjYd1l9ZdWncJ6EQnOkGLyBaRLSJh6fyl85fOB5rQhCZ/PL4P5a9/H/9/
hF5cL64X59/m3+n8z+K9E+ffrL+1dGuQNdqvjdEO7FOVr8x5cGb9i4KXT8PxVo/bH9sB+a4FrQgb
C4XG5b1VeDu86Y7fq9Vwpda982/mQVZH5vZ6EuBI8nF64KMi+T/LOxHaZWm7YlB9CLRkDiwVD66t
SZOTD4KRaHkrz4LSRlzVPgf5jbnKqA9KQS0nvcBo40xIvg9M1V5ZL4FyQFnjfQCMy85Zr+eB5/uU
L20TIPhumG+OLpAtIdu8rBPgovnkh6i9oJxxG0pzMDuafcxE0OpYyti+BbHPk92zGNQM9omWRmBp
rHQR0cCXcrkBiJ0UUp6Bpllm2DeBOtfR1ustiJp6R48AZaQ51LSB+NmpJ1cDTy7XM+ccMDWznWcZ
eGz6SqcGWrzaUVkN+msz3LwElsqOlt6FQCmp3tR6gixidpOdQL8jNJkfZEWjuGcx2MvZZinB4Jho
b28fDjJSqqIbYJV+Zn9w9vPMSTkGejFnQ9EalNrWivZhoJwXd9UtoK2jHVPAesUWKcNB7GC+GQKx
zRM+TsoKvDLeyJWgXdGirIdACbM2Uh+A8YVzcso1kLvM7a6ikDxXPOIgqIY8r2cFy271gFYQxHU5
1cwC6isqGK1BeSDLG0VB9Vc/d9wGr2RthFoTxDTtiXEIZANi1U7g/5FfkYBocGbTy3EDjBBjm/kI
rBntG7S5IBfIfMYY8LR0LyIFXFGeFa7vwWG3jdOagDgpTOUB6Ps924w+oJ1Qa4itoOa39bDbQTyW
eeRbEJ2VMuINeCfKgspvEDjR+4jvcHBu1F8ah0AvZzqVr0Dm15/K0qDeUKeYC0HLYDtiKwV+xy3n
1JFglbYgUQGAzz5EoMpSspQsBdo+bZ+27x/Xi0vikrgE5nPzufkcBpuDzcEmhOwL2ReyL62SVKVK
lSpVqsAOdrDjn9ive657rnvun5fbssyyzLLs3bebU3RO0TlFwdPB08HTAT63fW773AavGr9q/Kox
bNq0adOmTWntz/c83/N8T7i18tbKWyuhe7HuxboXgy+8v/D+whsObj249eBW2BW7K3ZX7IdLnP9Z
/fx9wvxHy1NJvSX+vnZ8V32m3rJ/3Odxn8d9oGKFihUqVgD7bftt+20IHBA4IHAAvGn+pvmb5h9A
kX+HslhZrCxO8/u/54/86l3jhY50pOP795M6NUA9pB5SD/1Nu8visrj8x+NO1W8qH8r+H0qvkTki
c0TmgJp7au6puQcoQxnKAFasWEFME9PEtH9+fL/Hu/rruxK4MXBj4Ma/zr/T+X+b906c3RvjvrPk
g5SDWoN4Haxfi2kBJcA+1GhivAW/77wX5xwBb/MrRw1/uFHu8cNbiZA5V/DNgJngVz30M5968GaZ
O+R2IlRZWLBMvVbQocDHiYNjwBrmVyR3BHjWp7xOfgDKLdUhCoEWJn9Re4PsKbPp1cHcw0vjJCh3
mCUug3uF51BKBHjN8YsIfgKRQ15meHUHLPMsLQxfsHbyirRPBMVtaeioBGErs1fMsgu8jlpf3j4K
CTfcbW39wRgvF4sE8HpjzWsrCwnH4grFzQNinNOd5cEyxP97RxK4/F1Z9Nxga2EP8GoIjBUfkwlc
s+PKvHkItnr2X3wOg9gismpfgzbTMs/+CsRg9WftKdiwBdpHAg/EblEOxGpjgJEVjO/1Cq4JoOZT
gtQIcGdz19RzgG25VkWrB+q3VqvNBPmJ/E5dAxQw3uiNIGFQrBb1EqhqHHT1AddhvZK8CfYXPpf9
4kF7ZvvepwVY6lg0bStoxdV71lvAUnO9HgBiidzi/h60X8lgaQWO41oZsxDYGtsviuvgdc/rmVoS
1HgZ7skFcrD1tGqCu4Zrs5ELUryM3NIX7KO87vvmg5SLnrbEgWct3yvHwHVR36p7g62Fmk9tD+oD
9WfLxyAXKpPkNnCkOA7Zm4D4SdZTq4FeUoZ56oL/EUcWSxbQGqidrKGgrza7MxLEQ1FBMUDOtqSI
T8HzWF9OEFh+tMzUEsGsblaUv4AywXHJcgI8HTwbnCVAbaqNVlUQ1eRymR3MpuZKIxhEJuWtKkHJ
xU6tEHhnI0YaIMoz2mwG1oV8o/wC7iB9iXkPXDfM74wwsD1V7stvwWukNZu1/H8FycfvH6ipb4dY
MXDFwBUDoZ/aT+2npq1ftnzZ8mXLocqOKjuq7IBTc07NOTUHtl3bdm3bNchwJ8OdDHfg7NmzZ8+e
/ZuOS1GKUsBlLnMZLNct1y3XISoqKioqCh70edDnQR9gBStY8fvypb7V4o8SwX+WLE2yNMnyNxUr
61TrVOvUtN85c+bMmTNn2u/bUbejbkfBvOLzis8rDkndkroldQO/yn6V/SpDpCvSFemCwrMLzy48
+8/L9Wf182e5evXq1atX392O76vPaiernax2Mq27WV1mdZnVBQIWBCwIWACR2SOzR2aHatZq1mrW
9x/nzlc7X+18Be1pT3tgS8iWkC0hUOpiqYul3qGSmMq7xsvfk+rP79pP0sKkhUkLYa/vXt+9vtCC
FrQA9rfc33J/S2Ayk5n877P/h9ZrlglZJmSZAFOaT2k+pXlaPL0c93Lcy3FwdsTZEWdHAPvZz/4/
7w/v6q/vSrU71e5Uu/Pv8+90/mfx3omz1z2/3MGzIUs3v4I5C0LJCqGf5KoDgZf9D3p84Zz529Yn
SXBpVGSr22dB3xxa02sjBBnuUW5/KLzePc8RD3W2NRw9+ygUDczXo5I/OJeIcV59QQwV31j7gowU
C/W6gCI3kQzyI1GGYSDay6FKF1CDlelqCdDjZDMlCRytbLN9OkDc49cnYl/Ab5euZTsTCwUHlZpT
/g2oGbTntlUg94O4D1l2ZWuQdRV4B9qX20+Akjmln3MWMM04qMSDJcKSwTYXrAn2TY4NYBS2jFA/
Bb0cEeIyeFt95vmNB32PJ9xdD4zBen9PfnBk9Qr3XwueoXokP4BSVXupdgO1vCWSnqAMMGeI+SDy
K3uU3WDEGdf0SuDe76qY8hDUp8odbRfIS9JfbgZitVaKH8g9YpL8FDzr3RHJjYCbSrRyDozZrovu
9iDLyN9ETRCqNcRnNHi98hps8QNW8a2RHcwl7vHGEnBfN93GY/A0Vrxd18E4rb82boO8pleWM8EM
o7f5FCyRFlMzwNqD/KI5JI5ImJj0BIwSRjhTwfK5elA2A93ktmmAzzP/Kf6vwRnuGaxEg0xQDH0k
hOYOWOh/B3zdth5KfrBs1VYrRUCEiKJKdfBccs/SPwV1BBmVT0CsUS8oEpLKu9fqA8EyQnlirgVl
kFpGnQ5GUdnevAKe39wTXUOAsmxV84NnrPu0roOZ2TPA1RhsE22z/r/23jNMqmpb1H5XqFzVOTeh
yZKDJANJskhOIqAgWRQQFBVQQMmggghIUEBQBJEgSs4oOeccm4bOqXKt8P3w9tde3JytG/Zx33Pq
/TOfGdYYY61Zs3r0qDHnktuDYNZusRrEe7TVvwJ1ldJFuQmmssYpcihInYR3DWNBqa/O1baBPlX4
VOsLwk29hyqDdFK6IC8Afbe0UgwH70+ujd76oF4WQ/ROoP4ipwjnQB5izJE2A3Mfz0It2KQyafSk
0ZNGQ9uLbS+2vVjYX+HHCj9W+LFws9KmapuqbaoGffv27du3L4RdC7sWdg1qaDW0GhqU31d+X/l9
MHP+zPkz58MwhjEM6Fm+Z/me5aHP3D5z+8yFBiMajGgw4uF2Fcjpfrj74e6H4Vu+5VsePz+M+mHU
D6OAUYxi1B/7C46Tujjz4syLMwsjUv7+/v7+/lBHraPWUeG94u8Vf6/4v27HX30+j0rBpqu/Oo+P
+jy7le1WtltZyOiR0SOjB/wY/2P8j/Hg+9X3q+/XwuP+Ro0ZNWbUGOB7vuf7f/0+rze93vR6U2h5
p+WdlncgIikiKSIJplyZcmXKlb8u76+ulwIe/DzPjZwbOfcvyHE+7Xza+XRhru23nb7t9G0naNKk
SZMmTUCqLdWWav/3zf/jfq7jxo0bN24cfDTloykfTQHvWu9a71qwLLMssyyDEYkjEkck/nW5/4x/
9nn9q/x3f76D/M9C+O0/V12vU6dOnTp1/rqAZ5P6jy7WF+p+X/xkzW3wzt7uN15Lg9OJV14/MxeW
lP+56/IBIF6wv21qAvd+Sl+QnAYvN6z1dION0DGvdZkPfwHft4Fu5tkgrrEdNm0Cw1e2G/ZYEAZr
g3UfqF79R+dbIG4X3rZMBP0FYakcDeJxXlS2Anu1FOkakGMsLt+E3E7pA29HQdbm1GOZ3UF9U3kp
szgkjizVtIoDrKstTaI2grTJNFbqC9eqH3hjhxM+8n1Ufe4UuPzG/ZS06WA8YCoZcgLCFib0LFYR
nM2zf7r/CvjmqLP0lmAw2E6F9ADBoW4J/AhM0Kz+YiB8xhhxJYgtpOqGuaAdFjPkHLD2DG8VdwfU
fZ5n3H0hb2x2sdSDoEerpQKbwHBaXiYXA8MvphBbMmi7eFo8B6riS889BtoCQyXrKZCHiGulEqAb
tOb6VyAdlucYBgFf8I5wFDSTnqDtAflr43KLBuIPepxyCXxl3EXzqkEg19/fOxHkedIOcy8QnpDK
C3YQqomjtDsgb5TybSEgv2zcYCwFerRWLTAOhJnaWO02eN/zjfYuBC1VL6taQbnmP+FvCPar1j6m
vWDCdikUUE6rjaRMsHxt2WU0QdhQa6ShBwgLA/H+BmD8znBFegcML0rNhOpgLma4KjYCqYfoJBz8
VQNP6P3Ane5d5ckH+aRuVt8HpZga5pPAHx7YHqgDhovyUYMF1G7aIJoDXYR17AB9hOpgNHBcfJND
wNO6Q3kCbMPsUoQbtJPCc3IVkGrIV0w6eHt5x7jjQNuobApUA+NXxrKSH4Su4h6xLih+YawwH7Sf
lUZiPyBUswZmgfGWqbL0BUSttN61z4LQ+hFvmEfBm++8f/T9c3/3Mg8S5D+TglzVv5qj+p9KQQ5w
9WrVq1WvBmHXw66HXYesyVmTsyYXniZRcGrDv4v/ac81SJD/BA4dOnTo0KHHEHEmVQgLPwnna14b
cLw6zHzum+vTW4KnpnLGfh7yZxq8ugji7tyRqY3hlZnRzersg3ZVqv/wQUfIPZuT6uoN3tC0Tpf3
QOKBp22Ne4B/gLpaWQTieD1JyQVRExYae4OQKzYQBoMwXM/SF4BWT5giLwImM1tZCSar0NDwJPgm
SFc8GZDb9ciujcfBNWTzvFNvQOzUsU3G3QX9buW90VdB/4SnxJ0Qe61Y6aQVULRS+JbwhnDt+cxO
zoPgMwRE70egldQVIRbke8ZrFhO4T+Q+l9UVDCstT1gUkJKl89JiUDvTWugJhnbyGuM9UD/RRkhP
AbPV1YFkCGx33c9cBP653h3+WmA5aX7FkgRCKvdMBtBO6T20lqCH84G2HPxzAk95q4DwIYq0FoT1
pBt+BGVe4GzgFpCsd/e/CPIQMV9fBf5DgfNKGIj9xJHicRAPi7/qN0HsZ4wyOiBkQeiZMAV4Sns2
kAhska6ZB4FvgqeWrw/4U3yDXJ1Ai9ETXKfBvcKTmvM9WMpbx9nc4FurVFUHgXpRm6jOButM22Xj
SJDaWOOMDjBeNoyVrCB/IntYAsa10vv6d8BtPlPPgbOHv6H4DkjPCwFpMLi+85cmFAz7xN3cAaG1
LzJgAeNxw1nDavAX930X+B4CLf2fqFNBek9TlWEgHZVOiQlgm249H1IC5IXi82Jf8PX0Hvd2Atcm
z2LvbFA6iIMlCfw73UVVC5i7GL41vAzSh75+vsYQqKR+7BkAqo+BnkogzpLHmJaDIqtJwkBw2p2h
7rZgOmv8wdwH1B/8M/1JYB1gaS/vAS1MWGaeCOov6n5xBcgXrIeEEyB45dXynL97mQcJEuS/k32e
fZ59HjhjOWM5Y4H+FfpX6F8BVtRdUXdFXageUz2mesyj6wkSJMjfxyM7zpZvTNVdL0JItu+FKCB5
+T134FuI2hY3WBsPpnNaauZp6OiM/rr2MWizpfWRsV64tds7OE0D6+X0r90/Q2SxSgueLAraAm0p
p0FI0sfpfUEN0RdkdwTJLh4KcwMbuChcBP2aflucC4SqP/o7gZRmXWp7Dm5XvnHkQBW4O2TCx+NW
g6nHrz+mdgethG+fdBvET72JaguQFfxyNbgj7mu7Iwtsc6ImO76AcmIVb6mOsH/mrRdTD4A/wVfT
9xIEnvUVVT4EQ2/z0PD9IOzPWZb1Cuhl/UZ/Cug/G3+1bAX66CWk90BZrqzTXwNlgxLhugD4xHwh
E/zrsnekhoLU2zDNYAHTRstP4dXB86r3tGcZWC5ZW1kPgVpa7audBVM1PpPqg7RJWi7/DLwhXmUv
aBvVD9T1oKWpLsN+EEpxU60M0svC+0ou+DV/ujYKhC7azcDHEPV8SIwtEbwXPd96voN8MdeatRHo
pD7tHw56Gj9Ia8DS2LY+9A4IZaStYk/QdWWZdyn4WvvWu/uD1MzQwPg8OCrZu1hOg1BKc8u9Qd2n
vaKUBKUZFdQ54Dvvu5p3F/SPtPXadyBfNYy3tgXhhvCT6SVgPGcFP1h/tm42AMp1bao4CKihN2Em
eCN8z/i/Be2EsE/oC4Y9xpvWBuBr5uvkHQSeLe5jnruQ9byzXU41ME0w2KTLYLgkjzIMgex9zpb+
kRC+3fGR1QWOjfb9YmNQ24pdDe9B9g7nWs/3YHIJYYEICEzQLMK7oB8W4uUrIG+URktfgOmwqbc8
A/zfe/t6r4FoFCI4Av4vFV9gPShuNVI5AvYGxvflKDBfMQ8JdYB0SpwvPwfAGNS/e5kHCfKfybrb
626vu/13W/H4GLhg4IKBC2BkrZG1RtaCBtYG1gZWqPhKxVcqvgITNk7YOGHjv9+O/2nPNUiQ/yQe
2XF+sktYwyL9IOeGODkkBsJm2Fo6tkBoJVPHwHroXrFLxFsDoVKlkn27zQZtU3R+1E4Ie+Kc9+B2
sGVEp5V3gOm5sIUR98AXHvgx0A+k57Xz/lYgTtanygtBnMtx00FQ++pz9E9AqIzF3w6MHU3vmdeD
O9qpptWDU7M/vfpxEpRdeLBThh9s1Z/YWUaDsK8MdUNiwFq9/KDS+0DxBAQlH6yZRRsVXQvWY7bW
JicUsUbdisqEsIb2E2E7wHnEFZ+3DVwtnD+4kyEsN7pRfE8wljDPtK4CfyO1ohoC5lHmQdZI0PcK
W/VZoL7gv+a3geWAobzhBVBekd+2lQPzE9b0QAxQRK3rnw++S77jnupg7Gp4Tv4EAv0DrZTGIPSQ
lsvNwPC+NExNB0Vig/ItiFN0p7AXDFXlOIsP9HipvXYU6KG38rQHIUJoL08CwyzTDOPrYBxnOGfM
Am8f573sDZAq33stpQqIvQ3PG9eBbDdUNsWAyW6aZtwK8gh5vbEr+Ed7j7oHg5gqnTD+BJLLeM8U
BYYWcm8xAuSZXFEugqGr+S3pJtBBP2LSwDdeGeAfC5zSYqWuQDvxgv46+Jd79/sXg/iZXifvMkS3
CIswyyDeVB0MBMNU2WPaA4YNRqwDwNPP3zVghUBLtULgDsh1lBGiCIbWQm19GkhbjfHEg+JT+4kr
Qf9E+z6QDMIoMdHYFMJfieof3Rj8A3yT1V6gH/d3U++AKoqbpZpgXmo6YioL1nnm2ZZ40PfqS8Va
YNpiWCRtBUNNoZKUCupl5Yo/EQLH5WxKg3DL9KvlFfBYffuVomA1GU7yIsRsDH/COAjCm4X1DC8L
aiDQT6kF7P67l3iQIP+5FEkrklYk7e+24vER837M+zHvwxKWsOQfDahDHf6FlMi/yv+05xokyH8S
j+w4hyAnxi4G78jQ5vlpUORm8TqBTtBh3pN3BudC/IxSmTWjwL1PGCveBrGMZ6nrDISeKd216mTg
hjjXsBUCki/WOx8Mu8SNpjoQKJ9f5uZeEJ+3ktgC9BQ+kvqBMJtD/neBN8U4+T54v3S7Xbdhf/Gl
b329AKy9cj6KkiBhwbuGVjpk970w9UxZQL9U524EaPuVD1yfgXTQstBcBEIrJx4rYQPzJUMFcRvI
UY5ulvfA3NvS2O4Cw13LXEcuuNyuHplrwFYlvEjcMDC+ZJ4cMhhyOt4/dqMm8I72vFAPzIdsy+2/
gFZG3eH/GDSRcUISSBYqC9tBMauLuA6Bt7T7alnQY9SBSghwl1J6KcAsfCXdBHm9vlXIBq2Rvj/w
OQheYbjmA2mmvMuSDpalxmPiy+B9wS26V4I4jPrKVhBXy4NstUF9QRwsLQBV8493/wr+0QG7712I
/qxoh1J1wLRJes84HySZo34fSPU1j/IVKA39S1yrQRpkbK2GQyDd95G6EXzzPKN9RlCbih+JoRBS
xYH1S9DPs4DV4E51v+JNBbW6VsdbAmzPmH6Q7kBYmuP1kJKgeLQ3fbdBHqDXM9QA6biQIQTAetO0
UJ8P3ud8y0UPpM/O3errDpYGxqXau2DuINo5A16LP917DvRofZfQE8yrDNHGt4Es8aw4AvTramXj
B5B5OL172lygiGwyTgPlGaGt9CSEpTmiTB9AuNdWJnI3eAJ+o/cg5B53x6u3QKwizPUsAflJ8buQ
X8EzxHPM1wxMfS0D5GuglBOWiKch60BGIGc3hG0PibDdB/MGcbPmgxIniwthJrCvdaxzxIEr1lXN
eweAjn/3Ig8SJEiQIEGCPB4e2XG+28jZz9gGwjPj+6gtwZeS/sHNF8HzQs6hzLGQf1wo4ekEptVS
bUtvUK7ymf4JSPl6C2YAE9R6/skgLhW7G4eDqiv7s2qAPlj9Qf8KhE9Nb4fFgf4iBmUaMF67qJ0A
01RjWfNaONTh4NLD2XDstZPdM3dAz4xec19+HkJmPpdd0wTpK/p8PKw5uBRnkcwOkJO/ocLy18Fh
fvbei6+A6WKJ7XHrIKdudiNXEbhTLreXJR5iv4m7Eb0I0lvl1fNOBneXfOutneB+1eVz1QL7IEeP
0DtgnWy6aZsJekagg6snqCGBXfp9MESZjI4nQfcKoeJc0NcSp88B9WmlqP8KGHoYx8nHweC0Do4Y
AnqS9rGYAlzT5imXQPMHVrt2QGCI75TnMsg/GWqKI8GX5b3mHgT6eF+8YAP/JsqbfgDr69bDoUXB
3sNWWnwHtIBnv7MyWFLtZ7UN4JquyOa24Jrq7eY+B4Yq8mzPBtBDAzGeWJAGS121J8HuMA81twGm
SZmWjZB7QdjnqwYOUV5smgD+EYEBfABer7ur9yq4BufvSd8FkTsiY60/gLmxIVP8ADJj8tY550Nu
mex5+T4I+yT0TXskqKLwntgA1LVEi6+AwZK3XekKajN/4/zrYHrSetswEnKr536g3gF/x8AoX01g
ttiR/SCfkJcb3gXlXP6YvGEgzzBUNMwDPtGW6t3B+LR1pWU/+Kr4I70JYHqbpEBHEF8OHNdCQW6u
1/LNg5B+xhVyBkhXLR2MAyFgUI4ZPgCtjvC8WhUMftsacRsElqi99XrgbanEeyqCOcWYIg4Cb7f8
mJxfofTqpKN2CZ5IrzSq2PeQF5XdVjwG+n3h9RDP3728gwQJEiRIkCCPk0d2nCtdrdy02BlIHnv2
jLslNP7haU+PFRD/UU1z3WXAMFMZqw5aNWULJ0D4TvhS3AhsE7IMc0A3qJn+l0CYLJYRM0F/x2nI
ygPDaL259QgwU/xKbA3+484S+RVAGCfMVYuA1iLQj41w+/KdcfJAaGR4qVn9NIhq+1SpCingqnF/
UsqrIAg5O/P2Q9jJIidLxIMpv8SLlY5C5pOzuixpD/HS6A79r0NOJac18DIYv7JGxUyDMpNL7i4Z
Bjdb3o/Kqwy5M3IT7BPBfTQvkP4lWL522IpXAkvtkBHhAhgGcDuvGYSscHSUZXD+7Dns9oOjvO12
SAWghrBfKgLy7vBq4Z+C/44Qbfwc1G3Kl75I8FbK2Z0xFPRqeh/lZSBevCIJIO2UxguNQNwqRImh
II4xi6bBYK5gu25fB6FFjRZLGljfsqwxFwF/vvMt50RQ5/m3euZDxpP5x7Q4cNb1z9G2gH5EihOr
geNs6GfmKiDvFt/XboBhh1RU7wTspLbfBK6y+QuVjqC21FfoV0BTBYNxG2hdNVXbBaZm8nYxHUoY
S5dMuA9yS/2MNhKudknR87uBhGGoHAf+s1orrSz4L+nv0B/CXwr9NSwMsjbkNHAXhwxP7tH8bLCc
NY/XvgTlkrOdUg90G0Y9BuRjxnHyLNCzSMME6o/qDHU8GPeZDptCQZupCUp9MPQ2TTTGg9JetWjP
QCBN+0H/GawvW7NNdyGwUz0mTIKMw1ktMvaAfbT9bcdFMB41DDZ+AFKU3Nd8ETyiu6frDqDoDmUW
qJv028I6QHVXcCVDIEzyi/fAXMV/JXcZVLIUN0UFIPK+ZakjGXJGpg7wX4XQ9tF2Rzb8t76eLkiQ
IEGCBAnyb+XRT9UY5X3m9jWofqnEhLJFoRJNol+sAJpijRTbgb9VZsfs+iB+bd5gigJR4QMlGdS5
wgDFBsZa5hz7S6AuF5/Rh4LaOneluzQEauv37H3A8kJ8iL4B8jvkbfAVgVAt7GLYTPA09v/orwvP
nGj4XhkzxHdIVMObgE/JM6R1BVXN7ZzTBIwJLp1cEJvHlDLPBsMn4SExzwPXbePDyoP/ZO793HIQ
NTF2etyLELPV/olaGqTkmMGWSLAfDTkurANjtbAxMangvJRe5GYH8BTztI7fCGazZXX4MhDtrte8
DggrZ9xlXgC2scIPSgOQrWp6qgjCOeGcVA20tzxT898H9Wt1u2QBcbE2SWoJvnvCHLUlKMe06vp0
0L/yr/JFg9zM0tL2Cwg1tSTFDbpbeca1HdQing3SZhDjhYnG7cARoZR3PuhFtSzXryDUNeywjQN1
rfqDfyCEqpZ6cjGwnrNet7UH63nDUr0eWF+Xp4ZEgDoyMMT3PARO+yeoP4O9VsghYQlEOExzDa9B
Xg9/P3E6+J/zNPSvgqQSMYtNEihxykLpMuSud5X0HoIiUTFvW8PA/bJ7cqAMZBXXegtdQL3tS/P0
AGWlMy/jOhT9ytpfbQDO9bbdIXsg3Zj3ZaATaMlKFWcfcNSwiMblYKhlKGtMAPaTwgjQftSjhVIQ
ULRY/QQEPlAyxQMgzBQOimfBdtjSRi4F0QNDh1hkMGvmRHs6KOsCycIQ0HWu+AB9kOrWPODP8u7y
JoGw37BZSYH8kc6ovCEgeHW39g746mg/qwoINdWGykLwnPb3VD+DktfjT5hGQ9joxGdKJEJA93QS
y4DxNVsfy7NgaxHxQ8iFv3t5BwkSJEiQIEEeJ+KjCpBu6g3yRHj6bHOtgwJcsc0zfAl5oal97rSB
vRN+7LEiHFw775xJXgPu4ZnZ2W+DUj4/Nv8lSK91cv+RFaA+7f7CmQq5lXJeVQH1KcvZ0O9AOeLf
pVhBua9eteSBsFS+LkgQusUuGbdDXEZsy5DXwVfPVcb1PoinHHNiMkAv4TykrQFxQmblzJ9B/MYw
3OoFaV5In9AjIDxnO2erBPouaa8hEoRc/yfOtlDKXDyj2G4IuxfxtVYHHNusqi8fQi2hnWJCQZKN
ueah4J6aNTVlNKixUhXTBPAcEobY3oPz85I/zh4NeUN9EVptMP0UujfxOthNtvkRbSG7Y/5wL+D7
yjUjfy9kt8xKT2kF7rfdt3OXgHraP9h1CszvmwJSQ7AWNbaiPZiqmqyWQaBe1o+L40G5GHjJVQGy
L+WWSb4O+U7XQucQyLibE68OhJR2mV3yykPkopAo2xSwlDW9b9gL+mntSc9FEE7oL4sOcCywaObX
IWSnY2jYBDBEm5+0DAExWqrhWA85pfJmi6vA2SvX6psMyin/QtcB8PXwvO17D3wv+Vc6I8C6RcrW
FIj9JORZyzxQflDX6mHgnOJ7yz0J3OFqG+0w2HTjq3pF0NJ4TrKDOFoNVyPAUE5oK86DqNdCDeHZ
IM8yrbe2A2uK9RPrNpCeZbg8HPRFwtMEwPSqqMpDwFTS8Jo0D4SOUiJh4M8NXFe/BP913zdaZdDK
+fFJYBoqx7MeTC3F9w2fgXGp9IZcEoQWwlTjNXBdy3vN3wxcWZ4mzm3gy6G57gcp1LjRWAXENpZS
lm8g7GZIP/tOKHm0ZFrRkqD1lDNCN0DahLxN3hkQ90pit0g3mM5ofcWif/fyDhIkSJAgQYI8Th45
4lzMZW3Z4DVIqF9CrWWEPFPmytQEuFzpeM3DcyHjevRycTD8NH3vubVPQ1KuKbnYYqg3p1tYZwHY
bRhrsAONXPuywyGwJWd9+gYwOZ9YVqkqZLdLTTy8B6RW+jOW82DYa3qn2gzwNwpsUhSgn3pFnwzy
SSHH8AUIVYX+0kVQjqUsSr8FSh/pJ0sqmOMjy8TYQSgfdyrBAMavw1JD2oBwVauq1wZDsu0ZUzPI
nm+re2ESZMzOrXtsMzzxyxPXI1rD/QP5vf2DwPFM1NfF8iCr9N3lV+uDd4uze/5zYH7BZg5zgTDf
n+9+C3K7+crqP4A2JM3p2gghXxjbaypEvB8zPHor6PO0EK0CmCc6G+aPhcgVoXPCaoN+AoP4Brg+
99/03If8o+7W/k/BY/CU9tYEIVXqb24F2h36CyKItfQ26kBwCd5v8o0gtKEqCyG+Z+RcxzgIDTW9
JjQA11DvIm0bCO+JPYXdYNlubCddB1/JQCu9L+ScyM7L6g/+kspF5oDnUyXe+R3od7Q3fdPB/plx
htIBAhd9vkBx8Mzwz2IgxNULGx59Am72zVie+QZk93TN056EwNd6cfELsEw3jQ5UBnuq8XW5DDBM
3aZ8BIwwdpGqQP4Kb0XGQG4D9xyvHYzLpEjpR4j7Nqy6eTyIyeJOqR4oU8ydTCYwVvbv9rcC7aCw
gTdBHKIkCyVBz1aq6ePB5DKJFAdfa+8U3ySQlgkTxRTI6Z4XcG2FQBV1gl4XAjHaKuU7MGwwHbVa
wXvGl+Y6BqGvhB4OXwjKZcWvfQ7KGH2TAohr9emGn6FYdNgp8ShUulrGkNQVLB8aytiGgdRD3mxv
DhFJEZnhChxf/mvvS02hGk9vZ//fvcyDBAkSJEiQII+DR444Pzmh8dyOr4Pfo3ZWFoF0wmCyyMCI
iPnyJshp7/4mrzZkjJEnu8pASFjiQr0SBBplfHwtHYzvRpaPHAnM8BzLHAJRL8QWc9wAqY55knEo
RFaKrvHEBYhaFfdcqb6gnFR+0IeCEMVGvRaI3+vnWA36VcHLl6DtBD0D9M/UskIIsM7WyLEJdJtv
ifYqGAYYLIZNIJmTFoQtBjbqk8V14Bfdd92zoMz2InFRn0H+ND1FDwX3xKwZGV9AsdCI7WIlMGxy
TI5qDuYajoiw6+Abn90krQIICdpHxilgXmCbb2sBniu+zsJPkDdabys7IMcjRJungedzZazQB7St
WntpLBi2m7fbPKC9qY1Q08B1ynXT1Q2ks2qmfyckvBgebQ+FYskxV8LfB2NAW+TTQAqoRwPp4Khm
XmD7GswbjUsNbcEy03BY2gXme/JhQ3e40TItO/Mo+G36QPUrsHW2TnaUAvc4V0tvGNx9NSMxcynk
VHCdzfsE3C94q2dPAc9Md1R6HVC+C/Rx5oPrpqexFgZStHRSWwjFnon+JioNzoXfeDk9ApKbZId4
+0J2D9dgz1wQ5uqKuh5CTVJ9cTXEzLXVF9uBsNbYUCoFWRZnTSkf/N8EflDfg+jIsJaWdWBbZD5g
sAAB/TVtA6SfzZLy6kP29Nx3XTbw1vRYPZ+Bd1u+L/87cG9ytcjtBNKLzPJ+BKrBmyGeAj1bby+3
geyzzkW+VpA5xlnM0wrSruXUz8mF7JHO0e5lkH04t3lOBzCeMXqYA8ay4mZhF4SssD1t/BTCFtnD
bVvAEDDkMA0S9xVPidoO8bfiusdFQOhaU7jtHhS9XPpCmfkQqO0eqpngmve4+WLDv3t5BwkSJEiQ
IEEeJ48ccXaciApLqAnaG/pSEkDUjRGGk5D+es4P2S+AS7tjuW+DmsPK36l2Eyp9XXVpo1GgHDfN
le+CVF87pFtAreXNc/0AHBA60RxYqS53lQbtfv7PnudBLBfROuEuSJMDq5TroP0irmIrUFJ8BR38
s9RmvlfBNMLfz38L1DbKMelL0HNN+fZhIGxw95MnAPdB2g7G1Ym1YisA3yvJgc/A3zqjwd2ikNfP
0TktC8o1r2F8si6cPXLuwAIf1G1b5avyL4O9k74oZjn8usK7oWhvyDl8d9DF0uAZlvd66gqwtAl/
NeIwSIMCb/lmgZaoDNDGgjbGeDm6CuQ9qT+jfg/Ku74GrhZguK5+p+0H10ueQ+4yYOtkXeQ4DiFz
hcbSIbB+bGhn+BmkHczVDkDSofgZkYPAddQnKEvAMyl/WU4zKDIp9lh0BDgreEPVWiDWkT+WLVDk
efvnxW6BaNDxquCZ6r7sXAbO+57U3C3gPepZ5vGCeavphCkUmCnsNX0C9ovW9SE2sAyUQ4U3wTJH
qqZ8CaZxxk+tRrg65e4153RwLdByfP3Bssvwtuk6RG8KqWBaBCnjU4feC4PoBY7e1hfB3tzWNrQa
nAvcGX//OTB9aIqyDwPHC4bp5nIgG5QE1wDQumhp4h5INuWOUJqDnqyu898ErSovGDtDTiN1SCAF
NNHbSVkF2vPKBdcWcE6Rv9UzQLQL1fUeEB6Irhn3LgQmKPXJAjlcvK+eB0ea5VPxFOi5+kA9EYzr
5V3aUxBy22yhCKh7Ard8PcC83b4n3AT6Sv8WvSOE/RRb0h4NURdK7yu3FjzZmm7qA9Hp8SVjmkG4
MWFtdAociV8z6Fcb3Fh7/9U7IUCnv2dh5+Tk5OTkwJIlS5YsWVLY3qtXr169ekFYWFhYWNjfY1uQ
IEGCBAny/yqP7Djrl4VEfRGoNled/NGQpdyffiUGSkxRbZZKUG5CVfnZvpBYpOqmp58F7YeYZoll
Qbzhv+FLAPGqHiIsBOf7t1qdGgzW9FhvlfKgO90D898APnL3z64N3Iv4NqEq6JfERnom6M8I95BB
2qenCStBr0VS4CR4P/aFu3pDoOb1FclbQVuo9aU75PSV7XkvgePUnZUXp4F307Eex6qC5ckndpY4
B+bK1bTSB0G/760dMgGefKvIZxYP+IY12Xj7GlQsX+H91pHQfFbdgd5akHpq6pPfdYJTX7qHxXnA
/WnmlbsnQG5oSXe8BabJ5mNhv4DvTv7P2ZvAPTHnSPbHYPCZ7MZWIBQX5gk9wH1YT5I/BctzRldY
efB+oy5hL+S0kJaIzcEXGdhGT4je6HjBJoDJZC5v+wDy2zhz3XchEGGeaGoKoQutT1tPQuwz4R3k
NPA28U3Wx4CTvPzcKyD1Em7qH4I0217SMAZs182tQz8B72hfI0t/oIPyaaAqiNEG3XgNsju7tynf
Q2ChXxAmATvl4WIlOPvJzcS0dAhckeO0WeAwmjaaygCzlDoZ5eBu+/TRYnewP2n52uQB0sQ0jwAZ
pqyfzF9C2K9hU6KHQpwxPMU6AnLlnBp598Hv8pfXX4KMUbl3nJ+Bb616Qr0MUStCfjE3BpNo+kB/
A2xvBgaIByFD46i8D+Q4SQ2/BNF7Q46bYsFUVl6sZoG/lb+uuAM8z7FNLQdSN6Ng0EHarB21VAe9
st4w8COoG7TO+kzIX+qurDpAetW027gI8ro693lHgOOEeZNhJSSsTTgWsx2E8uIB61JQW6vV5Itg
PxK7Ne4SBMa4FrvegYO+A+5jJjhZ/WaTG/rft7AbNmzYsGHDQge6gAJH+uTJkydPnvz77AsSJEiQ
/yk4nS6XzwfTpy9a9OuvcPnyzZvZ2f8+fWXLJiWFh8Pbb/ft+8wzYLfbbCbT7+3x+QIBmDJl9+4L
F+Dy5awsr/ffaU9EhNkM777bsGH58mC3m0wGQ2G/16tpmgZ79mRm5uVBbq6iKMq/z57QUFmWZWjQ
IDIyJATMZlEUHzm/opBHP1Vjm2uDaw14892XchaDrVbYqtihULRJq6J1KoI2mXP6YQiUVd5WU0Gf
51W9t4C+YpjeGlRj4C2XEczh4a9G1gK5ZtGF5SuCNN1eL6QR6NtskeFjQNNUu/AO6D2E72kJwlzO
CzGgVaAr34NpreBwTAe1ns0Wvh7CN9eullAbTh2528jrh+O1Yz6/dAm6jpayboXD/U3l9bsfQ8LV
Eu8UCwfb26Ze8a+CVMY8O+wTkNBb+z+Cpm808Y+qCPpnejZ9QHgv4QhvQ8eazeIutoObA9e0Pv0N
5ES4DuaUB+cHWY3uZUKYGFu26AdgKmOLDFkMnh75x7N3QWCmp5l2CITW4j52gPCrYZZoB/FWYILl
a1BC5SrGj8G9zdxXjgdppe8zTw/w5akv8w3kL3S1zf0YzKdUR95zkD0k4879H4F55q/D+wMzA62U
DSCOkBepU8C80rLKtB6EYXSQT4CeHwj1noaQnqY7Ul3QjJLD1hKUdDHDHA/uKPcYpRq4OngMnmeA
Vdogbx8QnxeOWLdAWG7ELbsBXE/kbc9xgOe++6vcjRBvijZEvQuZuRnVrvSAkE5hi5OqQeiXjtGx
70D2XV9X/znw5+S8pZ6FjLe9WSkzwLzV8pXpa8g6kf+r9zZ42ntjfUlQJCt+TsQZMOw31LTOBl5S
O3qjIfxE6LPmRqCO9zfP6w+pMa5wV2fI1IRv5AGgf0ya9jFoPSlFEzB9a3AZE0E9KDynH4HAz9rH
2lzwjQ/M1n4B5UnldU93kCppnwk1QR9CK48IjjXWJPkklKhYzFlGg4h+URcja4HhY/8rWjqE/xTt
jN4JptviEjEUDhxcu/rYMvjl9EXn5U8gLV4xaFf+fV8MD2P37t27d++GU6dOnTp1Cm7cuHHjxo3C
/hIlSpQoUaJwXIGDHSRIkCBB/jWmTJk/f88eyMzMywsEoEyZUqWiokAQBEEQHp8eXdd1XYe0tIwM
p7NQ74QJw4c3a1Y4bsKEbdvOngWPR9MEAZ5+ulixiIjf7Hmc9/2bNXDjRmam01mod8qUF16oXr1w
3I4dGRk5OWC1SpIkQbVqoaF2Ozxea0D/P8Gqu3c9Hp+vUG+rVjExERGPT88jO87ucs7i2U+B8YJx
gXkOSLkhE8L3gcfpbeMpBkIx7baQCuoKeSvjQHhCbKGPBimOEMNG0Lep77hfAuPzxb+veA6MR2zb
HddArc1PXAdiGCQWBYNJ7+l/CgLPCj42Agf1xmIu6F7hsH4HaE0dNQzEm/49hmJgLd/wjVpvQP7Z
rKQt2ZBTJnmXvwPkNWWXezeo00odVTRFnAAAPFJJREFUKVoVfm17+dzeDGi2N+RkuZfAG5Z21HwU
7n9y25KpgLGuYUnWcMjukrL4/gnIXnR/wJUUONX31ovJUWD9wNEo5Bdwv8BX5dqDd+jNA8c2Qf7I
7L3prSHkVmREzCYw1reY/XUg4PQVz30ZpH5ie2Eo2HtaI0JaAdMNFuMwMD4nJ4sTITRXXKCdA0MJ
423HIbh7I2+CHgu+jq7vfC9B1il9gCEPlHrGnCgdiswNKWn8GDLHZS12DwdpAbf0HMhzuX/WLeAr
pdb3mUEuIS8R0sFbXiulPQdyCzEk9024p+Wcc+0BSTTWcFQEYy2Dz9gQTJMMlRwvgvU4N7z7wHff
80VWKqgnmaZbwTTEvE0LAeW4+p5WBYo8F1up7FQIrxcRazsDnhddF+S5kJeSfdHTAVw9tHH+TuCo
YT9nOQ7exoFkrQx4e6pb6QCxb8QsjDoN1rnW1pYicNdxb3y2GwKDAv09x4Cj+qzACsgxeNf6XSB8
Ib9ibQiBxdpt6oJ5tmW+8RswHpCzpeOgjNbCxY6gGAP3vcXANsMwXFgNli9lh1wa5B+lFeFXIHej
/3SgE9gnGzeL7aDc0KL1YlOhWP9iU4vdB8NK4a70JsRGRA4NvwZR4ZFfRnWBS2/+mnT5e1jXZlOp
3aGQfNdX1pULckdxm/2t/7NItj7eL4f/imrVqlWrVq2wPnPmzJkzZ/7zcUGCBAkS5F/j3LkrV7Ky
ID4+MTEsDG7evHcvL+/fp89ut1gMhkK9D3LmTEpKbi6ULh0XFxYGBw7cvp2R8e+zJy7OZjObC/U+
SHq6368oULKk3W4wwIULHo/n3/iCsPBwSZJlSE//zYF+3Dyy45zyxlXj9VfAZ029kzUBqt3ovLZj
BvgjfGUDr4B+UjbzHUhntRMcBaG5MEBYAHqCeIp3QL+on/M1ArGkGCV/DtrPwh05Ebiq9Qk0AeEl
YZHghsAk4XVxCogXtbtiAyBWOKnoIAzT94tHQAvBIVuBr4SvAmVALe9+WfkayoxIeKPKp3BL9Xr2
fgQZ4fKB/J2QaNKuOtpDygvqt/LnkFXzfq97u+FTx9vXP10KN01phsAHEDnGNDlvJugHldnOkZAZ
41rkeRU8X9jXF68O8d2L/pSUAMwNeT50M6Tfjcotdgi8B9I7JceC94zxOfMecISEvh1yG4RbfKEn
gTlbXBCQICxg0NWroL+nXnU6IbSz8WWxFJh3SWGBKLjaKvnlnJPga6/lWeuBup9+kgv0jtTUhoH8
k9BZPwupqbkh/t1ga+wob24D8iC5qqU/eGt4Mj3vQ2im3FuVQAzwinAdjGXlLrbTYA4zh5tjwDjP
vsWTAUIRWnIDxG1CsvAEqEW1DwPfg22ZnC5dA/PLxlJR08H7tK9jblUQ2tLCeBh8OYEnlDng2+58
Nj8HAk1Na61ucBndM3Ingr5AeFv5CIp7w3sJNcDoEiKl8ZBt9izQ7kFMl9AdlnwIPWlK105ATlL+
4vwe4Fa1z3U3EEe64VPQsulNUzBftFW25oDlFcPThqOgNtWPqF1BjVG3CZ1B7aMfEW+AvFbSA7XB
1NdcX/ZD+PrQWY4O4F3uTZIvg/tjXy1fJbAdMdiliVB8c+zZ0PMQayy2vPiboBcVPrYEwH5Q7Go8
BUkflLIktgRXIPumexpsfuHnDftuwJ0uubdu1AFLcT7xxoEyS0eIAp799305/CMKcpcXL168ePFi
6N27d+/evQv7C9qDOc5BggQJ8nhQFE1TVcjN/S1l49HlBQJeL3i9LtfvU+3s9rCwuLhCPQV6H8Tv
9/sDAbh9OyfH6SxsT009derAgcJ6bGzVqk899ej2Fugp0PvH+1FVXYeMDEX5R/07dmzZcvQo7Nt3
4MCNG1Cv3lNPlSgBjRs3b16z5l+3p0BPgd7HzSNnfWT71UYZ4yEjQNu8NiB/JyjSdRC66ru0aKAE
qzgGwkRhlbAFSNf3CodB+FhYJlQHf5GrIb+YQNmZnZezG8QbcrIcAC1S6Ca+CfpWPEIZEG4Ln9MD
GCVU1a4BHRgiVARdpJJeDYSxQnOhGIjLiWYa+BThXX0dFB1f+ouGF6FpYq3pHVuC/VlzufiacHlz
hny+DJjNlpOh2bAv+eDTB8rDzYsW8523wW+11vTsAHuLsl+UPgXVqr3w/vM5UKpRtTJ1B8HQ0v1r
dekC9RwV9JiPIPZ9VuXNBeuCmKZFVoDsD/spsj149uY8l1oK3D3dzb3vg7GxvXpIe9AydVE+Bp6e
npmeSWB8Ur4TyAcv3k/dP8L5+Buv3/8Oki3p32XcAm+2Z5SrFEj3jBbjz2D2WV+1dQFOCV6pL0jn
DB7jXlD6axmG3ZDXz1XFawXTYvMLxkUQZgmpbf0aoiqGVA9pBubjYoRyCBgU8Dl7Q8gd81mehviv
Ij4NS4aYGza/vS4kfmzr7lgKRkFsZs8B/xZlpj8M8r/NfTY/EVIO3f8ieQqoDrVXYAbkhyhh3pfh
+tHMSScXgVxPuOWdCezSL+WeBvev/mX+UnDvSOaNTCsYPpci/TvB/oS1hPQWpBgzijvngXOS57Z/
B/gqeqt5vwfPbN/mgBOU+6wSFoBUis90GYwxxp3yWLCXt0ebmoOtnHml7QOQaxgzRRECnfS9YiZk
fpyXpd2BK3Nu9kpPgIyN2UmZV0DZoXzv+Qmiv4560boM4vcUfybhOojfyUNMLcG7w19Z+xAcDeOe
j+0MeeOcacKrsOXe5iNHouDwL1e+utAJ0vfm7UnrAM66WZ3utwb/CM+0+z88/gX7ZynYBPhn2x+V
mjVr1qxZ85+XXXZ02dFlx9/3XB43HSd1nNRxUuH9Pey5FIz7T2GFY4VjhePPz1tBeXnE5RGXR/zd
1hcyKXNS5qRMmN9/fv/5/f/69fnd8rvld4OnjE8ZnzIW3uedlnda3mn5d9/df+7nJ8j/jaoqiqqC
qqqqpv3rpc/n9brdMGnSkCGNG8P69fPmDRhQWP7xut/0Pojf7/P5/eD3BwKKUlju3//xx2+/XVg+
2P/o5W96HyQQ0DQATfvNjX2wPHDg1KnMTDCbIyMTEwvrDxv/Z8sCvY+bR444y3VKW2OmgTkjfGX4
LNB38CRjQG9MN14DYacW608A9Vv9tv4WCG3FtwyrQXxOKC0lgnhQ6G5YDtJOe0zMUlDf1X8gHkQP
TyrlQWjKc5IZ9AP6GBqC3gAjvYBoBKE5CF2Ep/Q3gLZ6bf006BmsFnuA+JOoWQ6AclAuFpgFRbWi
eoNbIK6WkS5DZqY46vItuO5MTbv+I1xMv37GUxvKrWyc8swLcPaTHzud6A9hA4t3cKRA+egySytt
hhePdbvRqyJYt9qKmZ6HXZ13lv6uGDTeE3M7fwyEnDieq22EsxX9b5S6A1kfaYeVieBblFEkZQEY
e0vTi5YFeYT9yfAo8H3in5H3EeT48lbkzQB32cAMoSNkH/Te1bPAdMzwqaEJGL4V1gUqgNhDOeoW
IBDmdcnJYJ5i+cn0PASm+V/xWSHnUN5L2efAVsQyxzIGlGc0i+UMOC95i0gfgbGUXNx4EvxGfY52
BJTzgaGey2CbZJhl2waedvmrA1PA/5WvddY1cH2o3LxshNRTafszVoD0s9yYS2BYJky1jAbveq8o
dQZ9lRRtDgO+FKvkB8Dl93fOOgliLabbf4G8cvnD8qLh7P0b77uSoOTB+FFRKsScse53JELKc2lP
5e8Hb1ey/GPBUotR8howl5FTyYawb0IrmxeB8I0wz3QMlL3iRWkpyHsN66X3QY0L3BV/htzw/Hey
M4GaREltwDrYesxaEWLmhrTXW4Ca6+9pWgWG9uYuxiegyJTwtWF7IeJmMSluAcibLHUc10Ct6R3M
SIj+Kt4SeR5k1dY7TIcDL/3yy6XqsDfxaOtTL0J6AzYEfgLtC+PMKBm8T9Pt7qcgtJeaShWBe/+O
ZftwCnKW9+zZs2fPnj/2F+TcNWjQoEGDBoW5zo+LyGaRzSKbweuvv/7666//sd9x2XHZcfm/95n8
nYz9ceyPY38Eu91ut9v/bmsKqVu3bt26dWHs0rFLxy4tbB/fZnyb8W0ePo9x38R9E/fN3219IWua
r2m+pjkU71C8Q/EOMIABDPgL12/fvn379u0QqBKoEqhS2L6l45aOWzpCX/rS9+++ySD/8ShKgSNb
4LL9a0yZ8uabTZtCqVLFikVF/bH/QfkFeh/E7/d4AgHw+63W/2oTnt//WwqFong8LldhuyxbLDYb
6LqqKgoEAi5Xfv5v7VYriKLB8PvNiA/qfZBA4LfNgapamIf8e2TZYnE4/lh/2Pg/S4Hex80jO85Z
1rsJyb0gbnj41jIfgfCpGq9nAYN5HQvg03OlCyCuE58TZgMBPpViQPtca6H1AalF0eFlF4N4wDo4
ei8IEepg317Q1us35NPASHE0i0Gw6Ov1YaCnEIoZhBK4qAnU1D8WDKBfoYRuA+7pRv0H0JtzTusL
Uge5jpQAyjPq58ovIN03TLHuhCd2x5Zq0B0icvWfQ05CVKDEYfN2WH16cdbmOCjVruLpCBdUz612
yNQQkkPuxp6rBAn10o5p2yHyTXtpewcoUy1sheVNENpqLRJegJSFcsqlT+Fegn1D6HOg1yKs7Pfg
XHrvm3My5Nkzf072Qfi0yEWJ60GfaZ3p8EJOlUA3rTqoI72OtJNgaCEPFb+DmLURxaNeBEMHUtSx
kLo/q8GdChBaI7RCxLOgFfWdlA5CaFSIHjYT7Dsst6Ud4PzF/Yt7OPhbeo/k7wHhsqGTMRZI13v6
7oMrx3PHMw0so00vyftAHaZM8LrAfceb7yoC3rxAi0wPaJuMO3w9QF5vaGWfCu5h7qdzngUx1zxH
agPWxeY9nAS5gfCefhpE9DG2pyAuPDq6yhHIn+R6PucqFLkT2Tj2OkhficvS+0LC5tCokImQVS5z
iWcl3P0qk5yfodQr8U/aN0EgVsgP1AJxgnmGZQIoc+jCJ2CPZ4riBdMy8ZR+EQxOsZ1cFTJ35TXN
+AaiE+zxhikQdzHqvZifwPyO+Wv5GKQ8k9ndXR5ujk1tfm8olH2p9LIi58Cxqci70SXBsNDYxXYS
PO3zrwV6QVS9mKSYvRCyLGZOVEO48c65Vnd9cPiNExknq8H9i3pV/QioI+TPoq4B0/3RKQfBONc6
Xb4JpraWpPgXH/+C/WcURJQLHOjx48ePHz++sH/s2LFjx46FpKSkpKSkx6+/wEFsndA6oXXCPxiQ
QAIJoM3T5mnz4Ms6X9b5sg6sW7du3bp1kJGRkZGRAVFRUVFRUdCuXbt27dpBn0N9DvU5BOIgcZA4
qDASV+Aw/TDqh1E/jCqMzN1ac2vNrTVw9OjRo0ePFqovuC4uLi4uLg4syyzLLMvAWc5ZzlkOhl8c
fnH4RWga0TSiaQQoVZQqShWYljstd1oubCy6sejGolC6dOnSpUuDp72nvac9sIY1rPnj7RbkmBdN
K5pWNA0aLWm0pNGSx2dHda26Vl2D2y1ut7jdAu7+ePfHuz/+8b4fpMS2EttKbIMSlKDE79rHM57x
/9U8vs3bvF1of7GJxSYWmwh1vqzzZZ0vIatTVqesTrBj2o5pO6b9+fm5turaqmurYGqpqaWmloKz
Z8+ePXu2UG25l8q9VO4lGHpu6Lmh52D2/tn7Z//uxUIF8oalDUsblvbw3P4H2Zi2MW1jGpT7tNyn
5T4F4xLjEuOS3znONfrW6FsDOM5xjj/65+gz32e+z3ywKX1T+qZ0cDqdTqcTanxR44saX8D4cePH
jR8HUbejbkfdLtTn2+/b79sPXad1ndZ1GuTNyJuRNwOGnB1ydshZaBnTMqZlzONbVw+b16ldpnaZ
2uXxf2/8v46i/OZgKsqjOWqlS//fDnP79sOHr179z/U+iN/v8xVEgn8fka5ceeDACRMK6xERFSrU
qgVxcV7v73Ogb9zIzs7MBIPB7c7JgZo1y5QpWhQuXrxz58YNyMuzWqOiwGh0OMLD/6j3QQKB3xz+
h/1bIctms9n8x/apU6dM2bDh4fdfp07NmkWKQP36jRv/fjPig3ofN4+cqmHI94cGbkN4VdPSkJEQ
SKKy8Abo9YUPhWdBWCauMGwAnhK8UiawQtiNCeipzHKPA21obou0MUAF7bZ4GmjNO8IyEBqL/XQ3
INNMnw2IZBENGAQzEpBKPrdAf54OejII1YSqugP4jueVb0EXtCF+CfTeTDf2AGmeECo1B7W3cs5z
EsKTHNbyV6F8lZJjW00H7235e0NjMItlWtv6Qg/HixPaNANHE8/IiP7gv3t/aO5+cArnDqUmQ8hc
w+2wnVB8aWQgrivoA+V+UhEIHVZ0hakvRA63Vc6zQ+Ro+5dSMpgHxu0stw2M+w3jLSvA3SDLcVcC
tb3ngs8JIdNDng1tCo6WMaeLXIDYWlHXY1IhNi4qJnoCRHpDQ6N1KN23aHjpsxDxk+1MyF6I2ufo
aagIph36cPenIDX2vp21CZJSIgfIeyC0m6GMMhVsNulz70YwrKG8MxGsXxlLmRuCt7/HHkiC7G8z
1bTPwbPfvcOnAWYtwfENmOK0o5U1CDtp6lsyBKyNDDctfYG7qt28EBx7THuL50N2M1cgfRj4X9Sn
URSyGqV2cylgeFt/NaQJuFd6k/MbQ6nUmKPF54HtAzktfC+4mvlme49C7PKIROsNsO82LTLtgPhy
Ee3C4yCxQVhR6+fgbZ5/NmAHxwaLKo4CYwv9EyUJMirff/V2X/D/6N+cOgByEz3LMjrBlZVp5U/1
gIsJd8KTl0Lugbyz7uJQ4ViFs0USoESn0kKJ78B0wNQrVAFXMfdO7XuwHnNUCmsKYcS8F5UL967f
+jarFBx98lj2qdtwo2T+Pvdh8NbXPWJf8Iz1bMh9HZyfO++mJYIhy3Ivahm4p+gbzV88voVacHzc
uHHjxo0b9/BxBY7zw8YVONI3b968efPmw+UUXP9Xj60rcGAe9lP/pqKbim4qCssuLLuw7ELhT+xl
d5fdXXY3TM+dnjs9t7Be0P/N8G+GfzP88T3P1I9SP0r9CDpN7jS502TI2ZGzI2cHTN81fdf0XYXj
lj679Nmlz8Ka6DXRa6Kh2Y1mN5rdKPxpP+2jtI/SPnq4ntyduTtzd0J+2fyy+WX/dTuWLV+2fNny
Qjuaj2o+qvkoKDuj7IyyMwod5v9ukpOTk5OTCx33Z4c+O/TZoX9dzuStk7dO3grHBxwfcHwATNg4
YeOEjTC189TOUztDcmxybHJsYUR84oSJEyb+zgGI3xC/IX4DvNfsvWbvNfvn+u4n3E+4nwAnap2o
daJWoYPbNLxpeNNwuNH0RtMbTeHq1atXr159uJw/O39fGb4yfGWAbx3fOr51QCNHI0cjB0wqPqn4
pOJw8eLFixcvwqxKsyrNqvRwPe0+avdRu4/+i8/JY1pXj2te/7fwr6Zq5OVlZd27V1g+yIP9fzZV
IxDw+Xy+3xzn3yLPv5VnznzxxZgxhWVB+8qVo0b16VNY9upVt26ZMrB584QJr70Gs2YNHNi5M2zZ
MnHi669D7dqxsRbLH+UX6H0Qv/+3XGNV/e0cjgdLSTKZzOY/ljZbYmLp0g8vT568etXne7jcAr2P
m0d2nI2LzBnGJyC8T+iBiBjQ3tQnKG4Q8oUQIRVIw6Q3BLbrlYVlIHwgfipNAOET3/TcWaBeyquT
FwLiF8I8815Q+wkZ+ioQautfMxOopI8UIkB3UwIBkBAA9Dwy8IIwhzlCA9C/QRLmgp6lTvNIIHby
XPH0Anq5fd51gInZWgoI1YUqZIFYT3qLqXB/ZVb19Hsg7r721NV0GGvptmrom1DlWIX6ra9CtXp1
XmzVDlplvdS0Uz8wjKvwcWI4/LRyZ6sdq2F7u71ZpzeB8VRgjpYHFRs7wsMbQLxDT/C8B6X8pujc
J6H80zGXjW0hJCmubxkBpL2WfY7u4Nuc9WraGfAPc1509QZjsmwJLQv68yZT5BlI25A3QKsCd6vk
Tvc1gsxtzjJqW0jdnnnQLUL6l9mDXF/CvRYZW3K+BfNxczXJCcJtf5o2DOQuTFaHQlS29RWhMkR/
Z/3CXAMc52SbWgasZ0xvGOPBH6O8Tn3wDlVv5KZCrhjYcyIS0l7LqXnuDGTtCPS8NByctXxfu2NB
usMOgwzu1oEQz3wgXOpvuAfunj5jTkXI3x7Yn7wQ0vvlHLs5AzI+zPnacw8y1jqNae+B4YWw646+
ECI4sqO2gKOd6WvsEGYIOWysAMLLylTTOMi/kJ/geRaMJ6Qzigd4SrTTDtTuot22FrTZ5qa+QSC0
t/XPSYbcS4Hi6Z3hcv17odfiID3Sc+beRSgyslTnsBlQ7HCx1qX7gKAI8db+4C6WXzyQDpZYx6CQ
1yB0dcydmMqQ/llyaN4+OBN75OtTAtx8MfdgbhiodQ3DDaeAzppP6AKsFpoItUF6ITy1aBwoG+TQ
eAGELHG48Cf+gP9ZCs5jLnB8CyJGD57T/M8oSM14MNe5QE6B3AI9f1V+gQOzevXq1atX/7Gsd6He
hXoXYPvU7VO3Ty28bsyYMWPGjIH639T/pv43MHrN6DWjfxfBfXD8o1KkbZG2RdoWRvAKIodZk7Mm
Z00uHLen+57ue7oX1ocuG7ps6DIYcHTA0QFHIfx6+PXw6/9+Ox5MqRliHmIeYobXF7+++PXFEPJ2
yNshbz++5/NnCX0u9LnQ52C2b7Zvtg9a32t9r/W/kJ5UcN8FTJ8xfcb0GbAte1v2tmwYYhpiGmKC
ZeZl5mVmiEuJS4lLKRxvXGxcbFwMsc/HPh/7/D/Xt3nS5kmbf5cz3KRJkyZNmkDjdxq/0/idwvYt
nbZ02vJfvMToz87fvl/2/bLvl8J6QQpMoyuNrjS6AotOLDqx6AT06NGjR48ef9STOD5xfOJ46Jbf
Lb9bfqGevOl50/OmF457XOvqcc3r/xYeTNX4s+WOHUuWvPFGYfkgD/Y/eP3DUzV+O8e5IOL8YOS5
cNw/bm/X7umnq1cHh8Ni+UeR4O7d69WrWvWP8gv0PkhhxPm3+oNlQcT5r5YvvNCoUcWKD5f774o4
P3KqRvHZkb2LfQGGm+ajVgdoK/RsrRwI8dzQb4Nu1bsKm0FMYIrSABghzLN+B76ncmbmXQf/cY8U
ehiMBkMPqQeIndXLgaXAWj1M3ggsF3vqXhA+1eeSD/p+/QK/gtBP6MIyUCP1NloCSF21ksJV8A3I
f9sngJDicXrvgqDLZU0LQGplWqetAeFZWZRbgL5IO6KOAsMG70pPLDQMfdLXvjqEX7fdKpUAvnB/
tncA2LtFDys+AhxGoUGJhhDlTXIrP0GEJ+LNsCdgT589w7Z/BKtSLx3IrAgx0zz19AtQ6kLYRFtb
MMaLu71RUKRrmKg2gbVPaJXIg2M2Q51SA0HbndX3zjoIfJS3Pn0v8LbaU+8JlmohjcMPgLZIXifM
Bv9z/u7aFnDfzxuZngOBSF9IfjuwVze3lAZDZC+bat4E9rOGA9ay4PlUb6yHQVTd8MWGyRAxICwx
LBfSvsr43rMUbIPlz11rwLRRzpT2QVqxLCF1ByS8G9k3rhuk7/ANjR4K6V/66l8ZAPZIa33HaNDH
S++ZVUhf49ZurQNhcV6sfAJCjlu+iy0K0k/WH90bwFbB0Tp0HojdlB8iPgPjr+IdYzJoU0ly/QS3
6t+dkFEWfK96052roWjjmMX2knBzb1oV/SVwJyir0vtDkZzwlnIfCMxRvjAfAncLz3OBcMi+7+6v
zYDIMvZvi5wD16uBgZQCW7RpgXEUlOgYs63cCShyu+gnJQ9B2Ovhw+OXgL9VYLLUENy1/BV8oRB6
LLxDRCw4LkdXjOgI2U+lb3EuhZunT8WeXw93HNlvpg4AbZoxMnQoME99RXgLtK6s950FsYKpcZgJ
hKnakUAEaE/7KmQfAOl+QHfFACUfz0J9MLVi/fr169evL4wI/9nzmAtymx+kQE6B3Ifp/WcUODBJ
o5JGJY36LwZ68PC744iEY8Ix4RjQjGY0A+G4cFz43U/jWj+tn9bvj2IebFcPq4fVw//cTnGgOFAc
+Lv6QnGhuPCP4/R+ej+9H2DFivV3dhZwjGMcAzrTmc5//jn9VTsCVQNVA1UL69JAaaA0EAS7YBfs
II2SRkmj/rm+x03IipAVIStAHCWOEv+B/j87Px8mfpj4YSK0+6LdF+2+gMMvHH7h8AtwqM+hPof6
wMbEjYkbE2HZ1GVTl02FVaxi1b9icA1qUAM2Tt84fePvHM6CfxgfpCBlY3CNwTUG/4OUjT87fwUp
FH8Y939SX/4ZUm2ptlT7n+t5kH91Xf2zeQ3yf1OYqvGPHdnHqef38h+WqhEIeL2/3xz4MB7Wv3z5
oUOXL8OyZUeO3LgBH3zQsmXVqtC5c82apUtD7drlyiUl/Xb9sWN/1PtHPf93xPlBHpaqMX58p07F
iz/c/jt38vLy88Ht/sdy/2MjzuajrnpyEzBUpbtUFECfy23gulBJuAqiT35Nvg0qwmR9LTBMOKQf
AfV97wzpIviaSTVjZ4E4SFqIApTRzrIA9KHCe9wAzusr9EjQ0/EQAezByXnQu+p1mA+G/tJB+Tsw
NDXOMFYB6ZAjMaYuJK/3TTAWhUuLM0fp8yBnuq+YMASkH8XWtAFlo7LLvxNCisQXL/sDhNqjk4p2
BO8Pitd9H4TPxHYMBOUtNdO7FALPBJZ4h4N20vumOg8SesdVqH4Y2q2pLT1dEep/VrlCRB6EDSlR
x1AXlDXGAb6PoYQlemdEDJSLKvtMyAmopltDc2rAEyONktYCwpTokOLLQCKscbGWoDby3cipC674
nCMpE4BLWg2mQOiJ0F8iR0HsmERfUi4k3i36eokhEOqzVYooBcJ1wwy5PITuj14QEQCHyTLF9DWk
7k1rl3MVzmy/WDbtI8jd7A3xLwdbb3uLiGywz7dJtrZQtWfS1uKLoUyPiLhiUWCw08b3JRTLjzpU
4mcoPygsu947UPSSvWHRr8F21WKx1IPSCSXOV24BEbawXpHHIWJCqCluIshTJCmiHHi6qsc8CijD
dXvuHjCJ5unmbhC+1v4iYZDwcdzGkH2giris1SDqzaifHd/Ck2fKlkk4C6Hhto9D+4E0WYiUW4At
1JJs6QlWt62X0QpiM1Nb82GIvR0WnzQfynQtnlFWhvIHKjxTsynYk0O+T/wFcru5Juv5kDPEa1Lu
g7VOZE5kTTCNj5wdmQe5+t2+uVXg1tljL504AakHsvpcPwxqhLmqJRX0V6Ro43nQFH2V3gqEEsLn
FAHuq9u99UCx+dY574NSSX3WdR0UK88pux/fQi1wYIsXL178918kBX/wH3y19p+l4LoHHYcCPf+u
XOjGKxuvbLyysP7Rpo82fbQJ9pXfV35feZgwYcKE3+fiNW3StEnTJoX1ghzc1I2pG1M3wqrGqxqv
agx3x94de3fs47PzmSHPDHlmSGF95sszX575MiwQFggLBMjunN05+19wmP8qtU/UPlH7RGH9swOf
HfjsAMw9MvfI3CP/fXb8Wf7q/Lxpe9P2pq0wx7n6kepHqh+BQbUH1R5UG6xvWt+0vvnHCKuwUFgo
LCzMFS5IMXgYV0KvhF4JhevvXH/n+juF8h/8ZaQgIpwyNmVsylg4+/XZr89+/a8/j2eWPrP0md9t
wvxk3yf7PtkHO7vu7LqzK7w699W5r86FFZdXXF7xCJtnH3VdBfnXKEyd+GsR5yZNBg789tvC8kEe
7P+jnH/sqAcCvx0L9+CpFw/ysPbdu69cSU0t7F+8+MCBK1cefn1BWaD3j+MKNgf+45QKWf4tNePB
cu/e69dTUuD8eZfL4/ljmZ//23nND0/V+A/dHGj7NXJs3CLQO0h1DJdAXM5Y3gclxb870At8T3hW
uauA6ZVQ7J+BsZgwWj8DZ+dcy83sA6ENk7ontQbjaGZow8D7odBWXADCz/ys+0B/h+NaMogzhO7S
YRCqsFFYDfpZalEGnK8583KuweoZa85usIDvc9UcsR2qbXuqTf1toBcx3GUXSD3kNPksiNHaNqUE
aP3EE4ZewMvUEj6HwFP+G/pZEP1Sa7YD6/WuZIKwgrfEycBcMUl9GSiiDZatEOhBmvgWiCsT36la
AiofFj+wr4cSr5sWnJ4FWaXCU3NGgngh76jHBuInie8+4YFKYyrtDVyAxNVpac6pcCopy6esgzNz
xcv2d+BOeXOTpDug3czbmTYKfJ0ym6b2B62o/cvQrWB/L+TLEAVMP1uamhJB/MT+lf0MaAGlk78p
pG3PiRb6gauY57yaC64Z+ouGnSDGyCXVG8BQ7Us9Cu68lnY6wwtsUl8zhEJY89DiljOgvCid8e2H
UttC+hR/AeQEw7yIopB3xuXxLAZ9hrDV9y6Yt2gDw3YCrbXGDADTJLm9+BUYL9EqIg0MfW19cy6C
53uPlHURMo25nfkC1LH+icnnoUypmNjyAQgdL+2LfwVs68Jm4AOlkuuUU4L7I5JV12hI6+VMdVnA
/LJZNZ0GsamwUz0CjjTzZFsPCC0XUS9kHtjHOgxhK8D8oX2mpSL48n0lhd3g/MA5yC+A9K7pHVM4
RKqxi2OWgLmzeadhFORPvN0r9VNIX3Oz31UT5DXJ1W6VBg9GQ/hnoA5ljPF10Kdoc9TfPn+D1Aug
39EP6ZVAG0GsXhmIELLUdSDaiTa+DTxLS73a/1kk7R/fgi3IPS44nzk3Nzc3N7ewXlA+LLL8z07d
eFDPv4uXPS97XvaAX/frfh3WjVg3Yt0IGJExImNEBkTfir4VfQsGFhtYbGAx6BHoEejxuy/k4bbh
tuE2mGmeaZ5phu9Gfjfyu5EQfTv6dvRtSCONtMdgZ+8qvav0rgL3X7j/wv0XYMvELRO3TIRiu4vt
LrYbIidHTo6cDJlbM7dm/htfdNNf76/31+HeyHsj742EDSkbUjakQKWIShGVIgpTFAoc1b+bvzo/
BQ7s9BXTV0xfASNsI2wjbKAeUg+phwo3Y44oPqL4iN/949ghvUN6h3T4sduP3X7sVrhp8GGb2Ao2
VXKe85yHVh+0+qDVB39MFSnYbPc5n/M5sGXSlklbJkGlbyt9W+lb/jJ9+/bt27cvOGc6Zzpnwubd
m3dv3g0bb228tfEW1PbX9tf2F25+/Fd51HUV5F9DVX97hfTDHNl/Xe5/La9A74MEAn6/3w+S9Nup
GQ+j4FSNB7lw4e7d379Y5cH6w64v0PtHe36L/D4sccJms9stFvD5FOX3I7ZvP3gwORk0LRBITf3j
dU88kZRkNkO1ak8++Y8CPAV6HzfCwYMHDx48qOt16tSpU6fOXxfgxtUguyZw2XDS3hWELD7UqoBW
z/+F/xD4YtzdPD6wGcPnRiwC9bL+lq8PnJ+yNfJ4DygZWWd09etgfTX8uGEQqOfVTD0JOKo69W3A
Nn2F+ioIPQ1PGsrB9aS7yeeWQ/HNMbVK1wWlj9JOj4M9GXudR6qD81eXRY0EWjm+L9odSmaW8hX5
Bcrfi19nSAZrF2tR9oNaXm0h3gOpgzCOk6CUVzd794DoF7rLR0F4TaokzgL9ba29tA9YI36iBUB/
DkFIAHG/Lirvgr+Gs0JeBzCmGNqoC0F9wTU54w3Q5me8nPkdSK7I6WGdwXsnc+N9B+iT06emvwHS
LllnBXhTpTueNMhKur4zJx1WX9tT4n4LOD4s+ycpHfxLvOOyZoM/090iezII1eSRlssQ9mZInYhN
4Hg7dIN5I5gchtf0e8BAtbtfBm9F13rvt+DL9m8PfAbKMv2iNgz8sf6r3nTwDXRZcg6A2WlZZx0M
EdmRb4S9Bd477jHeruAp5s5y/gyZVbNyUhuDOl3Y6LwNWnvhZUtRcHb2b89Oh5A8xwqxCvjT3NuE
DyG3vjvX1RPKpcWPK/oZyBfEKEtluBmecfPuUTDUlbdbekHUmjA1tj1E7jGfN5UGbY8+SukCdwfd
GebdBprXOIh14JgQKlkFML8if2O9CTG58RtsCkQ0jywelQmGQeZrIedA+0DZbXgTXKnO8ko+eDPV
DYHhYFHCzoUdg9Bl4XPC7oFYUfvZsAOcUfdz7ncG3zfZA+6kgsenfJ47GbL9rrcDByBvmz4qrCvo
pcV55mMQmMAM6Tnw3Vfe5zUI9Ap0D7SGwAFlpe80KDMCnbzngIXqPc9UkCrpS3w94Vjqvk83nHr8
C7fAsS04PaDAgf5XCQ0NDQ0NhWHDhg0bNuzf7zgH+WsU/DKQ0jqldUpraBPfJr5NfGFu80t7Xtrz
0p7C+sa2G9tubPt3Wx0kyP8OKld+/vlp06BKlZo1y5f/1+V8882HH7ZuXVjv3v2DD/6rUyVOnz56
9MIFOHNm48aRIwvbo6M7d54yBUymYsXi4wvbk5M//viVVwrrRYqMGLF06cPbH+SfjfP5bt++dw/S
07///t13C9sHDz569MYNqFQpIcFq/aPctLT79w0GOHHi3r2/8o+H35+fn5UFrVvXrx8a+sf+s2dT
UtxumDOnZs0SJf683Idx6NChQ4cOPYaIs6Z6fvT2B8O3xqaWI6C10T7WO4Jc1vitoTrIS0yKORHU
EH249j2wxLPePwEcnzv223aB8QvLfENvEDdLdUUTiE8IF4VnQWvLi+oPIEXLGYbXITUve3ZKPlx/
4/qCQ1ugeJu4LnFNIPMLd233IHA6TRNML0GxlWUWViwK/iLut3DDrRn3X3YNhgR3eF/7TbAesZc1
ZINeSxvMUOC43lw/D+JEYaHoB2GJ2En+AvSi+hfaFND684M3C6iorlOHg7RYPGEZCfoRcZDxHsiz
Hesio0Dzq+0CoaB3MExTV4Ky0FLV2RzktpY7se+DOSyyvnk20DMmsXRfYLKjTcxksNyTzHI0RCyu
Pst7BN44XeO9c9/Br8v2XDjxE6ybs7+M+hXce810OjQJlEN5ndL3QfaBzMr33wdvnnujZTGEbwu7
GVEfwk6HlrXbwNIi8pYlH/Rn9CXqANA3KF7/avBX8Y0zbQfXMEs9w2kwnZdjpUGQeTH7S+/34H1W
2R14F+TzxvGBY5CzxNsnewhY25j3WCaCPdKyznYPTIct7XwtQV5jGKdtAdedvBD3TAgrFjEzLAny
a/uNviOQsyK/Y05vEA5LI8RNYPzCMMHwMlwec7PhtRywvWY9ZGgHoVvCGhn9EDWq2MUi6yFyWkhk
eFMIvx3mc3QC0wyTM1QHQznbdvs4CBgCK6Rh4Bqf+5PvSchf57sYeB4kszXHMBbCj8VcjZXAssN6
yGEC5ZW8i959kJF95/atoZCx5m6VC+shEK83zpsH2if6O8L7kJ/krqp9A87uqpxXAwLZWhFtKfir
qd/pI0DZpnfQnwB1v9JX3Qz+6oE3A5Ggj9e2qlNBP6n2DTwDaiDQxPf+oy/Uh1Hg2BY4ugUOdIGD
devWrVu3bj38+oJUjIJNggVygm8U/M+k4Ni5Xd/s+mbXN9CPfvQDmM50phce1/Zm5puZb2b+3dYG
CfK/C037LTKcn5+VlZ8PJpPV+o/OOf6r+P3/OGfY53O7fb5CvQ8SCPz25jxdz8tzOkEU//Emv7+a
wvGwcZrm8Xi9oCj/+M2APt9vdmZnu92KAqGhFov8O++zVKmoKI/nt/OhQ0LgwoXMTEGA/zpeDk8/
XaJEfPxvkWy3u7A9N9fjUZRCvY+bR3aclcmufP0nMNQL+0aMA3Wpf6NaE3yz9PmBZWBsaGpCDMit
5YaGRPAcCnzlawbieWGJNgcMy8ydDe/A/TH3b99cB8p25Vf/92BC+krvCY6jtqHhByH/qZxueT6w
v2q+FjEGTKXN6+0DISrcvtkcAc7VziJnNLiyIqVd7peQWCFyRlQa2HZYXlLrQ8q3aXv9ZaBYo/Ai
plOgNhV8FAFltFIycBiESWJbsRFQlIVCGAjbuS+vBN0murPHgVCbGmJVIFJxqs+CctfpynkKDI3t
TYu0BrWycE+9BLLTcT2uBhjO2sPiKoP2rHLEmQ1qG+/B/ApgrGeuF/0zqDsMq23Pgvq59rIugWaV
XzYfBlv18sfqvwfPly3f5+k+UG5imWobvoYFXX/46nBduLzVKpc6Cd6KrmYZq8AzMP9abiz4d6Rt
vDsEXPPzNpvHQ+iXjvyoaAhJDllhOgi2y9ZXzN9B6LshHzkUiDofVUtNA/9ZzxrXs2BQbIl55SCw
W+krlgYl0avpm0D+tGR+sY6Q1yf3La8GpiaGN8zVQLqrrglJBbfBXdO/AOz7Lf2FUhD/Y0TF6NNg
x/BswmRIm25slfIKhOyyH7BNhKh9Iauid4OzU9G3PX3AMMt4jd3gSAm32vqB5ZrZGfYVGBvKZvtg
CPi17dJT4C8aMBEDOTnpX3hfgMDXag5bQfvV2MXcHixfhY60vAv2quFrI54HqZjvIC7IbXjzePoG
cLXLup/cG5SzysL0j8HWxf6lNh98W5QrlgXgLevf4+8GdtGSpB0CaX1gnrso+D5UKuilQa8vVyAf
lNtaXzUU9KdMcXwISl/dpD8N2jFtkyaCcEkwGP2giMoK+RF+cv2zFDi6BY70g8fIFZzjWkBBLnO1
atWqVav277cvyOOh6qtVX636KixlKUsBhjCEIY8qNUiQII+DJ54oVSoiAu7cSUnJyIC4uISEqKjH
50AXUOAw37//m54CvQ9SsWLx4hERcPr0rVuZmSCKoaEhIRAWNmjQ/Pl/HP+w9n82Ttc9Ho8HNC03
Ny8PqlQpXjwy8o/XhYYajbL826u5/X5ISPgtgSIszGKRJMjKEkVJguLFQ0Pz8qBu3cREmw0kSRDE
/2In3q1bv+nNz9d1WYacHI9HVSElJTfX7y/U+7h55FSNew0uvntjC0Suf2JKsREQSPd0UkuAkqnG
BkaBqbexpeE46LLi8tkgd+TurodCIG+W/pVcFYpcfq7qM20g25PjuVcffMuVYcpoMGUbvxGrwdk3
Lif8mgK5l9TX8l+GMqWil5fqCglq5JqKuXC60wXn8Tw49/5d/4VLcPHM3dNSHajyZsWPWr4AdSZU
yiw2Gp44FrVBaAlCSUNHsRiIG/Ut+grQp2jN1Nugp4pthDQQuwnFDY1BSBX36M9Dqin7+qUBkN7F
O+tGWYgYFtEupBdonzpd2VMg3GJyVvwAQuc4epWrB752WgX3BeADQRZlEHaRIvcC8QstIjAMlBn6
z1obEHWxquENIFGP1lJB+Eqfp58GNV1vICQAFdknRYHtC0sVuRGsCp3R55O7sK7tUeONPqAn2KZH
XQT3ZG/jQD1Q17tL5P4K+kXPzLxrIMraKf9SsL4n50kzwLzL3sWeDw6Lw2KdDSEjrC+ZT4N5utlk
kMEwQh6lPgfar6RoBvCXVj9WvKCf1Eop3UGbp50OdIOASXla1cBTzfu6fzQIK+Vk4XmQ5gpxYk2Q
pgkLhEugLdBaCAKY3Kb3jXtA2yg0134BUxXxGeNLYMg3/2R9ErRw1gjnQJsUaCimgreyt5lWHpx7
vcX8AQiMCmwNZIBaT1okvAVSjPGI7TgYx1vCjfkQXSakrgUo4osdZLsEdwL338j4GfKVnArpX0B2
7dSEi50hNz/N458O6jE2BX4FOU5poyWBaBJXmhoAq41mOQLkD8V1UlHQ3+Ed6R3wT1DL8i7on5Cv
jwUEGgknQU8QfhFXAB+IW6T5oMvaKb0WaG8JN8SdoGeI5+Rp8GO3n0d+v+3xL9wgQYIECfKfQVZW
To7TCb17v/PO11/D+fNXrqQ9jk0WD6FChTJlYmJg8eKpU19+GSIiwsJ+/2bS9PTcXKcTXnhh9OiF
C+HkyStX/tE50Y+LatXKlImPh59+mjixXz+Ijg4N/b092dm/xY4/+ODMmeRkSEv7LfL87yImxmqV
Zfjww8qVixSB8PDH40A/tlQNeZzjO+NaCEzPqZvvBv2V7G9zdoEw3pXisoI+uuy8Ui1BLe3u414O
zuKbz/36NoSZX3y7XT4I+ywJwnFImGh8pegAyB7krpJnhxMZx7UDM8BS1mgMfQk8+2xr9FsQtcNa
Mr4hGN4xlguvCzvSdoXf6Q33Rgg/3O0M7ghpXeAGbD226/z3F8DXyU/Xr6FUYuP1xeuBxWU6T09Q
92uvix4QTol3hTkgjhT2SB1By+VDfwLIC6hnPgPu2nm+rP5wefWVnsdLgXJYn26YD/pC03DNB9Gn
IiKTL0LF7UU+9yVBdLK1ceIuwCIONnhA/0ZEawhMEjaLISBAS2MrED7Uq6sVQF9HDzYA24WlwkQQ
w4XbFANtJp2UAAQ0pYh2EISK/tx8HcQNGU2uA/I4ba76Psh9zF3tG0B7IaxE5CVQfgmpGnEV1F5+
wfk9+Pv7Nud3ACU6MEarCYENWdOyLkKOM+sZuT2Y6hs/FN8Bs8W0w9IeTJUMw02lQQw3zZM2gHRD
kuWDINU1lLPuBOMeuYnYHgzmkL0EAJnntBQQvEwQl4AQokv6BtCa6rcoC8pQPVXrA2o5JZJFkN9c
KcMr4Fub08cbC97egSmKCAExUEK5AOpR9nIW5DWmZPM8MC61rrBNBWMHcwPrQYgbZV9uXAo1Opeb
GbUGanxX8+XKMyDus6TLpabA5ne3zvq6JKS+kTfpZmmo3qCmr20bWL1pzb2fh4C+2fOqoSQ0/a5K
rfrpcCXubIeMsnDs22PlzleAO4uyIrLGgO95ZbDSBSxjTcvMvUA+ZnjV0A+0imoR/V1Qa2lfKidA
/1oYIH4LYnO9uxgK2mX9rmYA7bi+Tx0FdPv3fTkECRIkSJC/nwLHdf36+fNfe+3vtqbQcT106PPP
33zz77am0HGdPfsfb+L7f41Hdpwt85XJ/lYQWH4z7956INLXwlMFtGe8RfwvgnG30KbkGiDUNcv1
M7DFfz2wBEyfxESGVAPDcqbJGyHzLffaDAGOrz8+fN8sSJhp3Bb3FriSzc1d4RCWJoxwJELsprgS
xXvBqVPXvkwTQTwdMjhxAeiLMtekhELRIuWHV2kLKTWu97kyFy4suOq9lgFHtiS1j0iA57pUnGnv
BYFVgWW+SSBvM0VYngX1sLbemwLCKWGOqSjQVy8jhIPhA8tE0y6IKVFBKwMkHz7luTIMSu2WIuJW
gv2SK9LSFq6lbt69Kg7sc0unVWsDwjqho5QE+m3Wy+3BMKLo9jJdQX4nOrvE06Bv1xsyD1gh9CQb
9IX6eXQQkhnFURBr6tFCKTA01BPUD0D4WlusdgXXV84nM++D/Kqy21MaxE7m3Y4NIMdY9kdEgzHP
ciHyEog1LHNsP4Lp51B3uADaFGf/rFjwosRqcyHwvn5PywHtkF5c08HZ3LPWcxzEl13+/MugSOou
/SLQXHdzBoRVwhlxEhgX8oRwHvSdYh/6gP6qsEhwgdCQxUIC6PP5SVwN+iRhISGg9defVfaBHia8
J5YB/TWhqHwXhLXSdrkFSCcNxwwHQT4Z0iDsFlimWabZfgazw7jGfBDiMq1ubSfUaFq8tsUO1VrV
rlL1GYjbXVauIYGySDhnjobASX0mO6Hhu/XdXcaBs4gz0OhdiOiV8FrpzyHa0n1h2T1gX+goU0aG
0EthvYu/BxUya0672w+Stlbvem4ofO9efmvDbfC/l59zzgPJHVO/zq4Iak9xmuQEo8OsWY+CIVFa
YpgPsllaKD4DdMMpdgZ9lRqvnQFtoHJc/wyAcjT6u5d5kCBBggQJEuRx8MiOs7RBPiKdBt3tqG/7
EYRNMWmxo0DowAUhE6gk++Um4Ft+J+76DZC7RL0aPgbk92MiYr8FT0jgfn51yBudl3xvEFTfWrlu
3YUQ3T98erwNDqSfb7xhNIRH27rHTAK9nXzd8CacG3i8+o5dYJxpbVt8MRSfafuyfDTU2lb26lM2
uNAgsmdJQHhe/VJ7GqpmlPVECuAb7Xo2/T0Q3vI0zmoJ2ipZtRUHcbm1v80HeiNDnvEHkC6ZN4rR
kDLwhHy1EqSczX3vQjuwLYj/0JQFEalRjZNmQvn3K/taDgGPuWK1u37Qk7Nq3SsCvgX3Ot/4AfQk
13s5VUGVwss71oLh2Yj46DzgCWFYaDXgLP2UeaA/zzlGA6dIZiVoLYUf+RB8n/g76M3Al+/fgBO0
AfJdQ2fw3g4sci8DDN7D7u0g5OWuyvwFTPmm7Ps2sLa0jwnzQ7EtxRKjUqB9dN/6zarA/fR7t7Nf
gtsrrsXfzYfb/TMGu3pC5mfuEoGpkH/Sv1CoA+4c/ZxyEoTWaqQ+EgKhKlo8uE+o6Vp34AlhnL4e
9GhhD/OAtXxIJogx4lDxKRCjDB8YfgBhgxRp+AbkdYbWxgYgzZAz5IkgjzB4jO+DIUl8S14OjKcz
z4IhWrUG0kGbltHwfnV4rvjzHUo1h6efbUP7kuB9T2wddRN88wNjvdGgHxa/8DUDMVa6LHYG6UVz
mG0RRI2SK1jyQR9DVfNiSCxWdG+TcRAwKVOVreDP9F/2Hwfj+7bd5hYQOK8ODmsLT79avV0VH8TP
Ccso9iokH3Rv01+C7ee2fLrXBSlzMt+4uws8ZsNZeT1YBOUr03EwrTTVNG4A8ZC4TzwKcoThSfm3
43OCMecgQYIECRLkfwiPnOMcJEiQIEGCBAkSJMj/ZApynB/5zYFBggQJEiRIkCBBgvxvIOg4BwkS
JEiQIEGCBAnyJwg6zkGCBAkSJEiQIEGC/AmCjnOQIEGCBAkSJEiQIH+CoOMcJEiQIEGCBAkSJMif
4P8/jq5gt2CQIEGCBAkSJEiQIEH+yP8HQZ0UJZX6QY4AAAAASUVORK5CYII=
--001a11c3923e66ff1304f1d67115--

From donald.coffin@reminetworks.com  Sun Feb  9 18:23:33 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F291F1A0671 for ; Sun,  9 Feb 2014 18:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roMkH9mRlM4B for ; Sun,  9 Feb 2014 18:23:30 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 8B8ED1A040E for ; Sun,  9 Feb 2014 18:23:30 -0800 (PST)
Received: (qmail 2814 invoked by uid 0); 10 Feb 2014 02:22:30 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 10 Feb 2014 02:22:30 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw2 with  id QSNP1n00G2is6CS01SNSYn; Sun, 09 Feb 2014 19:22:29 -0700
X-Authority-Analysis: v=2.1 cv=ar4hV0pV c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=12kg7gOp9WYA:10 a=8dE94GJacnkA:10 a=UGkfVyPCAAAA:8 a=7iSnmKMI2VEA:10 a=rE68L1KyjUoA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=EHBgZ4sUW48RT2DNDQEA:9 a=CjuIK1q_8ugA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=0qEjrYlnuRwA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=ucVnsiOnhKyJgSCjOHsA:9 a=rrzUoaHGUICbb9lY:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=UXMSCUqeL3O6fy7ak+t0ojl60TBmCd9kfqqwVFnFk9M=;  b=K2H3czBd6snKEm2bTaj+fFXnfbwguYkpOlSb9mtc/Bo0nGQu5nV22Z9wTmBWNkE6mkZgmSyFR/hmgFzmrnZgTcX2MvBuFCFtZPs/JDhvdGDheR97Y131KxSI/yiEcNAf;
Received: from [68.5.51.152] (port=49662 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1WCgVs-0007vw-MV; Sun, 09 Feb 2014 19:22:24 -0700
From: "Donald Coffin" 
To: 
Date: Sun, 9 Feb 2014 18:22:16 -0800
Organization: REMI Networks
Message-ID: <001001cf2606$ec119bf0$c434d3d0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01CF25C3.DDEFE290"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac8mBumtdmCYLk+cQNeR5xRZVTrSoA==
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.5.51.152 authed with donald.coffin@reminetworks.com}
Cc: greenbutton-dev 
Subject: [OAUTH-WG] Should data exist for an Oauth access token request to be granted?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Feb 2014 02:23:33 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0011_01CF25C3.DDEFE290
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

We are having a bit of a philosophical discussion regarding the requirement
for data to exist as a requirement for an OAuth 2.0 access token to be
granted and I'd like to get the opinions of the IETF Oauth WG.

 

The two points of view are:

 

.         There are no requirements in "The OAuth 2.0 Framework" [RFC6749]
specification that requires data to exist prior to an access token being
granted and therefore the requirement that data exist should NOT be a
consideration for granting or denying an access token request, as long as
all of the other requirements for granting of an access token are met.



.         There are many potential applications that are a one-shot access
request.  These would be confused if they receive an access token allowing
them to access information that does NOT exist.  

 

A potential solution that might meet both requirements is to add a SCOPE
parameter the client MAY provide indicating an access token should only be
issued if data does exist.  The default would be that absent the SCOPE
parameter the Authorization Server would issue an approved access token
regardless of the existence or absence of data at the time of the request.

 

I'd like to hear what the WG feels is a best practice solution to resolve
our existing implementation conflict.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

 

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

 


------=_NextPart_000_0011_01CF25C3.DDEFE290
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


We are having a =
bit of a philosophical discussion regarding the requirement for data to =
exist as a requirement for an OAuth 2.0 access token to be granted and =
I’d like to get the opinions of the IETF Oauth =
WG.
 
The two points =
of view are:
 
·         =
There are no =
requirements in “The OAuth 2.0 Framework” [RFC6749] =
specification that requires data to exist prior to an access token being =
granted and therefore the requirement that data exist should NOT be a =
consideration for granting or denying an access token request, as long =
as all of the other requirements for granting of an access token are =
met.

·         =
There are many =
potential applications that are a one-shot access request.  These =
would be confused if they receive an access token allowing them to =
access information that does NOT exist.  
 
A potential =
solution that might meet both requirements is to add a SCOPE parameter =
the client MAY provide indicating an access token should only be issued =
if data does exist.  The default would be that absent the SCOPE =
parameter the Authorization Server would issue an approved access token =
regardless of the existence or absence of data at the time of the =
request.
 
I’d like =
to hear what the WG feels is a best practice solution to resolve our =
existing implementation conflict.
 
Best =
regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836
 
Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks=
.com
 

------=_NextPart_000_0011_01CF25C3.DDEFE290--


From wmills_92105@yahoo.com  Sun Feb  9 19:29:57 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B1D1A0799 for ; Sun,  9 Feb 2014 19:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.646
X-Spam-Level: 
X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvsxeBMTGJuJ for ; Sun,  9 Feb 2014 19:29:55 -0800 (PST)
Received: from nm43-vm5.bullet.mail.bf1.yahoo.com (nm43-vm5.bullet.mail.bf1.yahoo.com [216.109.114.236]) by ietfa.amsl.com (Postfix) with ESMTP id 155621A0791 for ; Sun,  9 Feb 2014 19:29:55 -0800 (PST)
Received: from [98.139.214.32] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2014 03:29:55 -0000
Received: from [98.139.212.243] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2014 03:29:54 -0000
Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 10 Feb 2014 03:29:54 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 950404.27970.bm@omp1052.mail.bf1.yahoo.com
Received: (qmail 78832 invoked by uid 60001); 10 Feb 2014 03:29:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392002994; bh=4Nf8HIehqF3HRXf+HSDms6LhVgoTSMXcAi5B1ewnDPs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=N2+UjT0WEiKqDfjOGGBTNHekgtJ8kKZ7N0dGPUgtrJjN1ld7ck9fO2i33yXvncTZ8Z3kXqEu0GB0uD6twd5ZeJfv+f/DRaRH0wweSSr77k1a4KS+rXhkZgqgiUU6hNf8LKax5msmWmACsrm9QS81Li/DMnF0Ft7Pbl68SzMCjLA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ryVYVXPSlqXC0T5NRAuEfvI09iBhLPP1+ae0U0dVFiZccsTerPbgeirMUCqOZ9L93ru5UKxA53fQEkNEuFlVjRGN5y19AK5BXEkNaEuBVYW51Kpa4JOpC44Ac3wAJCc9s11wpVhwhSri1g+1adWen+SZWgRwr2vv8wHM3a04X+c=;
X-YMail-OSG: VgINoCoVM1kzWGn2JWp5x0tg0ZMi5gcVtzjmQuwF.Nz652b 4qzypECzmgU1kshM3LltWgKCYjgIg.QQPHr_VslNDj1MBcSCqBGucmMtFZEz CV2vLV8M6QzNnlxhuj2.lscam0XZkgQIceaCg1AprJYyGae42ECJxtsPgbz6 h62gl1aQZIeXW3S_ljePcu1JCDC.dL59uNEvFV2dj46.PcmXlrhcxBvOuJe4 XE0DKCGkhpNvL4LOba2IuSXkT34GZl.lwDoknIDthQLsuSti3JcKRQAXiEUX ovHFocv6.qjY6q3bRX8TQiMwzP_reauHoQzto5j_TqCSPhL6kxU40C29wSkp PuTOHsCuzEPkZ.2TATpxv_qg0cM_a4aqlPDuuwf2TwOc568UWW16iM3vIZDN HzsYtDdyob4RJcJOZA1QepVdSQLCc57xd0_aupnP2gXHYVpBIJL9d3U5o0u5 BluAXkFhRt0uiGXaEpyo_O7ERpVCr0I_YTV2yoOnpwkp0D8MvJro4ynIRpDC ZgWn6BHofOGqwCpX_d.zExFB.sEhOecEoiIKVA89HWbeO566A100fF8K_jMF .jzgaEKBRTrR7eUQ-
Received: from [99.31.212.42] by web142804.mail.bf1.yahoo.com via HTTP; Sun, 09 Feb 2014 19:29:54 PST
X-Rocket-MIMEInfo: 002.001, QWNjb3VudCBjcmVhdGlvbiBjb3VsZCByZXN1bHQgaW4gYSB0b2tlbi4gwqBEYXRhIHdvdWxkIGJlIHdyaXR0ZW4gYXMgYSByZXN1bHQgb2YgdGhlIHRyYW5zYWN0aW9uLgoKCgpPbiBTdW5kYXksIEZlYnJ1YXJ5IDksIDIwMTQgNjoyMyBQTSwgRG9uYWxkIENvZmZpbiA8ZG9uYWxkLmNvZmZpbkByZW1pbmV0d29ya3MuY29tPiB3cm90ZToKIApXZSBhcmUgaGF2aW5nIGEgYml0IG9mIGEgcGhpbG9zb3BoaWNhbCBkaXNjdXNzaW9uIHJlZ2FyZGluZyB0aGUgcmVxdWlyZW1lbnQgZm9yIGRhdGEgdG8gZXhpc3QgYXMBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.176.634
References: <001001cf2606$ec119bf0$c434d3d0$@reminetworks.com>
Message-ID: <1392002994.51645.YahooMailNeo@web142804.mail.bf1.yahoo.com>
Date: Sun, 9 Feb 2014 19:29:54 -0800 (PST)
From: Bill Mills 
To: Donald Coffin , "oauth@ietf.org" 
In-Reply-To: <001001cf2606$ec119bf0$c434d3d0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-2129327256-1192010599-1392002994=:51645"
Cc: greenbutton-dev 
Subject: Re: [OAUTH-WG] Should data exist for an Oauth access token request to	be granted?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Feb 2014 03:29:57 -0000

---2129327256-1192010599-1392002994=:51645
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Account creation could result in a token. =C2=A0Data would be written as a =
result of the transaction.=0A=0A=0A=0AOn Sunday, February 9, 2014 6:23 PM, =
Donald Coffin  wrote:=0A =0AWe are having a=
 bit of a philosophical discussion regarding the requirement for data to ex=
ist as a requirement for an OAuth 2.0 access token to be granted and I=E2=
=80=99d like to get the opinions of the IETF Oauth WG.=0A=C2=A0=0AThe two p=
oints of view are:=0A=C2=A0=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 There are no requirements in =E2=80=9CThe OAuth 2.0 Framework=E2=
=80=9D [RFC6749] specification that requires data to exist prior to an acce=
ss token being granted and therefore the requirement that data exist should=
 NOT be a consideration for granting or denying an access token request, as=
 long as all of the other requirements for granting of an access token are =
met.=0A=0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There a=
re many potential applications that are a one-shot access request. =C2=A0Th=
ese would be confused if they receive an access token allowing them to acce=
ss information that does NOT exist.=C2=A0 =0A=C2=A0=0AA potential solution =
that might meet both requirements is to add a SCOPE parameter the client MA=
Y provide indicating an access token should only be issued if data does exi=
st.=C2=A0 The default would be that absent the SCOPE parameter the Authoriz=
ation Server would issue an approved access token regardless of the existen=
ce or absence of data at the time of the request.=0A=C2=A0=0AI=E2=80=99d li=
ke to hear what the WG feels is a best practice solution to resolve our exi=
sting implementation conflict.=0A=C2=A0=0ABest regards,=0ADon=0ADonald F. C=
offin=0AFounder/CTO=0A=C2=A0=0AREMI Networks=0A22751 El Prado Suite 6216=0A=
Rancho Santa Margarita, CA=C2=A0 92688-3836=0A=C2=A0=0APhone:=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 (949) 636-8571=0AEmail:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 donald.coffin@reminetworks.com=0A=C2=A0=0A_____________________________=
__________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf=
.org/mailman/listinfo/oauth
---2129327256-1192010599-1392002994=:51645
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Account creation could result in a token.  Da=
ta would be written as a result of the transaction.
 
 
 
 
 
  On Sunday, Februa=
ry 9, 2014 6:23 PM, Donald Coffin <donald.coffin@reminetworks.com> wr=
ote:
  
  
We are having a bit of a philosophical=
 discussion regarding the requirement for data to exist as a requirement fo=
r an OAuth 2.0 access token to be granted and I=E2=80=99d like to get the o=
pinions of the IETF Oauth WG.
  <=
/span>
The two points of view are:
  
=C2=B7&nbs=
p;        There are no requireme=
nts in =E2=80=9CThe OAuth 2.0 Framework=E2=80=9D [RFC6749] specification th=
at requires data to exist prior to an access token being granted and theref=
ore the requirement that data exist should NOT be a consideration for grant=
ing or denying an access token request, as long as all of the other require=
ments for granting of an access token are met.

=C2=B7 &n=
bsp;       There are many potential applications that a=
re a one-shot access request.  These would be confused if they receive=
 an access token allowing them to access information that does NOT exist.&n=
bsp; 
  
A potential solution that might meet both requirements is to=
 add a SCOPE parameter the client MAY provide indicating an access token sh=
ould only be issued if data does exist.  The default would be that abs=
ent the SCOPE parameter the Authorization Server would issue an approved ac=
cess token regardless of the existence or absence of data at the time of th=
e request.
  
I=E2=80=99d like to hear what the WG feels is a best p=
ractice solution to resolve our existing implementation conflict.
  
Best regards,
Don
Donald F. Coffin
Founder/CTO<=
/span>
  
REMI Networks
22751 El Prado Suite 6216
Rancho Sant=
a Margarita, CA  92688-3836
  
Phone: &nbs=
p;    (949) 636-8571
Email:    =
   do=
nald.coffin@reminetworks.com
  

________________________________=
_______________
OAuth mailing list
OAuth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/oauth


  
   
 

---2129327256-1192010599-1392002994=:51645--

From torsten@lodderstedt.net  Sun Feb  9 22:29:45 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EA31A069B for ; Sun,  9 Feb 2014 22:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hvz4RZitB8YB for ; Sun,  9 Feb 2014 22:29:40 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2AD1A07B1 for ; Sun,  9 Feb 2014 22:29:40 -0800 (PST)
Received: from [80.187.99.156] (helo=[100.92.219.10]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1WCkN6-0002JS-QO; Mon, 10 Feb 2014 07:29:39 +0100
Date: Mon, 10 Feb 2014 07:29:03 +0100
Message-ID: 
Importance: normal
From: Torsten Lodderstedt 
To: Donald Coffin , oauth@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_437057223614260"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Cc: greenbutton-dev 
Subject: Re: [OAUTH-WG] Should data exist for an Oauth access token request to	be granted?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Feb 2014 06:29:45 -0000

----_com.android.email_437057223614260
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SGkgRG9uYWxkLMKgCgpkbyB5b3UgbWVhbiBkYXRhIHJlZ2FyZGluZyB0aGUgcGFydGljdWxhciB1
c2VyIGRvIG5vdCBleGlzdCAoMSkgYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG9yICgyKSB0
aGUgcmVzb3VyY2Ugc2VydmVyP8KgCgpSZWdhcmRzLMKgClRvcnN0ZW4uCgotLS0tLS0tLSBVcnNw
csO8bmdsaWNoZSBOYWNocmljaHQgLS0tLS0tLS0KVm9uOiBEb25hbGQgQ29mZmluIDxkb25hbGQu
Y29mZmluQHJlbWluZXR3b3Jrcy5jb20+IApEYXR1bToxMC4wMi4yMDE0ICAwMzoyMiAgKEdNVCsw
MTowMCkgCkFuOiBvYXV0aEBpZXRmLm9yZyAKQ2M6IGdyZWVuYnV0dG9uLWRldiA8Z3JlZW5idXR0
b24tZGV2QGdvb2dsZWdyb3Vwcy5jb20+IApCZXRyZWZmOiBbT0FVVEgtV0ddIFNob3VsZCBkYXRh
IGV4aXN0IGZvciBhbiBPYXV0aCBhY2Nlc3MgdG9rZW4gcmVxdWVzdCB0bwliZSBncmFudGVkPyAK
CldlIGFyZSBoYXZpbmcgYSBiaXQgb2YgYSBwaGlsb3NvcGhpY2FsIGRpc2N1c3Npb24gcmVnYXJk
aW5nIHRoZSByZXF1aXJlbWVudCBmb3IgZGF0YSB0byBleGlzdCBhcyBhIHJlcXVpcmVtZW50IGZv
ciBhbiBPQXV0aCAyLjAgYWNjZXNzIHRva2VuIHRvIGJlIGdyYW50ZWQgYW5kIEnigJlkIGxpa2Ug
dG8gZ2V0IHRoZSBvcGluaW9ucyBvZiB0aGUgSUVURiBPYXV0aCBXRy4KwqAKVGhlIHR3byBwb2lu
dHMgb2YgdmlldyBhcmU6CsKgCsK3wqDCoMKgwqDCoMKgwqDCoCBUaGVyZSBhcmUgbm8gcmVxdWly
ZW1lbnRzIGluIOKAnFRoZSBPQXV0aCAyLjAgRnJhbWV3b3Jr4oCdIFtSRkM2NzQ5XSBzcGVjaWZp
Y2F0aW9uIHRoYXQgcmVxdWlyZXMgZGF0YSB0byBleGlzdCBwcmlvciB0byBhbiBhY2Nlc3MgdG9r
ZW4gYmVpbmcgZ3JhbnRlZCBhbmQgdGhlcmVmb3JlIHRoZSByZXF1aXJlbWVudCB0aGF0IGRhdGEg
ZXhpc3Qgc2hvdWxkIE5PVCBiZSBhIGNvbnNpZGVyYXRpb24gZm9yIGdyYW50aW5nIG9yIGRlbnlp
bmcgYW4gYWNjZXNzIHRva2VuIHJlcXVlc3QsIGFzIGxvbmcgYXMgYWxsIG9mIHRoZSBvdGhlciBy
ZXF1aXJlbWVudHMgZm9yIGdyYW50aW5nIG9mIGFuIGFjY2VzcyB0b2tlbiBhcmUgbWV0LgoKwrfC
oMKgwqDCoMKgwqDCoMKgIFRoZXJlIGFyZSBtYW55IHBvdGVudGlhbCBhcHBsaWNhdGlvbnMgdGhh
dCBhcmUgYSBvbmUtc2hvdCBhY2Nlc3MgcmVxdWVzdC4gwqBUaGVzZSB3b3VsZCBiZSBjb25mdXNl
ZCBpZiB0aGV5IHJlY2VpdmUgYW4gYWNjZXNzIHRva2VuIGFsbG93aW5nIHRoZW0gdG8gYWNjZXNz
IGluZm9ybWF0aW9uIHRoYXQgZG9lcyBOT1QgZXhpc3QuwqAKwqAKQSBwb3RlbnRpYWwgc29sdXRp
b24gdGhhdCBtaWdodCBtZWV0IGJvdGggcmVxdWlyZW1lbnRzIGlzIHRvIGFkZCBhIFNDT1BFIHBh
cmFtZXRlciB0aGUgY2xpZW50IE1BWSBwcm92aWRlIGluZGljYXRpbmcgYW4gYWNjZXNzIHRva2Vu
IHNob3VsZCBvbmx5IGJlIGlzc3VlZCBpZiBkYXRhIGRvZXMgZXhpc3QuwqAgVGhlIGRlZmF1bHQg
d291bGQgYmUgdGhhdCBhYnNlbnQgdGhlIFNDT1BFIHBhcmFtZXRlciB0aGUgQXV0aG9yaXphdGlv
biBTZXJ2ZXIgd291bGQgaXNzdWUgYW4gYXBwcm92ZWQgYWNjZXNzIHRva2VuIHJlZ2FyZGxlc3Mg
b2YgdGhlIGV4aXN0ZW5jZSBvciBhYnNlbmNlIG9mIGRhdGEgYXQgdGhlIHRpbWUgb2YgdGhlIHJl
cXVlc3QuCsKgCknigJlkIGxpa2UgdG8gaGVhciB3aGF0IHRoZSBXRyBmZWVscyBpcyBhIGJlc3Qg
cHJhY3RpY2Ugc29sdXRpb24gdG8gcmVzb2x2ZSBvdXIgZXhpc3RpbmcgaW1wbGVtZW50YXRpb24g
Y29uZmxpY3QuCsKgCkJlc3QgcmVnYXJkcywKRG9uCkRvbmFsZCBGLiBDb2ZmaW4KRm91bmRlci9D
VE8KwqAKUkVNSSBOZXR3b3JrcwoyMjc1MSBFbCBQcmFkbyBTdWl0ZSA2MjE2ClJhbmNobyBTYW50
YSBNYXJnYXJpdGEsIENBwqAgOTI2ODgtMzgzNgrCoApQaG9uZTrCoMKgwqDCoMKgICg5NDkpIDYz
Ni04NTcxCkVtYWlsOsKgwqDCoMKgwqDCoCBkb25hbGQuY29mZmluQHJlbWluZXR3b3Jrcy5jb20K
wqA=

----_com.android.email_437057223614260
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+SGkgRG9uYWxkLCZuYnNwOzxkaXY+
PGJyPjwvZGl2PjxkaXY+ZG8geW91IG1lYW4gZGF0YSByZWdhcmRpbmcgdGhlIHBhcnRpY3VsYXIg
dXNlciBkbyBub3QgZXhpc3QgKDEpIGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBvciAoMikg
dGhlIHJlc291cmNlIHNlcnZlcj8mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlJlZ2Fy
ZHMsJm5ic3A7PC9kaXY+PGRpdj5Ub3JzdGVuLjwvZGl2Pjxicj48YnI+LS0tLS0tLS0gVXJzcHLD
vG5nbGljaGUgTmFjaHJpY2h0IC0tLS0tLS0tPGJyPlZvbjogRG9uYWxkIENvZmZpbiA8ZG9uYWxk
LmNvZmZpbkByZW1pbmV0d29ya3MuY29tPiA8YnI+RGF0dW06MTAuMDIuMjAxNCAgMDM6MjIgIChH
TVQrMDE6MDApIDxicj5Bbjogb2F1dGhAaWV0Zi5vcmcgPGJyPkNjOiBncmVlbmJ1dHRvbi1kZXYg
PGdyZWVuYnV0dG9uLWRldkBnb29nbGVncm91cHMuY29tPiA8YnI+QmV0cmVmZjogW09BVVRILVdH
XSBTaG91bGQgZGF0YSBleGlzdCBmb3IgYW4gT2F1dGggYWNjZXNzIHRva2VuIHJlcXVlc3QgdG8J
YmUgZ3JhbnRlZD8gPGJyPjxicj48ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPldlIGFyZSBoYXZpbmcgYSBiaXQgb2Yg
YSBwaGlsb3NvcGhpY2FsIGRpc2N1c3Npb24gcmVnYXJkaW5nIHRoZSByZXF1aXJlbWVudCBmb3Ig
ZGF0YSB0byBleGlzdCBhcyBhIHJlcXVpcmVtZW50IGZvciBhbiBPQXV0aCAyLjAgYWNjZXNzIHRv
a2VuIHRvIGJlIGdyYW50ZWQgYW5kIEnigJlkIGxpa2UgdG8gZ2V0IHRoZSBvcGluaW9ucyBvZiB0
aGUgSUVURiBPYXV0aCBXRy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJp
YSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSB0d28gcG9pbnRz
IG9mIHZpZXcgYXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1
b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh
c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozOS4wcHQ7dGV4dC1pbmRl
bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IS0tW2lmICFzdXBwb3J0TGlzdHNd
LS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3Bh
biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90
O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90Oywm
cXVvdDtzZXJpZiZxdW90OyI+VGhlcmUgYXJlIG5vIHJlcXVpcmVtZW50cyBpbiDigJxUaGUgT0F1
dGggMi4wIEZyYW1ld29ya+KAnSBbUkZDNjc0OV0gc3BlY2lmaWNhdGlvbiB0aGF0IHJlcXVpcmVz
IGRhdGEgdG8gZXhpc3QgcHJpb3IgdG8gYW4gYWNjZXNzIHRva2VuIGJlaW5nIGdyYW50ZWQgYW5k
IHRoZXJlZm9yZSB0aGUgcmVxdWlyZW1lbnQgdGhhdCBkYXRhIGV4aXN0IHNob3VsZCBOT1QgYmUg
YSBjb25zaWRlcmF0aW9uIGZvciBncmFudGluZyBvciBkZW55aW5nIGFuIGFjY2VzcyB0b2tlbiBy
ZXF1ZXN0LCBhcyBsb25nIGFzIGFsbCBvZiB0aGUgb3RoZXIgcmVxdWlyZW1lbnRzIGZvciBncmFu
dGluZyBvZiBhbiBhY2Nlc3MgdG9rZW4gYXJlIG1ldC48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD48cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM5LjBw
dDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhLS1baWYgIXN1
cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpT
eW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6
Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRp
Zl0tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1i
cmlhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGVyZSBhcmUgbWFueSBwb3RlbnRpYWwgYXBw
bGljYXRpb25zIHRoYXQgYXJlIGEgb25lLXNob3QgYWNjZXNzIHJlcXVlc3QuICZuYnNwO1RoZXNl
IHdvdWxkIGJlIGNvbmZ1c2VkIGlmIHRoZXkgcmVjZWl2ZSBhbiBhY2Nlc3MgdG9rZW4gYWxsb3dp
bmcgdGhlbSB0byBhY2Nlc3MgaW5mb3JtYXRpb24gdGhhdCBkb2VzIE5PVCBleGlzdC4mbmJzcDsg
PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2Vy
aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1icmlh
JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5BIHBvdGVudGlhbCBzb2x1dGlvbiB0aGF0IG1pZ2h0
IG1lZXQgYm90aCByZXF1aXJlbWVudHMgaXMgdG8gYWRkIGEgU0NPUEUgcGFyYW1ldGVyIHRoZSBj
bGllbnQgTUFZIHByb3ZpZGUgaW5kaWNhdGluZyBhbiBhY2Nlc3MgdG9rZW4gc2hvdWxkIG9ubHkg
YmUgaXNzdWVkIGlmIGRhdGEgZG9lcyBleGlzdC4mbmJzcDsgVGhlIGRlZmF1bHQgd291bGQgYmUg
dGhhdCBhYnNlbnQgdGhlIFNDT1BFIHBhcmFtZXRlciB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg
d291bGQgaXNzdWUgYW4gYXBwcm92ZWQgYWNjZXNzIHRva2VuIHJlZ2FyZGxlc3Mgb2YgdGhlIGV4
aXN0ZW5jZSBvciBhYnNlbmNlIG9mIGRhdGEgYXQgdGhlIHRpbWUgb2YgdGhlIHJlcXVlc3QuPG86
cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYm
cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1
b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5J4oCZZCBsaWtlIHRvIGhlYXIgd2hhdCB0aGUgV0cgZmVl
bHMgaXMgYSBiZXN0IHByYWN0aWNlIHNvbHV0aW9uIHRvIHJlc29sdmUgb3VyIGV4aXN0aW5nIGlt
cGxlbWVudGF0aW9uIGNvbmZsaWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YW1icmlhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkJl
c3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToyNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QnJ1c2ggU2NyaXB0
IE1UJnF1b3Q7Ij5Eb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkRvbmFsZCBGLiBDb2ZmaW48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPkZvdW5kZXIvQ1RPPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi
PlJFTUkgTmV0d29ya3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjIyNzUxIEVsIFByYWRvIFN1aXRlIDYyMTY8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQiPlJhbmNobyBTYW50YSBNYXJnYXJpdGEsIENBJm5ic3A7IDkyNjg4LTM4
MzY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UGhvbmU6Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICg5NDkpIDYzNi04NTcxPG86cD48L286cD48L3NwYW4+PC9w
PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5FbWFp
bDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOmRv
bmFsZC5jb2ZmaW5AcmVtaW5ldHdvcmtzLmNvbSI+ZG9uYWxkLmNvZmZpbkByZW1pbmV0d29ya3Mu
Y29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD48L2Rpdj48L2JvZHk+

----_com.android.email_437057223614260--



From donald.coffin@reminetworks.com  Sun Feb  9 23:31:33 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6562B1A07B9 for ; Sun,  9 Feb 2014 23:31:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Level: 
X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcfxSoVzeBYy for ; Sun,  9 Feb 2014 23:31:31 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 2B60D1A03B5 for ; Sun,  9 Feb 2014 23:31:31 -0800 (PST)
Received: (qmail 23771 invoked by uid 0); 10 Feb 2014 07:31:26 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 10 Feb 2014 07:31:26 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by CMOut01 with  id QXXJ1n0092is6CS01XXMe0; Mon, 10 Feb 2014 00:31:25 -0700
X-Authority-Analysis: v=2.1 cv=F57EKMRN c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=gGStWv32vzkA:10 a=8dE94GJacnkA:10 a=UGkfVyPCAAAA:8 a=ff6EgXNWp8gA:10 a=rE68L1KyjUoA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=_Y5QVBCcAAAA:8 a=48vgC7mUAAAA:8 a=HTztE06Fc_vDRZI0oYUA:9 a=uryOKfb1IghKoyvn:21 a=W7Sgr-WvrjalrT2w:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=0qEjrYlnuRwA:10 a=B6qkqdRczAkA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=mDviJVZEjCpv9u29nyoA:9 a=teuh10d_fqJw87Hw:21 a=eSXRYbAHew6GfYFd:21 a=GBv-Q5E5aJCooP1C:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=lt2zckDBThsA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=IZfhti9V1t195s9PBizBNY164gqyR1cbn8hhEkFXYWo=;  b=FrDf3LD7bCrV6okkLgGXqD2sphDyjX1k0RbkvDYVxUQFw2jxSQ70+PS4+WzfHM+gq3SnF48aN3ZyRvBnvNZrOGhnNbK/DEg/ZDQVFgA9puETx1fARm0Ee4hDueoFpO2e;
Received: from [68.5.51.152] (port=52136 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1WClKo-0001fL-Mc; Mon, 10 Feb 2014 00:31:18 -0700
From: "Donald Coffin" 
To: "'Torsten Lodderstedt'" , 
References: 
In-Reply-To: 
Date: Sun, 9 Feb 2014 23:31:06 -0800
Organization: REMI Networks
Message-ID: <004a01cf2632$110982d0$331c8870$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01CF25EF.02E865B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFPReOHJHalUPq8CVr/LBI/fBZi4put14Sw
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.5.51.152 authed with donald.coffin@reminetworks.com}
Cc: 'greenbutton-dev' 
Subject: Re: [OAUTH-WG] Should data exist for an Oauth access token request to	be granted?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Feb 2014 07:31:33 -0000

This is a multipart message in MIME format.

------=_NextPart_000_004B_01CF25EF.02E865B0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Torsten,

=20

I apologize if this is a duplicate response, but I just realized I =
responded to my greenbutton-dev email address in my initial response and =
wanted to be sure you got my reply.

=20

For the situation under discussion, there is no data at the (2) resource =
server available for the client to access at the time the resource owner =
grants them access.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:         =
donald.coffin@reminetworks.com

=20

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20
Sent: Sunday, February 09, 2014 10:29 PM
To: Donald Coffin; oauth@ietf.org
Cc: greenbutton-dev
Subject: AW: [OAUTH-WG] Should data exist for an Oauth access token =
request to be granted?

=20

Hi Donald,=20

=20

do you mean data regarding the particular user do not exist (1) at the =
authorization server or (2) the resource server?=20

=20

Regards,=20

Torsten.



-------- Urspr=C3=BCngliche Nachricht --------
Von: Donald Coffin=20
Datum:10.02.2014 03:22 (GMT+01:00)=20
An: oauth@ietf.org=20
Cc: greenbutton-dev=20
Betreff: [OAUTH-WG] Should data exist for an Oauth access token request =
to be granted?=20

We are having a bit of a philosophical discussion regarding the =
requirement for data to exist as a requirement for an OAuth 2.0 access =
token to be granted and I=E2=80=99d like to get the opinions of the IETF =
Oauth WG.

=20

The two points of view are:

=20

=C2=B7         There are no requirements in =E2=80=9CThe OAuth 2.0 =
Framework=E2=80=9D [RFC6749] specification that requires data to exist =
prior to an access token being granted and therefore the requirement =
that data exist should NOT be a consideration for granting or denying an =
access token request, as long as all of the other requirements for =
granting of an access token are met.




=C2=B7         There are many potential applications that are a one-shot =
access request.  These would be confused if they receive an access token =
allowing them to access information that does NOT exist. =20

=20

A potential solution that might meet both requirements is to add a SCOPE =
parameter the client MAY provide indicating an access token should only =
be issued if data does exist.  The default would be that absent the =
SCOPE parameter the Authorization Server would issue an approved access =
token regardless of the existence or absence of data at the time of the =
request.

=20

I=E2=80=99d like to hear what the WG feels is a best practice solution =
to resolve our existing implementation conflict.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20


------=_NextPart_000_004B_01CF25EF.02E865B0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Hi =
Torsten,
 
I =
apologize if this is a duplicate response, but I just realized I =
responded to my greenbutton-dev email address in my initial response and =
wanted to be sure you got my reply.
 
For the =
situation under discussion, there is no data at the (2) resource server =
available for the client to access at the time the resource owner grants =
them access.
 
=

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
=

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA=C2=A0 92688-3836
 
=

Phone:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 (949) 636-8571
Email:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 donald.coffin@reminetworks.com=

 
=

From:=
 =
Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 
Sent: =
Sunday, February 09, 2014 10:29 PM
To: Donald Coffin; =
oauth@ietf.org
Cc: greenbutton-dev
Subject: AW: =
[OAUTH-WG] Should data exist for an Oauth access token request to be =
granted?
 
Hi =
Donald, 
 
do you mean data regarding the particular user do not =
exist (1) at the authorization server or (2) the resource =
server? 
 
Regards, 
Torsten.


-------- Urspr=C3=BCngliche =
Nachricht --------
Von: Donald Coffin 
Datum:10.02.2014 03:22 =
(GMT+01:00) 
An: oauth@ietf.org =

Cc: greenbutton-dev 
Betreff: [OAUTH-WG] Should data exist for an =
Oauth access token request to be granted? 
We are having a bit of a =
philosophical discussion regarding the requirement for data to exist as =
a requirement for an OAuth 2.0 access token to be granted and =
I=E2=80=99d like to get the opinions of the IETF Oauth =
WG.
 
The two points of view =
are:
 
=C2=B7        =
; There are no =
requirements in =E2=80=9CThe OAuth 2.0 Framework=E2=80=9D [RFC6749] =
specification that requires data to exist prior to an access token being =
granted and therefore the requirement that data exist should NOT be a =
consideration for granting or denying an access token request, as long =
as all of the other requirements for granting of an access token are =
met.


=C2=B7        =
; There are many =
potential applications that are a one-shot access request.  These =
would be confused if they receive an access token allowing them to =
access information that does NOT exist.  
 
A potential solution that might =
meet both requirements is to add a SCOPE parameter the client MAY =
provide indicating an access token should only be issued if data does =
exist.  The default would be that absent the SCOPE parameter the =
Authorization Server would issue an approved access token regardless of =
the existence or absence of data at the time of the =
request.
 
I=E2=80=99d like to hear what =
the WG feels is a best practice solution to resolve our existing =
implementation conflict.
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO<=
o:p>
 <=
/o:p>
REMI =
Networks
22751 El =
Prado Suite 6216
Rancho =
Santa Margarita, CA  92688-3836
 <=
/o:p>
Phone: =
     (949) 636-8571
Email: =
      donald.coffin@reminetworks=
.com
 <=
/o:p>

------=_NextPart_000_004B_01CF25EF.02E865B0--


From donald.coffin@reminetworks.com  Sun Feb  9 23:35:06 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F961A07BB for ; Sun,  9 Feb 2014 23:35:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Level: 
X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w6sxfHGo53D for ; Sun,  9 Feb 2014 23:35:04 -0800 (PST)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 112BD1A07B9 for ; Sun,  9 Feb 2014 23:35:04 -0800 (PST)
Received: (qmail 1722 invoked by uid 0); 10 Feb 2014 07:35:01 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy3.mail.unifiedlayer.com with SMTP; 10 Feb 2014 07:35:01 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw3 with  id Qeav1n0042is6CS01eayPZ; Mon, 10 Feb 2014 07:35:00 -0700
X-Authority-Analysis: v=2.1 cv=RodWckWK c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=tDaU07nXRuMA:10 a=8dE94GJacnkA:10 a=UGkfVyPCAAAA:8 a=ff6EgXNWp8gA:10 a=rE68L1KyjUoA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=CjxXgO3LAAAA:8 a=48vgC7mUAAAA:8 a=Nsc6n_Ga5scsHIQRdzMA:9 a=0_GzCJyVQkVxtabE:21 a=dkuNRkQYqeeHP8B6:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=0qEjrYlnuRwA:10 a=rC2wZJ5BpNYA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=ldFFRV91ZxNj12Qa:21 a=JyGeHXo7Zhd4kt7k:21 a=hYlg6MTs17f2RTJ5:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=k4IfRK0+rrzHxE3wrkjmmyD3lyzWEP2Iwg6Og1ZVNWA=;  b=XRI/w/AHPS1CHEnqGDIXriIOA4pOWPtKUToxn7B7Mt5zu/UlKUrkw1Sapuw//ZqtbGTJFtFx3T3zfPM7kU415/J2pQeGfEj4CvME8NlGEYDxf7orzLh3f5RMTGCqdyPJ;
Received: from [68.5.51.152] (port=52144 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1WClOK-0003j7-Ew; Mon, 10 Feb 2014 00:34:56 -0700
From: "Donald Coffin" 
To: "'Bill Mills'" , 
References: <001001cf2606$ec119bf0$c434d3d0$@reminetworks.com> <1392002994.51645.YahooMailNeo@web142804.mail.bf1.yahoo.com>
In-Reply-To: <1392002994.51645.YahooMailNeo@web142804.mail.bf1.yahoo.com>
Date: Sun, 9 Feb 2014 23:34:44 -0800
Organization: REMI Networks
Message-ID: <004f01cf2632$92d55af0$b88010d0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01CF25EF.84B4B300"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHmau5dQRvpJpjiP1fC/Rh+k27e5wHwmLqxmnAJmoA=
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.5.51.152 authed with donald.coffin@reminetworks.com}
Cc: 'greenbutton-dev' 
Subject: Re: [OAUTH-WG] Should data exist for an Oauth access token request	to	be granted?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Feb 2014 07:35:06 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0050_01CF25EF.84B4B300
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Bill,

=20

Thanks for your response. =20

=20

Although in theory you are correct, the particular application being =
implemented collects energy usage data from meters on a periodic basis =
(i.e. once every 24 hours).  Therefore, even with an account creation, =
as suggested, there would be a significant delay after the account is =
created before a client would be able to access the resource =
owner=E2=80=99s data.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:         =
donald.coffin@reminetworks.com

=20

From: Bill Mills [mailto:wmills_92105@yahoo.com]=20
Sent: Sunday, February 09, 2014 7:30 PM
To: Donald Coffin; oauth@ietf.org
Cc: greenbutton-dev
Subject: Re: [OAUTH-WG] Should data exist for an Oauth access token =
request to be granted?

=20

Account creation could result in a token.  Data would be written as a =
result of the transaction.

=20

On Sunday, February 9, 2014 6:23 PM, Donald Coffin =
 wrote:

We are having a bit of a philosophical discussion regarding the =
requirement for data to exist as a requirement for an OAuth 2.0 access =
token to be granted and I=E2=80=99d like to get the opinions of the IETF =
Oauth WG.

=20

The two points of view are:

=20

=C2=B7         There are no requirements in =E2=80=9CThe OAuth 2.0 =
Framework=E2=80=9D [RFC6749] specification that requires data to exist =
prior to an access token being granted and therefore the requirement =
that data exist should NOT be a consideration for granting or denying an =
access token request, as long as all of the other requirements for =
granting of an access token are met.

=C2=B7         There are many potential applications that are a one-shot =
access request.  These would be confused if they receive an access token =
allowing them to access information that does NOT exist. =20

=20

A potential solution that might meet both requirements is to add a SCOPE =
parameter the client MAY provide indicating an access token should only =
be issued if data does exist.  The default would be that absent the =
SCOPE parameter the Authorization Server would issue an approved access =
token regardless of the existence or absence of data at the time of the =
request.

=20

I=E2=80=99d like to hear what the WG feels is a best practice solution =
to resolve our existing implementation conflict.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20


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




------=_NextPart_000_0050_01CF25EF.84B4B300
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Bill,
 
Thanks =
for your response.=C2=A0 
 
Although =
in theory you are correct, the particular application being implemented =
collects energy usage data from meters on a periodic basis (i.e. once =
every 24 hours).=C2=A0 Therefore, even with an account creation, as =
suggested, there would be a significant delay after the account is =
created before a client would be able to access the resource =
owner=E2=80=99s data.
 
=

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
=

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA=C2=A0 92688-3836
 
=

Phone:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 (949) 636-8571
Email:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 donald.coffin@reminetworks.com=

 
=

From:=
 =
Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: Sunday, =
February 09, 2014 7:30 PM
To: Donald Coffin; =
oauth@ietf.org
Cc: greenbutton-dev
Subject: Re: =
[OAUTH-WG] Should data exist for an Oauth access token request to be =
granted?
 
Account =
creation could result in a token.  Data would be written as a =
result of the transaction.
 
O=
n Sunday, February 9, 2014 6:23 PM, Donald Coffin <donald.coffin@reminetworks=
.com> wrote:
We are having a bit =
of a philosophical discussion regarding the requirement for data to =
exist as a requirement for an OAuth 2.0 access token to be granted and =
I=E2=80=99d like to get the opinions of the IETF Oauth WG.
 
The two points of =
view are:
 
=C2=B7      =
;   There are no =
requirements in =E2=80=9CThe OAuth 2.0 Framework=E2=80=9D [RFC6749] =
specification that requires data to exist prior to an access token being =
granted and therefore the requirement that data exist should NOT be a =
consideration for granting or denying an access token request, as long =
as all of the other requirements for granting of an access token are =
met.
=C2=B7      =
;   There are many =
potential applications that are a one-shot access request.  These =
would be confused if they receive an access token allowing them to =
access information that does NOT exist.  
 
A potential solution =
that might meet both requirements is to add a SCOPE parameter the client =
MAY provide indicating an access token should only be issued if data =
does exist.  The default would be that absent the SCOPE parameter =
the Authorization Server would issue an approved access token regardless =
of the existence or absence of data at the time of the =
request.
 
I=E2=80=99d like to =
hear what the WG feels is a best practice solution to resolve our =
existing implementation conflict.
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
22751 El =
Prado Suite 6216
Rancho Santa =
Margarita, CA  92688-3836
 
Phone: &n=
bsp;    (949) 636-8571
Email: &n=
bsp;     donald.coffin@reminetworks.com
 

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

=


------=_NextPart_000_0050_01CF25EF.84B4B300--


From wmills_92105@yahoo.com  Sun Feb  9 23:39:54 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3D31A07BE for ; Sun,  9 Feb 2014 23:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUwHmfuEstbY for ; Sun,  9 Feb 2014 23:39:52 -0800 (PST)
Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) by ietfa.amsl.com (Postfix) with ESMTP id 08F131A07BC for ; Sun,  9 Feb 2014 23:39:51 -0800 (PST)
Received: from [66.196.81.174] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2014 07:39:51 -0000
Received: from [98.139.212.233] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2014 07:39:51 -0000
Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 10 Feb 2014 07:39:51 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 873266.4743.bm@omp1042.mail.bf1.yahoo.com
Received: (qmail 26527 invoked by uid 60001); 10 Feb 2014 07:39:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392017991; bh=1Sk2aH/Q+0KuOG/AYa3HadjU2ub2lheawbPpeAvP1+U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rE/WoyPYj6T3lpNxM4nV51W3eNkkuv78M5VvQKMu88Fb3w1a2jxTla3tlbhunHLmhDjhnJQSWZ554NbFHFRZfhZZEAcRMmLtBhf3cJmiN26VdJfCIg3FLJstoFYZxRkAWoPS4YlFOAKVa/Uv1kyBf/mqrLJ7TrnT7aOnB06WGNk=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Z/r2H09Bzckj2zPt1eaVPAB8PRpveIsGOz6i0HsLlBZAgC7RuqKkBQLagurNMkMvxkvQIvTFlOPMOyNLO4kA7nBzbULrVBPuaIlkfdppN+MtobAHY8Pju/QLES4GXJ1v8BEg0a4AL7MqApz+EJ8oak47sfsDfjB7V+uR7xX61mg=;
X-YMail-OSG: OHW2UxEVM1lfYlrD2stqqOLOB8BRMdiXeiCznPNXYwFRYvJ Qnyb.U9QawbXJioqeURnZN7o4tHph3X5j6Hl_cXFbTzBIM.EY8tpy_ecAodl S7wE2NnfLPimkpSYam1iJich5t2QRKoTNlkRsUaXIOrtvDEe22heyX181Jiq BNW6JlftwWVDD8viVr0mye7bdWT1Z4_KS3vVJoZMMKWx1uMIQYl4J.dyr3S7 Gl3zgkjo6F.fPO.11kWdg9aK..D3BQtwTJ91QiSR3k9e2mFrpQAX.RYiiZ5g EvesbY6ikkfKs65OQgRM6iIj0KlBrkMo6f4ur8KrEs4LYwsUcg8.lSqLPdje UjufTJ2Jq5JZa1.Mn3kQgdAZ3VgkCfeyPtmWxmw.3apoaDPb5W6muIkVojge 5xJ.PwzgfTzOf.veDFi0Uqeyr2k5oIt.n1j9Kbi2fzv_3CdP78KwugW2CfkD aZGAhGwXQ7ESblxRHDGgEplzpJRnpm25H3qxSh8UxXfygTss0MykTHO_6qoL DoJNwgEH2phdSRwCaMS5kT04J6F48Ricq.nJh01fbArTE3FxcEUt59VITmCo v.cabDPllUJ97aWIkAbdYP5Dbbg--
Received: from [209.131.62.115] by web142806.mail.bf1.yahoo.com via HTTP; Sun, 09 Feb 2014 23:39:51 PST
X-Rocket-MIMEInfo: 002.001, U28gdGhlcmUgbWlnaHQgbm90IGJlIGFueSBhY2NvdW50IHNwZWNpZmljIGRhdGEsIGJ1dCBpbiB0aGUgZW5kIHlvdSBoYXZlIGEgdHJ1c3QgcmVsYXRpb25zaGlwIGluIHRoZSBhdXRoZW50aWNhdGlvbiB3aGljaCBoYXMgbWluaW1hbCBkYXRhLiDCoEJleW9uZCB0aGF0IHlvdSdyZSB1c2luZyBPYXV0aCBmb3Igcm9sZXMgYmFzZWQgYWNjZXNzIGNvbnRyb2wsIHdoaWNoIGlzIGZpbmUgaW4gbXkgb3Bpbmlvbi4KCgoKT24gU3VuZGF5LCBGZWJydWFyeSA5LCAyMDE0IDExOjM1IFBNLCBEb25hbGQgQ29mZmluIDwBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.176.634
References: <001001cf2606$ec119bf0$c434d3d0$@reminetworks.com> <1392002994.51645.YahooMailNeo@web142804.mail.bf1.yahoo.com> <004f01cf2632$92d55af0$b88010d0$@reminetworks.com>
Message-ID: <1392017991.92745.YahooMailNeo@web142806.mail.bf1.yahoo.com>
Date: Sun, 9 Feb 2014 23:39:51 -0800 (PST)
From: Bill Mills 
To: Donald Coffin , "oauth@ietf.org" 
In-Reply-To: <004f01cf2632$92d55af0$b88010d0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="515012262-606390983-1392017991=:92745"
Cc: 'greenbutton-dev' 
Subject: Re: [OAUTH-WG] Should data exist for an Oauth access token request	to	be granted?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Feb 2014 07:39:54 -0000

--515012262-606390983-1392017991=:92745
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

So there might not be any account specific data, but in the end you have a =
trust relationship in the authentication which has minimal data. =C2=A0Beyo=
nd that you're using Oauth for roles based access control, which is fine in=
 my opinion.=0A=0A=0A=0AOn Sunday, February 9, 2014 11:35 PM, Donald Coffin=
  wrote:=0A =0ABill,=0A=C2=A0=0AThanks for =
your response.=C2=A0 =0A=C2=A0=0AAlthough in theory you are correct, the pa=
rticular application being implemented collects energy usage data from mete=
rs on a periodic basis (i.e. once every 24 hours).=C2=A0 Therefore, even wi=
th an account creation, as suggested, there would be a significant delay af=
ter the account is created before a client would be able to access the reso=
urce owner=E2=80=99s data.=0A=C2=A0=0ABest regards,=0ADon=0ADonald F. Coffi=
n=0AFounder/CTO=0A=C2=A0=0AREMI Networks=0A22751 El Prado Suite 6216=0ARanc=
ho Santa Margarita, CA=C2=A0 92688-3836=0A=C2=A0=0APhone:=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 (949) 636-8571=0AEmail:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 do=
nald.coffin@reminetworks.com=0A=C2=A0=0AFrom:Bill Mills [mailto:wmills_9210=
5@yahoo.com] =0ASent: Sunday, February 09, 2014 7:30 PM=0ATo: Donald Coffin=
; oauth@ietf.org=0ACc: greenbutton-dev=0ASubject: Re: [OAUTH-WG] Should dat=
a exist for an Oauth access token request to be granted?=0A=C2=A0=0AAccount=
 creation could result in a token. =C2=A0Data would be written as a result =
of the transaction.=0A=C2=A0=0AOn Sunday, February 9, 2014 6:23 PM, Donald =
Coffin  wrote:=0AWe are having a bit of a p=
hilosophical discussion regarding the requirement for data to exist as a re=
quirement for an OAuth 2.0 access token to be granted and I=E2=80=99d like =
to get the opinions of the IETF Oauth WG.=0A=C2=A0=0AThe two points of view=
 are:=0A=C2=A0=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The=
re are no requirements in =E2=80=9CThe OAuth 2.0 Framework=E2=80=9D [RFC674=
9] specification that requires data to exist prior to an access token being=
 granted and therefore the requirement that data exist should NOT be a cons=
ideration for granting or denying an access token request, as long as all o=
f the other requirements for granting of an access token are met.=0A=C2=B7=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There are many potential a=
pplications that are a one-shot access request. =C2=A0These would be confus=
ed if they receive an access token allowing them to access information that=
 does NOT exist.=C2=A0 =0A=C2=A0=0AA potential solution that might meet bot=
h requirements is to add a SCOPE parameter the client MAY provide indicatin=
g an access token should only be issued if data does exist.=C2=A0 The defau=
lt would be that absent the SCOPE parameter the Authorization Server would =
issue an approved access token regardless of the existence or absence of da=
ta at the time of the request.=0A=C2=A0=0AI=E2=80=99d like to hear what the=
 WG feels is a best practice solution to resolve our existing implementatio=
n conflict.=0A=C2=A0=0ABest regards,=0ADon=0ADonald F. Coffin=0AFounder/CTO=
=0A=C2=A0=0AREMI Networks=0A22751 El Prado Suite 6216=0ARancho Santa Margar=
ita, CA=C2=A0 92688-3836=0A=C2=A0=0APhone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (9=
49) 636-8571=0AEmail:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@rem=
inetworks.com=0A=C2=A0=0A=0A_______________________________________________=
=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listi=
nfo/oauth
--515012262-606390983-1392017991=:92745
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


So there might not be any account specific data, b=
ut in the end you have a trust relationship in the authentication which has=
 minimal data.  Beyond that you're using Oauth for roles based access =
control, which is fine in my opinion.
 
 
 
 
 
  On Sunday, February 9, 2014 11:3=
5 PM, Donald Coffin <donald.coffin@reminetworks.com> wrote:
  
  
Bill,
 =
 
T=
hanks for your response.  
  
Although in theory you are correct, the particular =
application being implemented collects energy usage data from meters on a p=
eriodic basis (i.e. once every 24 hours).  Therefore, even with an acc=
ount creation, as suggested, there would be a significant delay after the a=
ccount is created before a client would be able to access the resource owne=
r=E2=80=99s data.
  
Best regards,
Don
Donald F. C=
offin
Fo=
under/CTO
  
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  92688-3836
  
Phone: &=
nbsp;    (949) 636-8571
Email:       <=
a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:donald.coffin@reminetwo=
rks.com" target=3D"_blank"
 href=3D"mailto:donald.coffin@reminetworks.com">donald.coffin@reminetworks.com
  
Fro=
m: Bill Mills [mailto:wmills_9=
2105@yahoo.com] 
Sent: Sunday, February 09, 2014 7=
:30 PM
To: Donald Coffin; oauth@ietf.org
Cc: greenbutton-dev
Subject: Re: =
[OAUTH-WG] Should data exist for an Oauth access token request to be grante=
d?
  
Account
 creation could result in a token.  Data would be written as a result =
of the transaction.
 &n=
bsp;
On Sunday, Februar=
y 9, 2014 6:23 PM, Donald Coffin <donald.coffin@reminetworks.com>=
 wrote:
We are having a bit of a philosophical discuss=
ion regarding the requirement for data to exist as a requirement for an OAu=
th 2.0 access token to be granted and I=E2=80=99d like to get the opinions =
of the IETF Oauth
 WG.
 
The two points of view are:<=
/span>
 
=C2=B7      &nb=
sp;  There are no requirements in =E2=80=9CThe=
 OAuth 2.0 Framework=E2=80=9D [RFC6749] specification that requires data to=
 exist prior to an access token being granted and therefore the requirement=
 that data exist should NOT be a consideration
 for granting or denying an access token request, as long as all of the oth=
er requirements for granting of an access token are met.
=C2=B7         There are many potential applications that are a one-shot access re=
quest.  These would be confused if they receive an access token allowi=
ng them to access information that does NOT exist.  
 
A potential solution that might meet both requir=
ements is to add a SCOPE
 parameter the client MAY provide indicating an access token should only be=
 issued if data does exist.  The default would be that absent the SCOP=
E parameter the Authorization Server would issue an approved access token r=
egardless of the existence or absence of data at the time of the request.
 
I=E2=80=99d like to hear what the =
WG feels is a best practice solution to resolve our existing implementation=
 conflict.
 
Best regards,
Don
<=
div class=3D"yiv6671769835MsoNormal" style=3D"background:white;">Donald F. Coffin
Founder/CTO
 
REMI Networks<=
/span>
22751 El Prado Suite 6216
=

Rancho Santa Margarita, CA  92688-3836
=

 
Phone:   &=
nbsp;  (949) 636-8571
Email:  =
;     donald.coffin@reminetworks.com
=
 

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


  
 
  
 

--515012262-606390983-1392017991=:92745--

From paul.madsen@gmail.com  Mon Feb 10 03:39:25 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9671A0845 for ; Mon, 10 Feb 2014 03:39:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExUWn0MCv4M5 for ; Mon, 10 Feb 2014 03:39:21 -0800 (PST)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 356741A080B for ; Mon, 10 Feb 2014 03:39:21 -0800 (PST)
Received: by mail-ig0-f180.google.com with SMTP id m12so6331518iga.1 for ; Mon, 10 Feb 2014 03:39:21 -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=vN5Mu4++Mdvw67vLDCJv96m3kupufZcjMJbwH+Nwzxo=; b=oVAqJVqWCb6Vejtf+565CrwlQYHDAP42rI5zTNwdmNs+a823Hi0HmhLLvpg3K3xTnV AYOJP0MV+Vo4kG3SYRkaqSxpm9wTYHJGgk6SxhCvzhj9MtQqxHqdU312QaWRPBUrF913 KFbBDJcmKAblFglZWsQ6NpeAzCEvw0UOkQVkLxk7T0tDVIGIuX8m2yD8qUevYwnsvof9 od23Ee+uaUgddKnIhgUfuPCczlEmAiZtRexX3kj3iXx9Xt5V0+epFfJicIoUl+yGnYWA IZ/6Zi9j+HVwta81RUFRaBXJNiwjs8auyX6npNB46FmVx/XuWWAjuM5T3o8lrOLpr+HS zV1w==
X-Received: by 10.50.30.234 with SMTP id v10mr13445381igh.23.1392032361124; Mon, 10 Feb 2014 03:39:21 -0800 (PST)
Received: from [192.168.0.184] (CPE0022b0cb82b4-CMbc1401e98fa0.cpe.net.cable.rogers.com. [99.224.82.58]) by mx.google.com with ESMTPSA id ft2sm41496141igb.5.2014.02.10.03.39.19 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 03:39:20 -0800 (PST)
Message-ID: <52F8BA6A.8030101@gmail.com>
Date: Mon, 10 Feb 2014 06:39:22 -0500
From: Paul Madsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Donald Coffin ,  'Torsten Lodderstedt' , oauth@ietf.org
References:  <004a01cf2632$110982d0$331c8870$@reminetworks.com>
In-Reply-To: <004a01cf2632$110982d0$331c8870$@reminetworks.com>
Content-Type: multipart/alternative; boundary="------------090809080306040804060204"
Cc: 'greenbutton-dev' 
Subject: Re: [OAUTH-WG] Should data exist for an Oauth access token request to be granted?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Feb 2014 11:39:26 -0000

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

Hi Don, the way I see it, whether or not there is data available at the 
RS is  mostly orthogonal to any authorizations the client is issued for 
that data

But a caveat is the risk of Client's asking for 'omnibus scopes', ie any 
and everything on the possibility that the authorizations become 
relevant in the future. For instance, Google API clients shouldnt start 
asking for Nest data in anticipation of future availability.

paul

On 2/10/14, 2:31 AM, Donald Coffin wrote:
>
> Hi Torsten,
>
> I apologize if this is a duplicate response, but I just realized I 
> responded to my greenbutton-dev email address in my initial response 
> and wanted to be sure you got my reply.
>
> For the situation under discussion, there is no data at the (2) 
> resource server available for the client to access at the time the 
> resource owner grants them access.
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
> REMI Networks
>
> 22751 El Prado Suite 6216
>
> Rancho Santa Margarita, CA  92688-3836
>
> Phone: (949) 636-8571
>
> Email: donald.coffin@reminetworks.com 
> 
>
> *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> *Sent:* Sunday, February 09, 2014 10:29 PM
> *To:* Donald Coffin; oauth@ietf.org
> *Cc:* greenbutton-dev
> *Subject:* AW: [OAUTH-WG] Should data exist for an Oauth access token 
> request to be granted?
>
> Hi Donald,
>
> do you mean data regarding the particular user do not exist (1) at the 
> authorization server or (2) the resource server?
>
> Regards,
>
> Torsten.
>
>
>
> -------- Ursprüngliche Nachricht --------
> Von: Donald Coffin
> Datum:10.02.2014 03:22 (GMT+01:00)
> An: oauth@ietf.org 
> Cc: greenbutton-dev
> Betreff: [OAUTH-WG] Should data exist for an Oauth access token 
> request to be granted?
>
> We are having a bit of a philosophical discussion regarding the 
> requirement for data to exist as a requirement for an OAuth 2.0 access 
> token to be granted and I'd like to get the opinions of the IETF Oauth WG.
>
> The two points of view are:
>
> ·There are no requirements in "The OAuth 2.0 Framework" [RFC6749] 
> specification that requires data to exist prior to an access token 
> being granted and therefore the requirement that data exist should NOT 
> be a consideration for granting or denying an access token request, as 
> long as all of the other requirements for granting of an access token 
> are met.
>
>
> ·There are many potential applications that are a one-shot access 
> request.  These would be confused if they receive an access token 
> allowing them to access information that does NOT exist.
>
> A potential solution that might meet both requirements is to add a 
> SCOPE parameter the client MAY provide indicating an access token 
> should only be issued if data does exist. The default would be that 
> absent the SCOPE parameter the Authorization Server would issue an 
> approved access token regardless of the existence or absence of data 
> at the time of the request.
>
> I'd like to hear what the WG feels is a best practice solution to 
> resolve our existing implementation conflict.
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
> REMI Networks
>
> 22751 El Prado Suite 6216
>
> Rancho Santa Margarita, CA  92688-3836
>
> Phone: (949) 636-8571
>
> Email: donald.coffin@reminetworks.com 
> 
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------090809080306040804060204
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Don, the way I see it, whether or not there is
      data available at the RS is  mostly orthogonal to any
      authorizations the client is issued for that data

      

      But a caveat is the risk of Client's asking for 'omnibus scopes',
      ie any and everything on the possibility that the authorizations
      become relevant in the future. For instance, Google API clients 
      shouldnt start asking for Nest data in anticipation of future
      availability.

      

      paul 

      

    
    
On 2/10/14, 2:31 AM, Donald Coffin
      wrote:

    

    

      
      
      
      

        
Hi
            Torsten,

        
 

        
I
            apologize if this is a duplicate response, but I just
            realized I responded to my greenbutton-dev email address in
            my initial response and wanted to be sure you got my reply.

        
 

        
For
            the situation under discussion, there is no data at the (2)
            resource server available for the client to access at the
            time the resource owner grants them access.

        
 

        

          
Best
              regards,

          
Don

          
Donald
              F. Coffin

          
Founder/CTO

          
 

          
REMI
              Networks

          
22751
              El Prado Suite 6216

          
Rancho
              Santa Margarita, CA  92688-3836

          
 

          
Phone:     
              (949) 636-8571

          
Email:      
              donald.coffin@reminetworks.com

        

        
 

        

          

            
From:
                Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 

                Sent: Sunday, February 09, 2014 10:29 PM

                To: Donald Coffin; oauth@ietf.org

                Cc: greenbutton-dev

                Subject: AW: [OAUTH-WG] Should data exist for an
                Oauth access token request to be granted?

          

        

        
 

        
Hi Donald, 

        

          
 

        

        

          
do you mean data regarding the particular
            user do not exist (1) at the authorization server or (2) the
            resource server? 

        

        

          
 

        

        

          
Regards, 

        

        

          
Torsten.

        

        


          

          -------- Ursprüngliche Nachricht --------

          Von: Donald Coffin 

          Datum:10.02.2014 03:22 (GMT+01:00) 

          An: oauth@ietf.org
          

          Cc: greenbutton-dev 

          Betreff: [OAUTH-WG] Should data exist for an Oauth access
          token request to be granted? 

        

          
We
              are having a bit of a philosophical discussion regarding
              the requirement for data to exist as a requirement for an
              OAuth 2.0 access token to be granted and I’d like to get
              the opinions of the IETF Oauth WG.

          
 

          
The
              two points of view are:

          
 

          
·         There
              are no requirements in “The OAuth 2.0 Framework” [RFC6749]
              specification that requires data to exist prior to an
              access token being granted and therefore the requirement
              that data exist should NOT be a consideration for granting
              or denying an access token request, as long as all of the
              other requirements for granting of an access token are
              met.

              

              

            

          
·         There
              are many potential applications that are a one-shot access
              request.  These would be confused if they receive an
              access token allowing them to access information that does
              NOT exist.  

          
 

          
A
              potential solution that might meet both requirements is to
              add a SCOPE parameter the client MAY provide indicating an
              access token should only be issued if data does exist. 
              The default would be that absent the SCOPE parameter the
              Authorization Server would issue an approved access token
              regardless of the existence or absence of data at the time
              of the request.

          
 

          
I’d
              like to hear what the WG feels is a best practice solution
              to resolve our existing implementation conflict.

          
 

          
Best
            regards,

          
Don

          
Donald
            F. Coffin

          
Founder/CTO

          
 

          
REMI
            Networks

          
22751
            El Prado Suite 6216

          
Rancho
            Santa Margarita, CA  92688-3836

          
 

          
Phone:     
            (949) 636-8571

          
Email:      
            donald.coffin@reminetworks.com

          
 

        

      

      

      

      

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


    

    

  


--------------090809080306040804060204--

From jbradley@pingidentity.com  Mon Feb 10 03:48:21 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFD41A0823 for ; Mon, 10 Feb 2014 03:48:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.534
X-Spam-Level: 
X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_KuyFkagzRp for ; Mon, 10 Feb 2014 03:48:18 -0800 (PST)
Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with ESMTP id 06DF21A0821 for ; Mon, 10 Feb 2014 03:48:18 -0800 (PST)
Received: from mail-qa0-f49.google.com ([209.85.216.49]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKUvi8gk+iQf/EEutxDWbCjxN2JqhWaC3o@postini.com; Mon, 10 Feb 2014 03:48:18 PST
Received: by mail-qa0-f49.google.com with SMTP id w8so9210039qac.36 for ; Mon, 10 Feb 2014 03:48:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1UVGN5wKyirkMQB8FhKdcdsAR5OjrUnz+vH//8GKgCI=; b=WXcPdKjUcA8e6LvW3l7Mwt1SFNOlJxgjxvr9pZLKMW9OFwNU7gZCSyKoyv+IrF/1OB cF15XlSzSUjdujaDaQLZnn9bJRJQ6H5eR3aCWjMyhuCx19R/5rQ72LM3PxNIxa9mNtJH 0/YdAUPGeR94yH+q+hFfFbFrqF3cYs/Ofw/LA6HdM4w4/0W+iHYnNl7q2XAjXBHarsOW rjhKPP5CcwTpzS8SUQr5BodRY7Xt+ZE2zT8tt3U7w82FNi/R18nhviULorfrVn0o2FmS 0ZHmpewdzBVR1SwtBe/EiPay/8XhzNn7ru9+2UH2nzlPU/RoSXMTJZ2x4PCEg+06N5p9 cQEQ==
X-Gm-Message-State: ALoCoQluoWrpxS8YHfEpC2wEHFxonKkHaVyx5AJyg1O5zqrFQMGJn6dqyZOX9rXcsDWBOD+fu2+BRgOxbKIWaY9xzEJ0nepPSk/DcEI3SsYSfAgJWNgLybViThu7hWr53JxziHVaSsjE/rgjJq/HfUyrPbLjrLp3hg==
X-Received: by 10.224.67.6 with SMTP id p6mr31321503qai.6.1392032897550; Mon, 10 Feb 2014 03:48:17 -0800 (PST)
X-Received: by 10.224.67.6 with SMTP id p6mr31320621qai.6.1392032890345; Mon, 10 Feb 2014 03:48:10 -0800 (PST)
Received: from [192.168.1.216] (190-20-20-80.baf.movistar.cl. [190.20.20.80]) by mx.google.com with ESMTPSA id w2sm28837850qad.19.2014.02.10.03.48.06 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 03:48:09 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_83D59F00-20E3-413F-840E-8AF55B8BB749"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley 
In-Reply-To: <52F8BA6A.8030101@gmail.com>
Date: Mon, 10 Feb 2014 08:48:02 -0300
Message-Id: 
References:  <004a01cf2632$110982d0$331c8870$@reminetworks.com> <52F8BA6A.8030101@gmail.com>
To: Paul Madsen 
X-Mailer: Apple Mail (2.1827)
X-Mailman-Approved-At: Tue, 11 Feb 2014 06:30:08 -0800
Cc: Donald Coffin , "oauth@ietf.org list" , greenbutton-dev 
Subject: Re: [OAUTH-WG] Should data exist for an Oauth access token request to be granted?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Feb 2014 11:48:21 -0000

--Apple-Mail=_83D59F00-20E3-413F-840E-8AF55B8BB749
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_BB055050-BC16-4982-90B6-879D2F06AED7"


--Apple-Mail=_BB055050-BC16-4982-90B6-879D2F06AED7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

OAuth AS and RS are intended to be loosely coupled.  A AS may not have =
any way to know if data for any or all of an API is populated.

At the API layer the client needs to be able to deal with the API =
appropriately including empty responses if that is possible.

Not returning a access token my be taken by the client that it is not =
the resource owner or that they resource owner did not not approve the =
grant.

I can see it being tempting to not send back a token if it is a single =
use token and there is no data, but I don't think the optimization is =
worth it.
Deal with missing data at the API layer, and Authorization at the OAuth =
layer.

John B.

On Feb 10, 2014, at 8:39 AM, Paul Madsen  wrote:

> Hi Don, the way I see it, whether or not there is data available at =
the RS is  mostly orthogonal to any authorizations the client is issued =
for that data
>=20
> But a caveat is the risk of Client's asking for 'omnibus scopes', ie =
any and everything on the possibility that the authorizations become =
relevant in the future. For instance, Google API clients  shouldnt start =
asking for Nest data in anticipation of future availability.
>=20
> paul=20
>=20
> On 2/10/14, 2:31 AM, Donald Coffin wrote:
>> Hi Torsten,
>> =20
>> I apologize if this is a duplicate response, but I just realized I =
responded to my greenbutton-dev email address in my initial response and =
wanted to be sure you got my reply.
>> =20
>> For the situation under discussion, there is no data at the (2) =
resource server available for the client to access at the time the =
resource owner grants them access.
>> =20
>> Best regards,
>> Don
>> Donald F. Coffin
>> Founder/CTO
>> =20
>> REMI Networks
>> 22751 El Prado Suite 6216
>> Rancho Santa Margarita, CA  92688-3836
>> =20
>> Phone:      (949) 636-8571
>> Email:       donald.coffin@reminetworks.com
>> =20
>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20
>> Sent: Sunday, February 09, 2014 10:29 PM
>> To: Donald Coffin; oauth@ietf.org
>> Cc: greenbutton-dev
>> Subject: AW: [OAUTH-WG] Should data exist for an Oauth access token =
request to be granted?
>> =20
>> Hi Donald,=20
>> =20
>> do you mean data regarding the particular user do not exist (1) at =
the authorization server or (2) the resource server?=20
>> =20
>> Regards,=20
>> Torsten.
>>=20
>>=20
>> -------- Urspr=FCngliche Nachricht --------
>> Von: Donald Coffin=20
>> Datum:10.02.2014 03:22 (GMT+01:00)=20
>> An: oauth@ietf.org=20
>> Cc: greenbutton-dev=20
>> Betreff: [OAUTH-WG] Should data exist for an Oauth access token =
request to be granted?
>>=20
>> We are having a bit of a philosophical discussion regarding the =
requirement for data to exist as a requirement for an OAuth 2.0 access =
token to be granted and I=92d like to get the opinions of the IETF Oauth =
WG.
>> =20
>> The two points of view are:
>> =20
>> =B7         There are no requirements in =93The OAuth 2.0 Framework=94 =
[RFC6749] specification that requires data to exist prior to an access =
token being granted and therefore the requirement that data exist should =
NOT be a consideration for granting or denying an access token request, =
as long as all of the other requirements for granting of an access token =
are met.
>>=20
>>=20
>>=20
>> =B7         There are many potential applications that are a one-shot =
access request.  These would be confused if they receive an access token =
allowing them to access information that does NOT exist.=20
>>=20
>> =20
>> A potential solution that might meet both requirements is to add a =
SCOPE parameter the client MAY provide indicating an access token should =
only be issued if data does exist.  The default would be that absent the =
SCOPE parameter the Authorization Server would issue an approved access =
token regardless of the existence or absence of data at the time of the =
request.
>> =20
>> I=92d like to hear what the WG feels is a best practice solution to =
resolve our existing implementation conflict.
>> =20
>> Best regards,
>> Don
>> Donald F. Coffin
>> Founder/CTO
>> =20
>> REMI Networks
>> 22751 El Prado Suite 6216
>> Rancho Santa Margarita, CA  92688-3836
>> =20
>> Phone:      (949) 636-8571
>> Email:       donald.coffin@reminetworks.com
>> =20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_BB055050-BC16-4982-90B6-879D2F06AED7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

OAuth =
AS and RS are intended to be loosely coupled.  A AS may not have =
any way to know if data for any or all of an API is =
populated.

At the API layer the client needs to be =
able to deal with the API appropriately including empty responses if =
that is possible.

Not returning a access token =
my be taken by the client that it is not the resource owner or that they =
resource owner did not not approve the grant.

I =
can see it being tempting to not send back a token if it is a single use =
token and there is no data, but I don't think the optimization is worth =
it.
Deal with missing data at the API layer, and Authorization =
at the OAuth layer.

John =
B.

On Feb 10, 2014, at 8:39 AM, Paul Madsen =
<paul.madsen@gmail.com>=
 wrote:

Hi Don, the =
way I see it, whether or not there is data available at the RS is  =
mostly orthogonal to any authorizations the client is issued for that =
data

But a caveat is the risk of Client's asking for 'omnibus =
scopes', ie any and everything on the possibility that the =
authorizations become relevant in the future. For instance, Google API =
clients  shouldnt start asking for Nest data in anticipation of =
future availability.

paul 

On 2/10/14, 2:31 AM, Donald Coffin =
wrote:
Hi Torsten,
 
I apologize if this is a =
duplicate response, but I just realized I responded to my =
greenbutton-dev email address in my initial response and wanted to be =
sure you got my reply.
 
For the situation under =
discussion, there is no data at the (2) resource server available for =
the client to access at the time the resource owner grants them =
access.
 
Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA  92688-3836
 
Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks.com
 
From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 
Sent: Sunday, February 09, 2014 =
10:29 PM
To: Donald Coffin; oauth@ietf.org
Cc: greenbutton-dev
Subject=
: AW: [OAUTH-WG] =
Should data exist for an Oauth access token request to be =
granted?
 
Hi =
Donald, 
 
do =
you mean data regarding the particular user do not exist (1) at the =
authorization server or (2) the resource =
server? 
 
Regards, 
Torsten.


-------- Urspr=FCngliche Nachricht =
--------
Von: Donald Coffin 
Datum:10.02.2014 03:22 =
(GMT+01:00) 
An: oauth@ietf.org 
Cc: =
greenbutton-dev 
Betreff: [OAUTH-WG] =
Should data exist for an Oauth access token request to be =
granted?
We are having a bit of a =
philosophical discussion regarding the requirement for data to exist as =
a requirement for an OAuth 2.0 access token to be granted and I=92d like =
to get the opinions of the IETF Oauth WG.
 
The two points of view =
are:
 
=B7         There are no requirements in =93The=
 OAuth 2.0 Framework=94 [RFC6749] specification that requires data to =
exist prior to an access token being granted and therefore the =
requirement that data exist should NOT be a consideration for granting =
or denying an access token request, as long as all of the other =
requirements for granting of an access token are =
met.


=B7         There are many potential =
applications that are a one-shot access request.  These would be =
confused if they receive an access token allowing them to access =
information that does NOT exist. 
 
A potential solution that might =
meet both requirements is to add a SCOPE parameter the client MAY =
provide indicating an access token should only be issued if data does =
exist.  The default would be that absent the SCOPE parameter the =
Authorization Server would issue an approved access token regardless of =
the existence or absence of data at the time of the =
request.
 
I=92d like to hear what the WG =
feels is a best practice solution to resolve our existing implementation =
conflict.
 
Best =
regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI =
Networks
22751 El Prado =
Suite 6216
Rancho Santa =
Margarita, CA  92688-3836
 
Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks.com
 


_______________________________________________
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=_BB055050-BC16-4982-90B6-879D2F06AED7--

--Apple-Mail=_83D59F00-20E3-413F-840E-8AF55B8BB749
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjEwMTE0ODAzWjAjBgkqhkiG9w0BCQQxFgQUEwpNuqF1
hl8j5o59nJYXdOzr98YwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAVtJ3kkK8hh0XmLq+lnE+UrhUa/gPkFeSrkEXrHVw
hEmYLfCMGtVlvsNU3gTpsYm+q7InOuP/eyy1Q+oEynUnQtU7W7vQNZUX+PuUAj9p//+8S+kybUOn
L2ijajeNrbarvXgcpA8nj9XQpNL1I6GxTI1RNiqEwkKzX3si8AFtEDYJDYBVuooCLfZI7DGDd7xc
Ik+9KOb5l2tpJV2WulNDwRu51M7+GKJdcGLxNQusT/On0U0xWkxDElaAIJwlHSdOF8zAVPRJRyMT
7EvjejXVgwk8JmRLNdavv3bHZNEKaPLhtQGWLgbbz28sJb8mm7qvvD+6WNv3KcqTsbseGRoUjQAA
AAAAAA==

--Apple-Mail=_83D59F00-20E3-413F-840E-8AF55B8BB749--

From donald.coffin@reminetworks.com  Tue Feb 11 11:50:21 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6B01A0702 for ; Tue, 11 Feb 2014 11:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02-2QltE-WpI for ; Tue, 11 Feb 2014 11:50:17 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 727861A071B for ; Tue, 11 Feb 2014 11:50:16 -0800 (PST)
Received: (qmail 29838 invoked by uid 0); 11 Feb 2014 19:50:09 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 11 Feb 2014 19:50:09 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw3 with  id REq31n00D2is6CS01Eq6lF; Tue, 11 Feb 2014 19:50:08 -0700
X-Authority-Analysis: v=2.1 cv=RodWckWK c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=WEZigaUjQ-wA:10 a=8dE94GJacnkA:10 a=UGkfVyPCAAAA:8 a=ff6EgXNWp8gA:10 a=rE68L1KyjUoA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=LS6YZpeZAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=_Y5QVBCcAAAA:8 a=C_lkRgqxPHSn20UaVKUA:9 a=ZX1UnnXvlVYVgxsC:21 a=skK9QXjtExaKFqlU:21 a=wPNLvfGTeEIA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=0qEjrYlnuRwA:10 a=JZhl9uXQ5EIA:10 a=lZB815dzVvQA:10 a=MSl-tDqOz04A:10 a=B6qkqdRczAkA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=tkXfz4JpnxkuqOlgVocA:9 a=pH_48YCtWWbLUa7m:21 a=Y1WjnEIykV8eTq6N:21 a=t5s3hPeAhuB0z23K:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=I7JDTLvZSLoA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=PIpFsvRP5Vtrqs4/vunGeFttFiqTMyZITAK0B1U68Q4=;  b=KO2ce35Twe8v/oH9gxsNw3ujXiYFEpSgEYqsAmtlu2cM79LG44/Y+Ypc3FKyVu3Q5igIK7eHIW1tSdxAjrrTglK+15CQBfMZpAwBHQJbB4W/b4Qio0x8LLr7Ap7lSi4P;
Received: from [68.5.51.152] (port=50036 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1WDJLI-0007Az-Gp; Tue, 11 Feb 2014 12:50:04 -0700
From: "Donald Coffin" 
To: "'John Bradley'" , "'Paul Madsen'" 
References:  <004a01cf2632$110982d0$331c8870$@reminetworks.com> <52F8BA6A.8030101@gmail.com> 
In-Reply-To: 
Date: Tue, 11 Feb 2014 11:49:16 -0800
Organization: REMI Networks
Message-ID: <00c901cf2762$5ab344d0$1019ce70$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01CF271F.4C93AE50"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFPReOHJHalUPq8CVr/LBI/fBZi4gHoABYBAoa/1fICZuGMNJt5iy2w
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.5.51.152 authed with donald.coffin@reminetworks.com}
Cc: oauth@ietf.org, 'greenbutton-dev' 
Subject: Re: [OAUTH-WG] Should data exist for an Oauth access token request	to be granted?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Feb 2014 19:50:21 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00CA_01CF271F.4C93AE50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks to everyone for their input.  Based on the feedback from the =
OAuth WG
we have decided that an access token will be issued regardless of =
whether
data exist at the time of the access token request. =20

=20

We already have logic developed to deal with client resource request =
when
there is no data present.  Therefore we will deal with the question of =
data
present only at the API level.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:        
donald.coffin@reminetworks.com

=20

From: John Bradley [mailto:jbradley@pingidentity.com]=20
Sent: Monday, February 10, 2014 3:48 AM
To: Paul Madsen
Cc: Donald Coffin; oauth@ietf.org list; greenbutton-dev
Subject: Re: [OAUTH-WG] Should data exist for an Oauth access token =
request
to be granted?

=20

OAuth AS and RS are intended to be loosely coupled.  A AS may not have =
any
way to know if data for any or all of an API is populated.

=20

At the API layer the client needs to be able to deal with the API
appropriately including empty responses if that is possible.

=20

Not returning a access token my be taken by the client that it is not =
the
resource owner or that they resource owner did not not approve the =
grant.

=20

I can see it being tempting to not send back a token if it is a single =
use
token and there is no data, but I don't think the optimization is worth =
it.

Deal with missing data at the API layer, and Authorization at the OAuth
layer.

=20

John B.

=20

On Feb 10, 2014, at 8:39 AM, Paul Madsen  wrote:





Hi Don, the way I see it, whether or not there is data available at the =
RS
is  mostly orthogonal to any authorizations the client is issued for =
that
data

But a caveat is the risk of Client's asking for 'omnibus scopes', ie any =
and
everything on the possibility that the authorizations become relevant in =
the
future. For instance, Google API clients  shouldnt start asking for Nest
data in anticipation of future availability.

paul=20

On 2/10/14, 2:31 AM, Donald Coffin wrote:

Hi Torsten,

=20

I apologize if this is a duplicate response, but I just realized I =
responded
to my greenbutton-dev email address in my initial response and wanted to =
be
sure you got my reply.

=20

For the situation under discussion, there is no data at the (2) resource
server available for the client to access at the time the resource owner
grants them access.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20

From: Torsten Lodderstedt [ 
mailto:torsten@lodderstedt.net]=20
Sent: Sunday, February 09, 2014 10:29 PM
To: Donald Coffin;   oauth@ietf.org
Cc: greenbutton-dev
Subject: AW: [OAUTH-WG] Should data exist for an Oauth access token =
request
to be granted?

=20

Hi Donald,=20

=20

do you mean data regarding the particular user do not exist (1) at the
authorization server or (2) the resource server?=20

=20

Regards,=20

Torsten.



-------- Urspr=FCngliche Nachricht --------
Von: Donald Coffin=20
Datum:10.02.2014 03:22 (GMT+01:00)=20
An:   oauth@ietf.org=20
Cc: greenbutton-dev=20
Betreff: [OAUTH-WG] Should data exist for an Oauth access token request =
to
be granted?

We are having a bit of a philosophical discussion regarding the =
requirement
for data to exist as a requirement for an OAuth 2.0 access token to be
granted and I=92d like to get the opinions of the IETF Oauth WG.

=20

The two points of view are:

=20

=B7         There are no requirements in =93The OAuth 2.0 Framework=94 =
[RFC6749]
specification that requires data to exist prior to an access token being
granted and therefore the requirement that data exist should NOT be a
consideration for granting or denying an access token request, as long =
as
all of the other requirements for granting of an access token are met.





=B7         There are many potential applications that are a one-shot =
access
request.  These would be confused if they receive an access token =
allowing
them to access information that does NOT exist.=20

=20

A potential solution that might meet both requirements is to add a SCOPE
parameter the client MAY provide indicating an access token should only =
be
issued if data does exist.  The default would be that absent the SCOPE
parameter the Authorization Server would issue an approved access token
regardless of the existence or absence of data at the time of the =
request.

=20

I=92d like to hear what the WG feels is a best practice solution to =
resolve
our existing implementation conflict.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:        
donald.coffin@reminetworks.com

=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


------=_NextPart_000_00CA_01CF271F.4C93AE50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Thanks to everyone for their =
input.=A0 Based on the feedback from the OAuth WG we have decided that =
an access token will be issued regardless of whether data exist at the =
time of the access token request.=A0 
 
We =
already have logic developed to deal with client resource request when =
there is no data present.=A0 Therefore we will deal with the question of =
data present only at the API level.
 
=

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
=

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA=A0 92688-3836
 
=

Phone:=A0=A0=A0=A0=A0 (949) =
636-8571
Email:=A0=A0=A0=A0=A0=A0 donald.coffin@reminetworks.com=

 
=

From:=
 =
John Bradley [mailto:jbradley@pingidentity.com] 
Sent: Monday, =
February 10, 2014 3:48 AM
To: Paul Madsen
Cc: Donald =
Coffin; oauth@ietf.org list; greenbutton-dev
Subject: Re: =
[OAUTH-WG] Should data exist for an Oauth access token request to be =
granted?
 
OAuth AS and =
RS are intended to be loosely coupled.  A AS may not have any way =
to know if data for any or all of an API is =
populated.
 
At the API layer the client needs to be able to deal =
with the API appropriately including empty responses if that is =
possible.
 
Not returning a access token my be taken by the client =
that it is not the resource owner or that they resource owner did not =
not approve the grant.
 
I =
can see it being tempting to not send back a token if it is a single use =
token and there is no data, but I don't think the optimization is worth =
it.
Deal with missing data =
at the API layer, and Authorization at the OAuth =
layer.
 
John B.
 
On =
Feb 10, 2014, at 8:39 AM, Paul Madsen <paul.madsen@gmail.com> =
wrote:


Hi Don, the =
way I see it, whether or not there is data available at the RS is  =
mostly orthogonal to any authorizations the client is issued for that =
data

But a caveat is the risk of Client's asking for 'omnibus =
scopes', ie any and everything on the possibility that the =
authorizations become relevant in the future. For instance, Google API =
clients  shouldnt start asking for Nest data in anticipation of =
future availability.

paul 
On =
2/10/14, 2:31 AM, Donald Coffin =
wrote:
Hi =
Torsten,
 
I apologize if this is a =
duplicate response, but I just realized I responded to my =
greenbutton-dev email address in my initial response and wanted to be =
sure you got my reply.
 
For the situation under =
discussion, there is no data at the (2) resource server available for =
the client to access at the time the resource owner grants them =
access.
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
=

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA  92688-3836
 
=

Phone:   &nbs=
p;  (949) 636-8571
Email:   &nbs=
p;   donald.coffin@reminetworks=
.com
 
From:=
 Torsten =
Lodderstedt [mailto:torsten@lodderstedt.net] 
Sent: Sunday, February 09, 2014 =
10:29 PM
To: Donald Coffin; oauth@ietf.org
Cc: greenbutton-dev
Subject:=
 AW: [OAUTH-WG] =
Should data exist for an Oauth access token request to be =
granted?
 
Hi Donald, 
 
do you mean data regarding the particular user do not =
exist (1) at the authorization server or (2) the resource =
server? 
 
Regards, 
Torsten.


-------- =
Urspr=FCngliche Nachricht --------
Von: Donald Coffin 
Datum:10.02.2014 03:22 =
(GMT+01:00) 
An: oauth@ietf.org 
Cc: greenbutton-dev 
Betreff: [OAUTH-WG] =
Should data exist for an Oauth access token request to be =
granted?
We are having a bit of a =
philosophical discussion regarding the requirement for data to exist as =
a requirement for an OAuth 2.0 access token to be granted and I’d =
like to get the opinions of the IETF Oauth =
WG.
 
The two points of view =
are:
 
=B7        =
; There are no requirements in =
“The OAuth 2.0 Framework” [RFC6749] specification that =
requires data to exist prior to an access token being granted and =
therefore the requirement that data exist should NOT be a consideration =
for granting or denying an access token request, as long as all of the =
other requirements for granting of an access token are =
met.



=B7        =
; There are many potential =
applications that are a one-shot access request.  These would be =
confused if they receive an access token allowing them to access =
information that does NOT exist. 
 
A potential solution that might =
meet both requirements is to add a SCOPE parameter the client MAY =
provide indicating an access token should only be issued if data does =
exist.  The default would be that absent the SCOPE parameter the =
Authorization Server would issue an approved access token regardless of =
the existence or absence of data at the time of the =
request.
 
I’d like to hear what the =
WG feels is a best practice solution to resolve our existing =
implementation conflict.
 
Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  =
92688-3836
 
Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks.com
 


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


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

 

------=_NextPart_000_00CA_01CF271F.4C93AE50--


From jaredhanson@gmail.com  Wed Feb 12 10:26:37 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D261E1A0602 for ; Wed, 12 Feb 2014 10:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LVwuKJkH5GS for ; Wed, 12 Feb 2014 10:26:34 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAEA1A0635 for ; Wed, 12 Feb 2014 10:26:34 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u56so6409380wes.16 for ; Wed, 12 Feb 2014 10:26:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VyTVBlj9VR1dCMtCe6dQcJ8tPl22zxQA5Hr/MQsmHFI=; b=Vi7YV5uWAk40WOO76nfoMLnddu5JXUVICvHFOPSEhvunCWlC2lj95CgjUiqGEyraMb VBjgfTmXw1Mgy/SULSJslnVMDFPsLnXRp5MzhIhqtvOeXDwyygAxhITM7cKxqyX7YmPR Gy0vuspbmI1hrDjWrJwl9D4GEfSI6Aq0eToNKuHtSFy/wtuq3i9Efqbjb6GfLAMzcZFW VprZsmbbXi42qXu3wIS+I+QnZ0W8fve02DEabG0iNfA4ITNN/1HZB5dxVYCaoUTi6Ri1 HsmtkWoX05YVH92UBGmjX2J1cz1OZZnY0iUajb0aFx3m5E2EGB+cEceLEVzcGXZ8yw24 CKDQ==
MIME-Version: 1.0
X-Received: by 10.194.134.132 with SMTP id pk4mr2143927wjb.82.1392229592825; Wed, 12 Feb 2014 10:26:32 -0800 (PST)
Received: by 10.180.7.106 with HTTP; Wed, 12 Feb 2014 10:26:32 -0800 (PST)
Date: Wed, 12 Feb 2014 10:26:32 -0800
Message-ID: 
From: Jared Hanson 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=089e01227f4453b4c404f239b66d
Subject: [OAUTH-WG] Correct use of jku claims in JWT/JWS bearer assertions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Feb 2014 18:26:38 -0000

--089e01227f4453b4c404f239b66d
Content-Type: text/plain; charset=ISO-8859-1

I'm wondering if there is any guidance on including "jku", "jwk", "x5u",
and "x5c"
claims in a JWT/JWS used as a bearer assertion for authentication.

Specifically, in the case of service-to-service authentication, where the
"iss" is
set to the service acting as a client, say "https://client.example.net/"
making a
request to "https://api.example.com/", and the assertion is signed using
client.example.net's private key.

In this situation, api.example.com authenticates the assertion by finding
the
corresponding public key (possibly in a JWK set, the location of which can
be
obtained by something like OpenID Provider Configuration [1]).

It is clear that any claims in the assertion are self-asserted until
validated,
including both the "iss" and any keys or URLs to keys.  Thus, when a service
validates the assertion, it *must not* use the values of "jku", etc to
validate
the signature.  Instead it should use some trusted channel to obtain the
keys
directly from the issuer.

If this were not done, a malicious entity could freely generate assertions
claiming to be client.example.net, using any private key and including a
malicious
reference to its own public key using a "jku" set to "
https://malicious.com/jwks.json"

This security consideration is not called out anywhere that I've noticed,
which
I've seen leading to insecure implementations and/or bad examples.  For
example,
this example on Gluu's wiki: http://ox.gluu.org/doku.php?id=oxauth:jwt is
blindly
using the value of "jku" to fetch the key used to validate the signature,
without
any way to validate that the URL itself belongs to the issuer.

I'm raising this point hoping that guidance can be clarified and included
in the
specification.

Thanks,
Jared Hanson

PS. I separately sent this same message to the JOSE list, and later figured
it was equally relevant to OAuth, if not more so.

[1] http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig

-- 
Jared Hanson 

--089e01227f4453b4c404f239b66d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I'm wondering if there is any guidance on includi=
ng "jku", "jwk", "x5u", and "x5c"
claims in a JWT/JWS used as a bearer assertion for authentication.=




Specifically, in the case of service-to-service authent=
ication, where the "iss" is
set to the service acting a=
s a client, say "https://clien=
t.example.net/" making a


request to "https://api.exam=
ple.com/", and the assertion is signed using
client.example.net's private key.
<=
div>

In this situation, api.ex=
ample.com authenticates the assertion by finding the
correspo=
nding public key (possibly in a JWK set, the location of which can be


obtained by something like OpenID Provider Configuration [1]).

It is clear that any claims in the assertion are self-ass=
erted until validated,
including both the "iss" and any=
 keys or URLs to keys. =A0Thus, when a service


validates the assertion, it *must not* use the values of "jku&quo=
t;, etc to validate
the signature. =A0Instead it should use some =
trusted channel to obtain the keys
directly from the issuer.


If this were not done, a malicious entity could freely =
generate assertions
claiming to be client.example.net, using any private key and including a malic=
ious


reference to its own public key using a "jku" set to "<=
a href=3D"https://malicious.com/jwks.json">https://malicious.com/jwks.json<=
/a>"

This security consideration is not calle=
d out anywhere that I've noticed, which


I've seen leading to insecure implementations and/or bad examples.=
 =A0For example,
this example on Gluu's wiki: http://ox.gluu.org/doku.php?id=3Do=
xauth:jwt is blindly


using the value of "jku" to fetch the key used to validate t=
he signature, without
any way to validate that the URL itself bel=
ongs to the issuer.

I'm raising this point hop=
ing that guidance can be clarified and included in the


specification.

Thanks,
Jared Hanson=


PS. I separately sent this same message to the JO=
SE list, and later figured it was equally relevant to OAuth, if not more so=
.




-- 
Jared Hanson=
 <http://jaredhanson.net/>



--089e01227f4453b4c404f239b66d--


From nobody Fri Feb 14 15:20:13 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799C21A03ED; Fri, 14 Feb 2014 15:20:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSFhK_iUozHN; Fri, 14 Feb 2014 15:20:07 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7F01A02E2; Fri, 14 Feb 2014 15:20:06 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140214232006.30690.74841.idtracker@ietfa.amsl.com>
Date: Fri, 14 Feb 2014 15:20:06 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/vw7NmXoAZEIGJooPYUQbllKHs2M
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-16.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Feb 2014 23:20:09 -0000

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

        Title           : JSON Web Token (JWT)
        Authors         : Michael B. Jones
                          John Bradley
                          Nat Sakimura
	Filename        : draft-ietf-oauth-json-web-token-16.txt
	Pages           : 29
	Date            : 2014-02-14

Abstract:
   JSON Web Token (JWT) is a compact URL-safe means of representing
   claims to be transferred between two parties.  The claims in a JWT
   are encoded as a JavaScript Object Notation (JSON) object that is
   used as the payload of a JSON Web Signature (JWS) structure or as the
   plaintext of a JSON Web Encryption (JWE) structure, enabling the
   claims to be digitally signed or MACed and/or encrypted.

   The suggested pronunciation of JWT is the same as the English word
   "jot".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-16

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-16


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

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


From nobody Fri Feb 14 17:09:26 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCDD1A0164 for ; Fri, 14 Feb 2014 17:09:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH3z5lZISUQm for ; Fri, 14 Feb 2014 17:09:21 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 33D231A0129 for ; Fri, 14 Feb 2014 17:09:21 -0800 (PST)
Received: from BL2PR03CA021.namprd03.prod.outlook.com (10.141.66.29) by BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) with Microsoft SMTP Server (TLS) id 15.0.878.16; Sat, 15 Feb 2014 01:09:18 +0000
Received: from BL2FFO11FD030.protection.gbl (2a01:111:f400:7c09::113) by BL2PR03CA021.outlook.office365.com (2a01:111:e400:c1b::29) with Microsoft SMTP Server (TLS) id 15.0.873.15 via Frontend Transport; Sat, 15 Feb 2014 01:09:19 +0000
Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD030.mail.protection.outlook.com (10.173.161.40) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 15 Feb 2014 01:09:18 +0000
Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0174.002; Sat, 15 Feb 2014 01:08:45 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: JOSE -21 drafts incorporating WGLC feedback
Thread-Index: Ac8p6g5i+6VQzEWbTwWC1YAmMT3J7gAAB3Yw
Date: Sat, 15 Feb 2014 01:08:44 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739438B19755D@TK5EX14MBXC288.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.76]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B19755DTK5EX14MBXC288r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(199002)(189002)(377454003)(76786001)(66066001)(63696002)(77982001)(19300405004)(44976005)(85306002)(19580395003)(51856001)(6806004)(16297215004)(65816001)(76796001)(19580405001)(83322001)(31966008)(74662001)(49866001)(59766001)(20776003)(77096001)(84326002)(86362001)(92726001)(81542001)(74876001)(94946001)(4396001)(53806001)(92566001)(50986001)(94316002)(47976001)(80976001)(47736001)(93136001)(15202345003)(79102001)(16236675002)(47446002)(56776001)(71186001)(95666001)(90146001)(86612001)(83072002)(56816005)(69226001)(2656002)(15975445006)(74706001)(87266001)(85852003)(46102001)(54356001)(54316002)(74502001)(55846006)(80022001)(93516002)(33656001)(74366001)(76176001)(81342001)(81686001)(76482001)(512954002)(81816001)(95416001)(87936001)(6606295002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB592; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:A643DAB0.A0F2FBD1.41F19549.80ECF540.202B1; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 012349AD1C
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WkyEfPWAgZkdpvm-wXcLtQo0OcU
Subject: [OAUTH-WG] FW: JOSE -21 drafts incorporating WGLC feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Feb 2014 01:09:24 -0000

--_000_4E1F6AAD24975D4BA5B16804296739438B19755DTK5EX14MBXC288r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The only JWT change was to change some normative references to being non-no=
rmative, paralleling companion changes made in the JOSE specifications.

                                                                -- Mike

From: Mike Jones
Sent: Friday, February 14, 2014 5:06 PM
To: jose@ietf.org
Subject: JOSE -21 drafts incorporating WGLC feedback

JSON Object Signing and Encryption (JOSE) drafts have been published that a=
ddress the feedback received during Working Group Last Call (WGLC) on the s=
pecifications, which ran from January 22 to February 13, 2014.  Two breakin=
g (but very local) changes were made as a result of working group discussio=
ns:


*         Replaced the JWK key_ops values wrap and unwrap with wrapKey and =
unwrapKey to match the KeyUsage values defined in the current Web Cryptogra=
phy API editor's draft.

*         Compute the PBES2 salt parameter as (UTF8(Alg) || 0x00 || Salt In=
put), where the p2s Header Parameter encodes the Salt Input value and Alg i=
s the alg Header Parameter value.

A few editorial changes were also made to improve readability.  See the Doc=
ument History sections for the issues addressed by these changes.  One para=
llel editorial change was also made to the JSON Web Token (JWT) specificati=
on.

The specifications are available at:

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-21

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-21

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-key-21

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-21

*         http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-16

HTML formatted versions are also available at:

*         http://self-issued.info/docs/draft-ietf-jose-json-web-signature-2=
1.html

*         http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-=
21.html

*         http://self-issued.info/docs/draft-ietf-jose-json-web-key-21.html

*         http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-=
21.html

*         http://self-issued.info/docs/draft-ietf-oauth-json-web-token-16.h=
tml

Thanks to those of you who provided feedback on the specs during Working Gr=
oup Last Call.

                                                                -- Mike

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

--_000_4E1F6AAD24975D4BA5B16804296739438B19755DTK5EX14MBXC288r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











The only JWT change wa=
s to change some normative references to being non-normative, paralleling c=
ompanion changes made in the JOSE specifications.


 


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



 






From: Mike Jon=
es


Sent: Friday, February 14, 2014 5:06 PM

To: jose@ietf.org

Subject: JOSE -21 drafts incorporating WGLC feedback






 


JSON Object Signing and Encryption (JOSE) drafts hav=
e been published that address the feedback received during Working Group La=
st Call (WGLC) on the specifications, which ran from January 22 to February=
 13, 2014.  Two breaking (but very
 local) changes were made as a result of working group discussions:


 


·        
Replace=
d the JWK
key_ops=
 values
wrap and
unwrap<=
span lang=3D"EN" style=3D"font-size:10.0pt;font-family:"Verdana",=
"sans-serif";color:black"> with
wrapKey=
 and
unwrapKey to match the
KeyUsage values defined in the current
Web Cryptography API editor's draft.


·        
Compute=
 the PBES2 salt parameter as (UTF8(Alg) || 0x00 || Salt Input), where the
p2s Header Parameter encodes the Salt Input v=
alue and Alg is the
alg Header Parameter value.


 


A few editorial changes were also made to improve re=
adability.  See the Document History sections for the issues addressed=
 by these changes.  One parallel editorial change was also made to the=
 JSON Web Token (JWT) specification.


 


The specifications are available at:


·        
http://tools.ietf.org/html/draft-ietf-jose=
-json-web-signature-21


·        
http://tools.ietf.org/html/draft-ietf-jos=
e-json-web-encryption-21


·        
http://tools.ietf.org/html/draft-ietf-jose-json-=
web-key-21


·        
http://tools.ietf.org/html/draft-ietf-jos=
e-json-web-algorithms-21


·        
http://tools.ietf.org/html/draft-ietf-oauth-j=
son-web-token-16


 


HTML formatted versions are also available at:<=
/o:p>


·        
http://self-issued.info/docs/draft-=
ietf-jose-json-web-signature-21.html


·        
http://self-issued.info/docs/draft=
-ietf-jose-json-web-encryption-21.html


·        
http://self-issued.info/docs/draft-ietf-j=
ose-json-web-key-21.html


·        
http://self-issued.info/docs/draft=
-ietf-jose-json-web-algorithms-21.html


·        
http://self-issued.info/docs/draft-iet=
f-oauth-json-web-token-16.html


 


Thanks to those of you who provided feedback on the =
specs during Working Group Last Call.


 


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


 


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






--_000_4E1F6AAD24975D4BA5B16804296739438B19755DTK5EX14MBXC288r_--


From nobody Sat Feb 15 19:00:55 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACB41A0334 for ; Sat, 15 Feb 2014 19:00:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOPRv1O_t3hi for ; Sat, 15 Feb 2014 19:00:50 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 12D601A0333 for ; Sat, 15 Feb 2014 19:00:50 -0800 (PST)
Received: (qmail 2291 invoked by uid 0); 16 Feb 2014 03:00:45 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 16 Feb 2014 03:00:45 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw2 with  id Sr0d1n0052is6CS01r0gcA; Sat, 15 Feb 2014 20:00:44 -0700
X-Authority-Analysis: v=2.1 cv=ar4hV0pV c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=dq0SZ62CdugA:10 a=8dE94GJacnkA:10 a=UGkfVyPCAAAA:8 a=vapAUs4nhnIA:10 a=rE68L1KyjUoA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=bWl4DpNhBsVAJclonDIA:9 a=3k4I53lu14ZK_pcp:21 a=2A3wSueGU6QEdADM:21 a=CjuIK1q_8ugA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=0qEjrYlnuRwA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=sZPqtPKswmdgoLt4O1AA:9 a=ZZg2_XOimAgrIQHq:21 a=V6yUaaWhD1N3yDWB:21 a=5VQqbNJaKBctPyk3:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=G0KSfkkDGdFOLRUDRPFWpBSoxunoV/7x5NgA+qaPxRk=;  b=GVqz4eSwhfmNPHUkDx4aDPklTf3TPOsKk3k7IEF+Uz5kW8yiulwqs118wFakdagaT64E281u5jHGcdJ2YM/UL/JfQMQB+SfAvdzpVOfIgQTe92GhibyorvRCTZaglko9;
Received: from [68.5.51.152] (port=49527 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1WEryA-00028o-4N; Sat, 15 Feb 2014 20:00:38 -0700
From: "Donald Coffin" 
To: 
Date: Sat, 15 Feb 2014 18:58:13 -0800
Organization: REMI Networks
Message-ID: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CF2A7F.E1E38030"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac8qwu4BeTwmY6ITTSW2cms7JVDlkQ==
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.5.51.152 authed with donald.coffin@reminetworks.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-f8CDU_2FYRIB7fPqV_fyjWMcuk
Cc: greenbutton-dev 
Subject: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 16 Feb 2014 03:00:53 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0024_01CF2A7F.E1E38030
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I would like to get the views and comments of the OAuth 2.0 IETF WG on the
following design and implementation question:

 

I have an application that supports both "authorization_code" and
"client_credentials" based access tokens.  The application allows a client
to obtain data on a nightly basis for resource owners who have granted the
application access to their data.  The client application retrieves energy
usage information and can potentially need to retrieve data from a few
accounts to several million accounts.  In order to eliminate the need for
the client application to request the data from the resource server one
account at a time, the client application has been designed to support
"client_credentials" based access tokens.  Per [RFC 6749 Section 4.4 -
"Client Credentials Grant"] The use of the "client_credentials" based access
token will allow the client application to obtain access to the data with a
single request, thus significantly reducing the amount of network traffic
for both the client and the resource server.

 

The question the design team is struggling with is what should the Scope
string be for the "client_credentials" based access token and should there
be a single access token or can there be multiple "client_credentials" based
access tokens?

 

The client application currently supports the following Scope definitions:

 

.
FB=4_5_15;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13



.
FB=4_5_16;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13

 

There are several allowable values for the FB=, IntervalDuration=,
BlockDuration=, and HistoryLength= values.  At the moment, there are only
two defined Scope values, but as you can see, there could easily be many
more potential possibilities.  

 

The question being discussed, is does the "client_credentials" access token
request Scope parameter need to match either of the above two strings or can
it be something altogether different?  In the event the "client_credentials"
access token request Scope parameter needs to match a defined Scope string,
does that mean that there MUST be multiple "client_credentials" based access
tokens?

 

Thanks in advance for helping clarify our understanding of the relationship
between "authorization_code" and "client_credentials" based access tokens.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

 

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

 


------=_NextPart_000_0024_01CF2A7F.E1E38030
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I would like to =
get the views and comments of the OAuth 2.0 IETF WG on the following =
design and implementation question:
 
I have an =
application that supports both “authorization_code” and =
“client_credentials” based access tokens.  The =
application allows a client to obtain data on a nightly basis for =
resource owners who have granted the application access to their =
data.  The client application retrieves energy usage information =
and can potentially need to retrieve data from a few accounts to several =
million accounts.  In order to eliminate the need for the client =
application to request the data from the resource server one account at =
a time, the client application has been designed to support =
“client_credentials” based access tokens.  Per [RFC =
6749 Section 4.4 – “Client Credentials Grant”] The use =
of the “client_credentials” based access token will allow =
the client application to obtain access to the data with a single =
request, thus significantly reducing the amount of network traffic for =
both the client and the resource server.
 
The question =
the design team is struggling with is what should the Scope string be =
for the “client_credentials” based access token and should =
there be a single access token or can there be multiple =
“client_credentials” based access =
tokens?
 
The client =
application currently supports the following Scope =
definitions:
 
·         =
FB=3D4_5_15;Inte=
rvalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13

·         =
FB=3D4_5_16;Inte=
rvalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13<=
/span>
 
There are =
several allowable values for the FB=3D, IntervalDuration=3D, =
BlockDuration=3D, and HistoryLength=3D values.  At the moment, =
there are only two defined Scope values, but as you can see, there could =
easily be many more potential possibilities.  =

 
The question =
being discussed, is does the “client_credentials” access =
token request Scope parameter need to match either of the above two =
strings or can it be something altogether different?  In the event =
the “client_credentials” access token request Scope =
parameter needs to match a defined Scope string, does that mean that =
there MUST be multiple “client_credentials” based access =
tokens?
 
Thanks in =
advance for helping clarify our understanding of the relationship =
between “authorization_code” and =
“client_credentials” based access =
tokens.
 
Best =
regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836
 
Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks=
.com
 

------=_NextPart_000_0024_01CF2A7F.E1E38030--


From nobody Sat Feb 15 20:30:27 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E9E1A034D for ; Sat, 15 Feb 2014 20:30:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nkh6nRBuvQlq for ; Sat, 15 Feb 2014 20:30:23 -0800 (PST)
Received: from nm50-vm2.bullet.mail.bf1.yahoo.com (nm50-vm2.bullet.mail.bf1.yahoo.com [216.109.115.221]) by ietfa.amsl.com (Postfix) with ESMTP id AA33F1A034A for ; Sat, 15 Feb 2014 20:30:22 -0800 (PST)
Received: from [98.139.212.153] by nm50.bullet.mail.bf1.yahoo.com with NNFMP;  16 Feb 2014 04:30:20 -0000
Received: from [98.139.212.206] by tm10.bullet.mail.bf1.yahoo.com with NNFMP;  16 Feb 2014 04:30:20 -0000
Received: from [127.0.0.1] by omp1015.mail.bf1.yahoo.com with NNFMP; 16 Feb 2014 04:30:20 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 453658.32554.bm@omp1015.mail.bf1.yahoo.com
Received: (qmail 20146 invoked by uid 60001); 16 Feb 2014 04:30:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392525020; bh=G3MZHetHpgAuyww5ADWRMbWQ/BKhcHWzSNUgb2I/Tbs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=K1uqNXwpfisQlvUCxNcISEeQ38zr4ycNMqQsYUr3esqJrEkVkeMnaLqch72ngfKVclmDhUw8fQedsh+426Uxah8CiDIpdv+VBwyxlB4HuXYCyMl7vTK7CdqpTTJqWFaG3g0MxCMzFC49yPbz8ekq9ytYemJPA1mbXQhIiGvBp84=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VzRr3uqp0AJX0aLdcJQKZmnZlntITq0hnERol2T43Mxu4Ylknt00ygqqTieV+BMQbu6KllyMolU8UJ+z9ZB/6Bc7yil5tvuFE+oW1ALAi2GG4esA1BKclBvvFWJWGQP0P+LhJ3kgCLyGZDnaj9ttL1VzbwUCiDj3KLpyY+QP/GA=;
X-YMail-OSG: DoameloVM1ninSDiYKE823yi9748FFVL4rmgwvlEtyDwF5_ oQgfkMGU7rqKEea4CZxYBZxl1m7fR1tOhjo6md26qqMTqdc5h5vTclVdz_bn qmcaUsu7NJd12vp31TliGsWwGlsHqOceHZK7BgW9_u5SysDN3JNnRoO98MoO SyRblmLNDmDzAln9ikuSgkR_SVyGtDrc3i2_P_VWkDvSvYZwHCa03XAk8i.o X_kZmeVMnDDT77DpiGzTnF8AUL_cGy9hgN.Z6ctog_szcDuekGnXpIWehxqS 6ggrz.WaJBKCfh_pvC4pWHLZF4Q9SLCfGEhMXbEhOJHt55EN99UGzbMIRSlt VijcqsgOSr3IBcXYhSDVsxs6oEYNO0S1kntP0s6vfbhL9CBVbOkCXJM3NgTv a04H8idU9EFPj6XAX6htCmIYjx4qfmtTS26rd9Eiw.5OMfWQkReX6m7I16iS jHRhpO3K9KmVulesgNJDWsOLZZuO8IEicarbxDzky5i_M4qJVxPl9tbNmrTK zEHwUPYB7lo698RPoXbyo6k52xoYj6W4fnUjXknPKr8njs9Vri4RA.rBkIMu Ua7sJlJkJpWiVQLE-
Received: from [99.31.212.42] by web142801.mail.bf1.yahoo.com via HTTP; Sat, 15 Feb 2014 20:30:20 PST
X-Rocket-MIMEInfo: 002.001, VG8gdG9rZW5zIHRoZW1zZWx2ZXMgZG9uJ3QgZGlmZmVyIGJhc2VkIG9uIGhvdyB0aGV5IGFyZSBvYnRhaW5lZCB1bmxlc3MgeW91IHdhbnQgdGhlbSB0by4gwqBObyByZXF1aXJlbWVudCB0byBtYXRjaCBzY29wZSB0byB0aGUgY2xpZW50IElEIGVpdGhlciwgYnV0IGFnYWluIGl0J3MgdXAgdG8geW91LgoKWW91IGRvIHdhbnQgdG8gZ2V0IHRoaXMgcmlnaHQuIMKgVGhlIGNoYWxsZW5nZSBoZXJlIGlzIHRoYXQgeW91ciByZXNvdXJjZSBzZXJ2ZXJzIGhhdmUgdG8gZ2V0IHVwZGF0ZWQgdG8gc3VwcG9ydCBuZXcBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.177.636
References: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com>
Message-ID: <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com>
Date: Sat, 15 Feb 2014 20:30:20 -0800 (PST)
From: Bill Mills 
To: Donald Coffin , "oauth@ietf.org" 
In-Reply-To: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="469468616-1506815308-1392525020=:7390"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FYrM_UdMFQBaKtYGghoJvWScISg
Cc: greenbutton-dev 
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 16 Feb 2014 04:30:25 -0000

--469468616-1506815308-1392525020=:7390
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

To tokens themselves don't differ based on how they are obtained unless you=
 want them to. =C2=A0No requirement to match scope to the client ID either,=
 but again it's up to you.=0A=0AYou do want to get this right. =C2=A0The ch=
allenge here is that your resource servers have to get updated to support n=
ew scopes. =C2=A0If they support auto-updates then it's not quite as big a =
deal but it's still non-trivial.=0A=0A-bill=0A=0A=0A=0A=0A=0AOn Saturday, F=
ebruary 15, 2014 7:01 PM, Donald Coffin  wr=
ote:=0A =0AI would like to get the views and comments of the OAuth 2.0 IETF=
 WG on the following design and implementation question:=0A=C2=A0=0AI have =
an application that supports both =E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.=C2=A0 The applica=
tion allows a client to obtain data on a nightly basis for resource owners =
who have granted the application access to their data.=C2=A0 The client app=
lication retrieves energy usage information and can potentially need to ret=
rieve data from a few accounts to several million accounts.=C2=A0 In order =
to eliminate the need for the client application to request the data from t=
he resource server one account at a time, the client application has been d=
esigned to support =E2=80=9Cclient_credentials=E2=80=9D based access tokens=
.=C2=A0 Per [RFC 6749 Section 4.4 =E2=80=93 =E2=80=9CClient Credentials Gra=
nt=E2=80=9D] The use of the =E2=80=9Cclient_credentials=E2=80=9D based acce=
ss token will allow the client application to obtain access to the data wit=
h a single request, thus significantly reducing the amount of network traff=
ic for both the client and the resource server.=0A=C2=A0=0AThe question the=
 design team is struggling with is what should the Scope string be for the =
=E2=80=9Cclient_credentials=E2=80=9D based access token and should there be=
 a single access token or can there be multiple =E2=80=9Cclient_credentials=
=E2=80=9D based access tokens?=0A=C2=A0=0AThe client application currently =
supports the following Scope definitions:=0A=C2=A0=0A=C2=B7=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_15;IntervalDuration=3D900;BlockD=
uration=3Dmonthly;HistoryLength=3D13=0A=0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=
=3Dmonthly;HistoryLength=3D13=0A=C2=A0=0AThere are several allowable values=
 for the FB=3D, IntervalDuration=3D, BlockDuration=3D, and HistoryLength=3D=
 values.=C2=A0 At the moment, there are only two defined Scope values, but =
as you can see, there could easily be many more potential possibilities.=C2=
=A0 =0A=C2=A0=0AThe question being discussed, is does the =E2=80=9Cclient_c=
redentials=E2=80=9D access token request Scope parameter need to match eith=
er of the above two strings or can it be something altogether different?=C2=
=A0 In the event the =E2=80=9Cclient_credentials=E2=80=9D access token requ=
est Scope parameter needs to match a defined Scope string, does that mean t=
hat there MUST be multiple =E2=80=9Cclient_credentials=E2=80=9D based acces=
s tokens?=0A=C2=A0=0AThanks in advance for helping clarify our understandin=
g of the relationship between =E2=80=9Cauthorization_code=E2=80=9D and =E2=
=80=9Cclient_credentials=E2=80=9D based access tokens.=0A=C2=A0=0ABest rega=
rds,=0ADon=0ADonald F. Coffin=0AFounder/CTO=0A=C2=A0=0AREMI Networks=0A2275=
1 El Prado Suite 6216=0ARancho Santa Margarita, CA=C2=A0 92688-3836=0A=C2=
=A0=0APhone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571=0AEmail:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com=0A=C2=A0=0A_____=
__________________________________________=0AOAuth mailing list=0AOAuth@iet=
f.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth
--469468616-1506815308-1392525020=:7390
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


To tokens themselves don't differ based on how the=
y are obtained unless you want them to.  No requirement to match scope=
 to the client ID either, but again it's up to you.

You do want to get this right.  The ch=
allenge here is that your resource servers have to get updated to support n=
ew scopes.  If they support auto-updates then it's not quite as big a
 deal but it's still non-trivial.

-bill

<=
div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNe=
ue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; backgr=
ound-color: transparent; font-style: normal;">
 
 
 
 
=
 
  On Saturday, February 1=
5, 2014 7:01 PM, Donald Coffin <donald.coffin@reminetworks.com> wrote=
:
  
  
I would like to get the views and comments of th=
e OAuth 2.0 IETF WG on the following design and implementation question:
  
I have an application that supports both =E2=80=9Cauthorization_code=
=E2=80=9D and =E2=80=9Cclient_credentials=E2=80=9D based access tokens.&nbs=
p; The application allows a client to obtain data on a nightly basis for re=
source owners who have granted the application access to their data.  =
The client application retrieves energy usage information and can potential=
ly need to retrieve data from a few accounts to several million accounts.&n=
bsp; In order to eliminate the need for the client
 application to request the data from the resource server one account at a =
time, the client application has been designed to support =E2=80=9Cclient_c=
redentials=E2=80=9D based access tokens.  Per [RFC 6749 Section 4.4 =
=E2=80=93 =E2=80=9CClient Credentials Grant=E2=80=9D] The use of the =E2=80=
=9Cclient_credentials=E2=80=9D based access token will allow the client app=
lication to obtain access to the data with a single request, thus significa=
ntly reducing the amount of network traffic for both the client and the res=
ource server.
  
The question the design team is struggling with is wha=
t should the Scope string be for the =E2=80=9Cclient_credentials=E2=80=9D b=
ased access token and should there be a single access token or can there be=
 multiple =E2=80=9Cclient_credentials=E2=80=9D based access
 tokens?
  
The client application currently supports the following Sco=
pe definitions:
  
=C2=B7<=
span style=3D"font-style: normal; font-variant: normal; font-weight: normal=
; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">&nb=
sp;        FB=3D4_5_15;IntervalD=
uration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13

=C2=B7 =
;        FB=3D4_5_16;IntervalDur=
ation=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13
  
=
There are sev=
eral allowable values for the FB=3D, IntervalDuration=3D, BlockDuration=3D,=
 and HistoryLength=3D values.  At the moment, there are only two defin=
ed Scope values, but as you can see, there could easily be many more potent=
ial possibilities. 
 
  
The question being discussed, is does the =E2=80=9Cclient_credenti=
als=E2=80=9D access token request Scope parameter need to match either of t=
he above two strings or can it be something altogether different?  In =
the event the =E2=80=9Cclient_credentials=E2=80=9D access token request Sco=
pe parameter needs to match a defined Scope string, does that mean that the=
re MUST be multiple =E2=80=9Cclient_credentials=E2=80=9D based access token=
s?
  
Thanks in advance for helping clarify our understanding of the re=
lationship between =E2=80=9Cauthorization_code=E2=80=9D
 and =E2=80=9Cclient_credentials=E2=80=9D based access tokens.
=

  
Best regards,
Don
=
Donald F. Coffin
Founder/CTO
  
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 
 92688-3836
  
Phone:     =
; (949) 636-8571
Email:       donald.coffin@reminet=
works.com
  

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


  
 
  
 

--469468616-1506815308-1392525020=:7390--


From nobody Sun Feb 16 17:15:13 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CFD1A02C3 for ; Sun, 16 Feb 2014 17:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Level: 
X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyFEeW4C3-WN for ; Sun, 16 Feb 2014 17:15:04 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 5B92C1A0294 for ; Sun, 16 Feb 2014 17:15:03 -0800 (PST)
Received: (qmail 28170 invoked by uid 0); 17 Feb 2014 01:13:55 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 17 Feb 2014 01:13:55 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw3 with  id TLDm1n00D2is6CS01LDpkx; Mon, 17 Feb 2014 01:13:54 -0700
X-Authority-Analysis: v=2.1 cv=RodWckWK c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=d-K1uXnm4cMA:10 a=8dE94GJacnkA:10 a=UGkfVyPCAAAA:8 a=S71PjDr2FGoA:10 a=rE68L1KyjUoA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=CjxXgO3LAAAA:8 a=48vgC7mUAAAA:8 a=oKP0rcp2K9NtoCZRy2sA:9 a=-NCC91e-xOn4sofj:21 a=kiL_TTvjLwVjxmus:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=0qEjrYlnuRwA:10 a=rC2wZJ5BpNYA:10 a=lZB815dzVvQA:10 a=M6Kqmjw4cQ4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=1XiioecUQsFQGx-2:21 a=X5kVEmVc7fyQJbv8:21 a=-JZyIkZ5rYmbY9m7:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=u3fDgPNuHa5/7QDf2asG+EoVeDKCxGytIhQe+RZl+8o=;  b=AurCGSukeB5jbgg127z36XR1+9b131Ki8L/oF3tGWYBil93d4E6qq2+PeNPzHHjzFikFROrMV8AAXhgeXM6XDf7UoQXKQMhDBwqa/IrPs8NoCRydIi2CGQ8emvvRdvSU;
Received: from [68.5.51.152] (port=49500 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1WFCmK-0005P7-4s; Sun, 16 Feb 2014 18:13:48 -0700
From: "Donald Coffin" 
To: "'Bill Mills'" , 
References: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com> <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com>
In-Reply-To: <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com>
Date: Sun, 16 Feb 2014 17:13:30 -0800
Organization: REMI Networks
Message-ID: <000e01cf2b7d$79a66c90$6cf345b0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CF2B3A.6B8660E0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEnOl+8JZU1HiFwOiLE96BHahHifwH2C3usm/jVJHA=
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.5.51.152 authed with donald.coffin@reminetworks.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/o31Ld2jFwYtohrMD5ejZiOmliIk
Cc: 'greenbutton-dev' 
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2014 01:15:12 -0000

This is a multipart message in MIME format.

------=_NextPart_000_000F_01CF2B3A.6B8660E0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Bill,

=20

Thanks for your reply, but I=E2=80=99m not sure you fully understand the =
situation I am attempting to resolve.

=20

For example, does an access token obtained via the =
=E2=80=9Cclient_credentials=E2=80=9D request with the following SCOPE =
parameter:

                        BulkID=3D04

allow a client to ask for resources when the individual access token =
contained the following SCOPE parameter:

                        =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13

=20

The question is what individual access token authorization should be =
covered by the =E2=80=9Cclient_credentials=E2=80=9D based access token?

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:         =
donald.coffin@reminetworks.com

=20

From: Bill Mills [mailto:wmills_92105@yahoo.com]=20
Sent: Saturday, February 15, 2014 8:30 PM
To: Donald Coffin; oauth@ietf.org
Cc: greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" =
and "client_credentials" based access tokens

=20

To tokens themselves don't differ based on how they are obtained unless =
you want them to.  No requirement to match scope to the client ID =
either, but again it's up to you.

=20

You do want to get this right.  The challenge here is that your resource =
servers have to get updated to support new scopes.  If they support =
auto-updates then it's not quite as big a deal but it's still =
non-trivial.

=20

-bill

=20

=20

=20

On Saturday, February 15, 2014 7:01 PM, Donald Coffin =
 wrote:

I would like to get the views and comments of the OAuth 2.0 IETF WG on =
the following design and implementation question:

=20

I have an application that supports both =
=E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  The =
application allows a client to obtain data on a nightly basis for =
resource owners who have granted the application access to their data.  =
The client application retrieves energy usage information and can =
potentially need to retrieve data from a few accounts to several million =
accounts.  In order to eliminate the need for the client application to =
request the data from the resource server one account at a time, the =
client application has been designed to support =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  Per [RFC 6749 =
Section 4.4 =E2=80=93 =E2=80=9CClient Credentials Grant=E2=80=9D] The =
use of the =E2=80=9Cclient_credentials=E2=80=9D based access token will =
allow the client application to obtain access to the data with a single =
request, thus significantly reducing the amount of network traffic for =
both the client and the resource server.

=20

The question the design team is struggling with is what should the Scope =
string be for the =E2=80=9Cclient_credentials=E2=80=9D based access =
token and should there be a single access token or can there be multiple =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens?

=20

The client application currently supports the following Scope =
definitions:

=20

=C2=B7         =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13

=C2=B7         =
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13

=20

There are several allowable values for the FB=3D, IntervalDuration=3D, =
BlockDuration=3D, and HistoryLength=3D values.  At the moment, there are =
only two defined Scope values, but as you can see, there could easily be =
many more potential possibilities. =20

=20

The question being discussed, is does the =
=E2=80=9Cclient_credentials=E2=80=9D access token request Scope =
parameter need to match either of the above two strings or can it be =
something altogether different?  In the event the =
=E2=80=9Cclient_credentials=E2=80=9D access token request Scope =
parameter needs to match a defined Scope string, does that mean that =
there MUST be multiple =E2=80=9Cclient_credentials=E2=80=9D based access =
tokens?

=20

Thanks in advance for helping clarify our understanding of the =
relationship between =E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20


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




------=_NextPart_000_000F_01CF2B3A.6B8660E0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Bill,
 
Thanks =
for your reply, but I=E2=80=99m not sure you fully understand the =
situation I am attempting to resolve.
 
For example, does an access =
token obtained via the =E2=80=9Cclient_credentials=E2=80=9D request with =
the following SCOPE =
parameter:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 BulkID=3D04

allow a client to ask for resources when the =
individual access token contained the following SCOPE =
parameter:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 FB=3D4_5_15;IntervalD=
uration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13
 
The =
question is what individual access token authorization should be covered =
by the =E2=80=9Cclient_credentials=E2=80=9D based access =
token?
 
=

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
=

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA=C2=A0 92688-3836
 
=

Phone:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 (949) 636-8571
Email:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 donald.coffin@reminetworks.com=

 
=

From:=
 =
Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: Saturday, =
February 15, 2014 8:30 PM
To: Donald Coffin; =
oauth@ietf.org
Cc: greenbutton-dev
Subject: Re: =
[OAUTH-WG] Scope parameter values for "authorization_code" and =
"client_credentials" based access =
tokens
 
To tokens =
themselves don't differ based on how they are obtained unless you want =
them to.  No requirement to match scope to the client ID either, =
but again it's up to you.
 
You do want =
to get this right.  The challenge here is that your resource =
servers have to get updated to support new scopes.  If they support =
auto-updates then it's not quite as big a deal but it's still =
non-trivial.
 
-bill
 
 
 
O=
n Saturday, February 15, 2014 7:01 PM, Donald Coffin <donald.coffin@reminetworks=
.com> wrote:
I would like to get =
the views and comments of the OAuth 2.0 IETF WG on the following design =
and implementation question:
 
I have an =
application that supports both =E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  The =
application allows a client to obtain data on a nightly basis for =
resource owners who have granted the application access to their =
data.  The client application retrieves energy usage information =
and can potentially need to retrieve data from a few accounts to several =
million accounts.  In order to eliminate the need for the client =
application to request the data from the resource server one account at =
a time, the client application has been designed to support =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  Per [RFC =
6749 Section 4.4 =E2=80=93 =E2=80=9CClient Credentials Grant=E2=80=9D] =
The use of the =E2=80=9Cclient_credentials=E2=80=9D based access token =
will allow the client application to obtain access to the data with a =
single request, thus significantly reducing the amount of network =
traffic for both the client and the resource server.
 
The question the =
design team is struggling with is what should the Scope string be for =
the =E2=80=9Cclient_credentials=E2=80=9D based access token and should =
there be a single access token or can there be multiple =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens?
 
The client =
application currently supports the following Scope =
definitions:
 
=C2=B7      =
;   FB=3D4_5_15;IntervalD=
uration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13
=C2=B7      =
;   FB=3D4_5_16;IntervalD=
uration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13
 
There are several =
allowable values for the FB=3D, IntervalDuration=3D, BlockDuration=3D, =
and HistoryLength=3D values.  At the moment, there are only two =
defined Scope values, but as you can see, there could easily be many =
more potential possibilities.  
 
The question being =
discussed, is does the =E2=80=9Cclient_credentials=E2=80=9D access token =
request Scope parameter need to match either of the above two strings or =
can it be something altogether different?  In the event the =
=E2=80=9Cclient_credentials=E2=80=9D access token request Scope =
parameter needs to match a defined Scope string, does that mean that =
there MUST be multiple =E2=80=9Cclient_credentials=E2=80=9D based access =
tokens?
 
Thanks in advance =
for helping clarify our understanding of the relationship between =
=E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
22751 El =
Prado Suite 6216
Rancho Santa =
Margarita, CA  92688-3836
 
Phone: &n=
bsp;    (949) 636-8571
Email: &n=
bsp;     donald.coffin@reminetworks.com
 

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

=


------=_NextPart_000_000F_01CF2B3A.6B8660E0--


From nobody Sun Feb 16 22:01:50 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F0F1A034B for ; Sun, 16 Feb 2014 22:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEQY3U_IdU07 for ; Sun, 16 Feb 2014 22:01:43 -0800 (PST)
Received: from nm34-vm5.bullet.mail.bf1.yahoo.com (nm34-vm5.bullet.mail.bf1.yahoo.com [72.30.239.77]) by ietfa.amsl.com (Postfix) with ESMTP id 276A21A02DD for ; Sun, 16 Feb 2014 22:01:43 -0800 (PST)
Received: from [66.196.81.172] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 06:01:40 -0000
Received: from [98.139.212.212] by tm18.bullet.mail.bf1.yahoo.com with NNFMP;  17 Feb 2014 06:01:40 -0000
Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 06:01:40 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 448201.60580.bm@omp1021.mail.bf1.yahoo.com
Received: (qmail 44103 invoked by uid 60001); 17 Feb 2014 06:01:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392616900; bh=Mnuhkxev5EsCKPU63KyJGDwqWptvapzFNkW4wv7Unvs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fvmFCMcU+aJc8xhlKkr8pdu7v7Tmgsgq2zCV9LaKNhkeaUBQ1jFD7PAE3GlidCMT5MSQ5vznnR79vjznItiNibb16Xb2J07McXfQV08+5xJbUzVI/a8ICVAnWgEkjw/DYN+7zf03hyi7zsXGcqPqaoaEdGlLxc5KEqM04zZgkCQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TFbc5CM6HvN6Z+0gj45mHokT5Es/wwhe5Pl7+/c21u1WJQtwvNx9TKbxIf8ivwy4NMJSFo4kt5c4DNbKVb12XdlcBMBsF12Ibg0JPyn7tkU4/vBCslZdYD3IPrI52y1ET4ubBFtMbKPtoZs2p0872/F+9bnRwVLvnl+RNEo7f30=;
X-YMail-OSG: EGoDPlMVM1kP42NTY01lf31Uda3Drh3S7dW4zpiSmE1fmfr NJZxhyMayOdde8PadyMOn7WDe.L1D2D97tMgMpTkdTemdZ0SF_oCYN.SbmSX BLJNa.pshaLYLjjwpZJXuZZl3qERA9PUoi2CkQI4iYmK5Ak31rIKnVB.dBUV RP7sihAfN1WxGWQAUgCY8YjrAXmJu7_MGA_n37rmjz55sPTFKas16.y0YQYo L0p2XUHLmeCdPr8PUPIoN1VLjaSC3pKmIkJn2CzyrbldYqd6k4FLQMRLCy0t XCy0lCh.18gXkXPkahwlMTqgrqSX5F_QHQXlWKn48iP.vMtKtcx0w7XyWhtA NMKj0zGthSyfmskAGj_PY4kFDAjmopNXM8MueC9nfJNQ8E5HTAxoOv9Gn6sj 1vi3ZfAes..WSXfO8aPErTaTuAmtz9U88rQwKJPc4hU0qG24MbqAlOxjMfUz vyu3kpHecndgG5ObUS_cBn2eq.U4aE63cebdnlSwP9aUXirWqaR31pCgwjYF S5NLgYov9lF.D5MwZ7Q9PFT0P1PY_twZcDsbStMQoHcqyqhhpuIffo5HlaMU 8ZGSG2YBAOP0CBPG8CtdZnYjTdLlvc5iu49VRlTG55jYsZroc.n0221gnbVC TiQd1MM4POQTukITf6obE.53lteKKecRJbkt5M0Y.djL20g1RudG1eAya.Kh v27JUFNI-
Received: from [99.31.212.42] by web142801.mail.bf1.yahoo.com via HTTP; Sun, 16 Feb 2014 22:01:40 PST
X-Rocket-MIMEInfo: 002.001, VGhlIHNjb3BlIHJlcXVlc3RlZCBkb2VzIG5vdCBoYXZlIHRvIG1hdGNoIHRoZSBzY29wZSBncmFudGVkLiDCoAoKQWxzbyBub3RlIHRoYXQgc3BhY2UgaXMgdGhlIHNjb3BlIHNlcGFyYXRvciBwZXIgdGhlIHNwZWMsIHNvIEJSPTA0IGlzIG5vdCBlcXVhbCB0byBGQj00XzVfMTU7SW50ZXJ2YWxEdXJhdGlvbj05MDA7QmxvY2tEdXJhdGlvbj1tb250aGx5O0hpc3RvcnlMZW5ndGg9MTM7QlI9MDQgYnV0IGl0J3MgeW91ciBpbXBsZW1lbnRhdGlvbiBvZiBob3cgeW91IHdhbnQgdG8gaW50ZXJwcmV0IHNjb3Blcy4BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.177.636
References: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com> <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com> <000e01cf2b7d$79a66c90$6cf345b0$@reminetworks.com> <0e9117b9bb80c29d3e3a53ab64392e94@mail.gmail.com>
Message-ID: <1392616900.46009.YahooMailNeo@web142801.mail.bf1.yahoo.com>
Date: Sun, 16 Feb 2014 22:01:40 -0800 (PST)
From: Bill Mills 
To: Marty Burns , Donald Coffin , "oauth@ietf.org" 
In-Reply-To: <0e9117b9bb80c29d3e3a53ab64392e94@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="469468616-904707550-1392616900=:46009"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/mz0KgjJKPfcNrVUyO51dJyG2lRw
Cc: greenbutton-dev 
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2014 06:01:47 -0000

--469468616-904707550-1392616900=:46009
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The scope requested does not have to match the scope granted. =C2=A0=0A=0AA=
lso note that space is the scope separator per the spec, so BR=3D04 is not =
equal to FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;History=
Length=3D13;BR=3D04 but it's your implementation of how you want to interpr=
et scopes.=0A=0A=0A=0AOn Sunday, February 16, 2014 5:36 PM, Marty Burns  wrote:=0A =0ADon,=0A=C2=A0=0AGood comment. One point =E2=
=80=93 the authorizations covered by BulkId=3D04 would have Scopes of:=0A=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_15=
;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04=
=0AMarty=0A=C2=A0=0A=C2=A0=0AFrom:greenbutton-dev@googlegroups.com [mailto:=
greenbutton-dev@googlegroups.com] On Behalf Of Donald Coffin=0ASent: Sunday=
, February 16, 2014 8:14 PM=0ATo: 'Bill Mills'; oauth@ietf.org=0ACc: 'green=
button-dev'=0ASubject: RE: [OAUTH-WG] Scope parameter values for "authoriza=
tion_code" and "client_credentials" based access tokens=0A=C2=A0=0ABill,=0A=
=C2=A0=0AThanks for your reply, but I=E2=80=99m not sure you fully understa=
nd the situation I am attempting to resolve.=0A=C2=A0=0AFor example, does a=
n access token obtained via the =E2=80=9Cclient_credentials=E2=80=9D reques=
t with the following SCOPE parameter:=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BulkID=3D04=0A=0Aallow a client to ask fo=
r resources when the individual access token contained the following SCOPE =
parameter:=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLe=
ngth=3D13=0A=C2=A0=0AThe question is what individual access token authoriza=
tion should be covered by the =E2=80=9Cclient_credentials=E2=80=9D based ac=
cess token?=0A=C2=A0=0ABest regards,=0ADon=0ADonald F. Coffin=0AFounder/CTO=
=0A=C2=A0=0AREMI Networks=0A22751 El Prado Suite 6216=0ARancho Santa Margar=
ita, CA=C2=A0 92688-3836=0A=C2=A0=0APhone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (9=
49) 636-8571=0AEmail:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@rem=
inetworks.com=0A=C2=A0=0AFrom:Bill Mills [mailto:wmills_92105@yahoo.com] =
=0ASent: Saturday, February 15, 2014 8:30 PM=0ATo: Donald Coffin; oauth@iet=
f.org=0ACc: greenbutton-dev=0ASubject: Re: [OAUTH-WG] Scope parameter value=
s for "authorization_code" and "client_credentials" based access tokens=0A=
=C2=A0=0ATo tokens themselves don't differ based on how they are obtained u=
nless you want them to. =C2=A0No requirement to match scope to the client I=
D either, but again it's up to you.=0A=C2=A0=0AYou do want to get this righ=
t. =C2=A0The challenge here is that your resource servers have to get updat=
ed to support new scopes. =C2=A0If they support auto-updates then it's not =
quite as big a deal but it's still non-trivial.=0A=C2=A0=0A-bill=0A=C2=A0=
=0A=C2=A0=0A=C2=A0=0AOn Saturday, February 15, 2014 7:01 PM, Donald Coffin =
 wrote:=0AI would like to get the views and=
 comments of the OAuth 2.0 IETF WG on the following design and implementati=
on question:=0A=C2=A0=0AI have an application that supports both =E2=80=9Ca=
uthorization_code=E2=80=9D and =E2=80=9Cclient_credentials=E2=80=9D based a=
ccess tokens.=C2=A0 The application allows a client to obtain data on a nig=
htly basis for resource owners who have granted the application access to t=
heir data.=C2=A0 The client application retrieves energy usage information =
and can potentially need to retrieve data from a few accounts to several mi=
llion accounts.=C2=A0 In order to eliminate the need for the client applica=
tion to request the data from the resource server one account at a time, th=
e client application has been designed to support =E2=80=9Cclient_credentia=
ls=E2=80=9D based access tokens.=C2=A0 Per [RFC 6749 Section 4.4 =E2=80=93 =
=E2=80=9CClient Credentials Grant=E2=80=9D] The use of the =E2=80=9Cclient_=
credentials=E2=80=9D based access token will allow the client application t=
o obtain access to the data with a single request, thus significantly reduc=
ing the amount of network traffic for both the client and the resource serv=
er.=0A=C2=A0=0AThe question the design team is struggling with is what shou=
ld the Scope string be for the =E2=80=9Cclient_credentials=E2=80=9D based a=
ccess token and should there be a single access token or can there be multi=
ple =E2=80=9Cclient_credentials=E2=80=9D based access tokens?=0A=C2=A0=0ATh=
e client application currently supports the following Scope definitions:=0A=
=C2=A0=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_15=
;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13=0A=C2=B7=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_16;IntervalDurati=
on=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13=0A=C2=A0=0AThere are se=
veral allowable values for the FB=3D, IntervalDuration=3D, BlockDuration=3D=
, and HistoryLength=3D values.=C2=A0 At the moment, there are only two defi=
ned Scope values, but as you can see, there could easily be many more poten=
tial possibilities.=C2=A0 =0A=C2=A0=0AThe question being discussed, is does=
 the =E2=80=9Cclient_credentials=E2=80=9D access token request Scope parame=
ter need to match either of the above two strings or can it be something al=
together different?=C2=A0 In the event the =E2=80=9Cclient_credentials=E2=
=80=9D access token request Scope parameter needs to match a defined Scope =
string, does that mean that there MUST be multiple =E2=80=9Cclient_credenti=
als=E2=80=9D based access tokens?=0A=C2=A0=0AThanks in advance for helping =
clarify our understanding of the relationship between =E2=80=9Cauthorizatio=
n_code=E2=80=9D and =E2=80=9Cclient_credentials=E2=80=9D based access token=
s.=0A=C2=A0=0ABest regards,=0ADon=0ADonald F. Coffin=0AFounder/CTO=0A=C2=A0=
=0AREMI Networks=0A22751 El Prado Suite 6216=0ARancho Santa Margarita, CA=
=C2=A0 92688-3836=0A=C2=A0=0APhone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636=
-8571=0AEmail:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@reminetwor=
ks.com=0A=C2=A0=0A=0A_______________________________________________=0AOAut=
h mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oau=
th=0A-- =0AYou received this message because you are subscribed to the Goog=
le Groups "greenbutton-dev" group.=0ATo unsubscribe from this group and sto=
p receiving emails from it, send an email to greenbutton-dev+unsubscribe@go=
oglegroups.com.=0AFor more options, visit https://groups.google.com/groups/=
opt_out.
--469468616-904707550-1392616900=:46009
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


The scope requested does not have to match the sco=
pe granted.  

Also note that space is the scope separator per the spec, so BR=3D04 is=
 not equal to FB=3D4=
_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04=
 but it's your implementation of how you want to interpret scopes.
 
 
 
 
 
  On =
Sunday, February 16,
 2014 5:36 PM, Marty Burns <marty@hypertek.us> wrote:
    
Don,=0A
 
Good comment. One point =E2=80=93 the authorizations co=
vered by BulkId=3D04 would have =
Scopes of:
=0A
       =
;            &n=
bsp;    FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D04
=0A
Marty
 
=0A
 
=0AFrom: greenbutton=
-dev@googlegroups.com [mailto:greenbutton-dev@googlegroups.com]=
 On Behalf Of Donald Coffin
=0ASent: Sunday=
, February 16, 2014 8:14 PM
To: 'Bill Mills'; oauth@ietf.org
Cc: 'greenbutton-dev'
Subject: RE: [OAUTH-=
WG] Scope parameter values for "authorization_code" and "client_credentials=
" based access tokens
=0A
 
Bill,
 
=0A
Thanks for your reply, but I=E2=80=99m not sure you fully understan=
d the situation I am attempting to resolve.
 
=0A
For examp=
le, does an access token obtained via the =E2=80=9Cclient_credentials=E2=80=
=9D request with the following SCOPE parameter:
=0A
          &n=
bsp;            =
; BulkID=3D04

allow a client to ask fo=
r resources when the individual access token contained the following SCOPE =
parameter:

    &nb=
sp;            =
       FB=3D4_5_=
15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13=

=0A
&nbs=
p;
The q=
uestion is what individual access token authorization should be covered by =
the =E2=80=9Cclient_credentials=E2=80=9D based access token?
=
=0A
 
Best regards,=

=0ADon
Donald F. Coffin
=0AFounder/CTO
 
REMI Networks
=0A
22751 El Prado Suite 6216
Rancho Santa Margarita, =
CA  92688-3836
=0A
 
Phone:      (949) 636-8571=0A
Email: &n=
bsp;     donald.coffin@reminetworks.com
=0A 
From: Bill Mills [mailto:wmills_92105@yahoo.com] 
=0ASent: Saturday, February 15, 2014 8:30 PM
To: Donald C=
offin; oauth@ietf.org
Cc: greenbutton-dev
Subject: Re=
: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_cr=
edentials" based access tokens
=0A
 
To tokens themselves don=
't differ based on how they are obtained unless you want them to.  No =
requirement to match scope to the client ID either, but again it's up to yo=
u.
=0A
 
You do want to get this right.  The challenge here =
is that your resource servers have to get updated to support new scopes. &n=
bsp;If they support auto-updates then it's not quite as big a deal but it's=
 still non-trivial.
=0A
 
-bill
=0A
 
 =0A
 
<=
div>
=0AOn Saturday, February 15, 2014 7:01 PM, Don=
ald Coffin <donald.coffin@reminetworks.com> wrote:
=0A
I would like to get the views and comments of the OAuth 2.0 IETF =
WG on the following design and implementation question:
=0A
 
=0A
I have an application that supports both =E2=
=80=9Cauthorization_code=E2=80=9D and =E2=80=9Cclient_credentials=E2=80=9D =
based access tokens.  The application allows a client to obtain data o=
n a nightly basis for resource owners who have granted the application acce=
ss to their data.  The client application retrieves energy usage infor=
mation and can potentially need to retrieve data from a few accounts to sev=
eral million accounts.  In order to eliminate the need for the client =
application to request the data from the resource server one account at a t=
ime, the client application has been designed to support =E2=80=9Cclient_cr=
edentials=E2=80=9D based access tokens.  Per [RFC 6749 Section 4.4 =E2=
=80=93 =E2=80=9CClient Credentials Grant=E2=80=9D] The use of the =E2=80=9C=
client_credentials=E2=80=9D based access token will allow the client applic=
ation to obtain access to the data with a single request, thus significantl=
y
 reducing the amount of network traffic for both the client and the resourc=
e server.
=0A
 <=
/span>
=0A
The question the =
design team is struggling with is what should the Scope string be for the =
=E2=80=9Cclient_credentials=E2=80=9D based access token and should there be=
 a single access token or can there be multiple =E2=80=9Cclient_credentials=
=E2=80=9D based access tokens?
=0A
 
=0A
The client application currently supports the following Scope definit=
ions:
=0A
 
=0A
=

=C2=B7     =
;    FB=3D4_5_15;IntervalDuration=3D=
900;BlockDuration=3Dmonthly;HistoryLength=3D13
=0A
=C2=B7         F=
B=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D1=
3
=0A
 
=0A
There are several allowab=
le values for the FB=3D, IntervalDuration=3D, BlockDuration=3D, and History=
Length=3D values.  At the moment, there are only two defined Scope val=
ues, but as you can see, there could easily be many more potential possibil=
ities.  
=0A
&n=
bsp;
=0A
The question=
 being discussed, is does the =E2=80=9Cclient_credentials=E2=80=9D access t=
oken request Scope parameter need to match either of the above two strings =
or can it be something altogether different?  In the event the =E2=80=
=9Cclient_credentials=E2=80=9D access token request Scope parameter needs t=
o match a defined Scope string, does that mean that there MUST be multiple =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens?
=0A
 
=0A
Thanks in advance for helping clarify our un=
derstanding of the relationship between =E2=80=9Cauthorization_code=E2=80=
=9D and =E2=80=9Cclient_credentials=E2=80=9D based access tokens.
=0A
 
=0A
Best regards,
=0ADon
=
=0ADonald F. Coffin
Founder=
/CTO
=0A
 
REMI Networks
=0A
22751 El Prado Suite 621=
6
=0ARancho Santa Margarita, CA  92688-=
3836
 
=0A
Phone:      (949) 636-8571
=0AEmail:       donald.coffin@remin=
etworks.com
=0A 
=


=0A______=
_________________________________________
OAuth mailing l=
ist
OAuth@ietf=
.org
https://www.ietf.=
org/mailman/listinfo/oauth
=0A
-- 
You received this message because you are subscribed to the Googl=
e Groups "greenbutton-dev" group.
To unsubscribe from thi=
s group and stop receiving emails from it, send an email to greenbutton-dev+unsubscribe@googlegroups.com.
=0AFor more options, visit https://group=
s.google.com/groups/opt_out.


  
 
  
 

--469468616-904707550-1392616900=:46009--


From nobody Sun Feb 16 22:54:12 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332891A003D for ; Sun, 16 Feb 2014 22:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WZUEzPB563o for ; Sun, 16 Feb 2014 22:54:06 -0800 (PST)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 6F5551A002D for ; Sun, 16 Feb 2014 22:54:04 -0800 (PST)
Received: (qmail 25350 invoked by uid 0); 17 Feb 2014 06:53:59 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy3.mail.unifiedlayer.com with SMTP; 17 Feb 2014 06:53:59 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw4 with  id TRtt1n0092is6CS01RtweK; Mon, 17 Feb 2014 06:53:58 -0700
X-Authority-Analysis: v=2.1 cv=Ht/lRSjS c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=d-K1uXnm4cMA:10 a=8dE94GJacnkA:10 a=UGkfVyPCAAAA:8 a=S71PjDr2FGoA:10 a=rE68L1KyjUoA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=CjxXgO3LAAAA:8 a=48vgC7mUAAAA:8 a=4RBUngkUAAAA:8 a=1XWaLZrsAAAA:8 a=2qiyc8QAdRSH84PpqGsA:9 a=fDom93KKcOWE83Ee:21 a=HgfyfjfpW8GkE0Wz:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=c4S9Whzb7AQA:10 a=0qEjrYlnuRwA:10 a=rC2wZJ5BpNYA:10 a=lZB815dzVvQA:10 a=nsSs_srodhIA:10 a=Bm6qEjDGwGEA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=2dNFFZtfaqtM57Ws:21 a=iQja4pWG3VOdONRk:21 a=WoJ7bjmwdfpB4ZP-:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=SbTkAUmA+jiqie/o29wULg2OXfUzKLTp8/vDn5zIwa8=;  b=TBTGubG780B6HKPoFHvdZFZrVz2l7LDSykbOvml6zp8kCgs7RV8tmnHYPWjd1cMN8eHoNimxWUZvlN8uirh3kxkCKXPqgottoF91mIFAuUveN56SVMyMevRTUMZXdSdN;
Received: from [68.5.51.152] (port=49664 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1WFI5T-0002Wt-7D; Sun, 16 Feb 2014 23:53:55 -0700
From: "Donald Coffin" 
To: "'Bill Mills'" , "'Marty Burns'" , 
References: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com> <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com> <000e01cf2b7d$79a66c90$6cf345b0$@reminetworks.com> <0e9117b9bb80c29d3e3a53ab64392e94@mail.gmail.com> <1392616900.46009.YahooMailNeo@web142801.mail.bf1.yahoo.com>
In-Reply-To: <1392616900.46009.YahooMailNeo@web142801.mail.bf1.yahoo.com>
Date: Sun, 16 Feb 2014 22:53:32 -0800
Organization: REMI Networks
Message-ID: <005401cf2bac$fa684360$ef38ca20$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01CF2B69.EC4B6C00"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEnOl+8JZU1HiFwOiLE96BHahHifwH2C3usAiM9j6kCwG9IxgKKA/s1m72/URA=
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.5.51.152 authed with donald.coffin@reminetworks.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/i-DBnIra_GcNEtI-aAbpK3-etYk
Cc: 'greenbutton-dev' 
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2014 06:54:10 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0055_01CF2B69.EC4B6C00
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Bill,

=20

We understand, per [RFC 6749], the granted SCOPE does not have to match =
the requested SCOPE, however, in our application a client does an =
exchange of supported Authorization Server Scopes to ensure the resource =
owner is NOT asked by the client to select a SCOPE parameter the =
Authorization Server will be forced to override.

=20

We also understand, per [RFC 6740], the SCOPE parameter is a space =
delimited list.  Therefore, the following two examples are not the same:

=20

=C2=B7         =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D04



=C2=B7         FB=3D4_5_15 IntervalDuration=3D900 =
BlockDuration=3Dmonthly HistoryLength=3D13 BR=3D04

=20

The first string represents a single SCOPE parameter, but the second =
string represents five (5) different SCOPE parameters.  Our original =
definition of the SCOPE string used commas (=E2=80=9C,=E2=80=9D) where =
the first example has semi-colons (=E2=80=9C;=E2=80=9D), however, we =
found the Spring Security OAuth 2.0 framework treats commas as blanks to =
support a Facebook SCOPE implementation.  This has recently been =
refactored to support the [RFC 6749] SCOPE definition, as it was found =
that though Facebook=E2=80=99s documentation calls for commas as SCOPE =
parameter separators, this was never implemented by Facebook.

=20

The following table defines a potential table of access tokens based on =
granted SCOPE strings:

=20


Owner

SCOPE

Grant Type

Access Token

Accessible by Access Token


Client

FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D05

Client_credentials

Token 1

NA**


RO 1

FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D04

Code

Token 2

Token 2


RO 1

FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D04

Code

Token 3

Token 3


RO 2

FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D05

Code

Token 4

Token 4


RO 3

FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D05

Code

Token 5

Token 5 & Token 1


RO 4

FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D05

Code

Token 6

Token 6 & Token 1

=20

** Token 1 is owned by the client and therefore does NOT own any =
resources for which access can be authorized.

=20

The question we are attempting to resolve is which resources can the =
owner of Token 1 access given the above table?  If the owner of Token 1 =
is allowed to access ALL resources represented by Tokens 2 =E2=80=93 6, =
then we do not need to worry about identifying which resources can be =
accessed by using Token 1.  However, if Token 1 can only be used to =
access the resources authorized by resource owner (RO) 3 and 4, then =
what is the criteria that must be used to validate that Token 1, when =
used, is able to access the requested resource?

=20

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:         =
donald.coffin@reminetworks.com

=20

From: Bill Mills [mailto:wmills_92105@yahoo.com]=20
Sent: Sunday, February 16, 2014 10:02 PM
To: Marty Burns; Donald Coffin; oauth@ietf.org
Cc: greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" =
and "client_credentials" based access tokens

=20

The scope requested does not have to match the scope granted. =20

=20

Also note that space is the scope separator per the spec, so BR=3D04 is =
not equal to =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D04 but it's your implementation of how you want to interpret =
scopes.

=20

On Sunday, February 16, 2014 5:36 PM, Marty Burns  =
wrote:

Don,

=20

Good comment. One point =E2=80=93 the authorizations covered by =
BulkId=3D04 would have Scopes of:

                        =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D04

Marty

=20

=20

From: greenbutton-dev@googlegroups.com =
[mailto:greenbutton-dev@googlegroups.com] On Behalf Of Donald Coffin
Sent: Sunday, February 16, 2014 8:14 PM
To: 'Bill Mills'; oauth@ietf.org
Cc: 'greenbutton-dev'
Subject: RE: [OAUTH-WG] Scope parameter values for "authorization_code" =
and "client_credentials" based access tokens

=20

Bill,

=20

Thanks for your reply, but I=E2=80=99m not sure you fully understand the =
situation I am attempting to resolve.

=20

For example, does an access token obtained via the =
=E2=80=9Cclient_credentials=E2=80=9D request with the following SCOPE =
parameter:

                        BulkID=3D04

allow a client to ask for resources when the individual access token =
contained the following SCOPE parameter:

                        =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13

=20

The question is what individual access token authorization should be =
covered by the =E2=80=9Cclient_credentials=E2=80=9D based access token?

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20

From: Bill Mills [mailto:wmills_92105@yahoo.com]=20
Sent: Saturday, February 15, 2014 8:30 PM
To: Donald Coffin; oauth@ietf.org
Cc: greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" =
and "client_credentials" based access tokens

=20

To tokens themselves don't differ based on how they are obtained unless =
you want them to.  No requirement to match scope to the client ID =
either, but again it's up to you.

=20

You do want to get this right.  The challenge here is that your resource =
servers have to get updated to support new scopes.  If they support =
auto-updates then it's not quite as big a deal but it's still =
non-trivial.

=20

-bill

=20

=20

=20

On Saturday, February 15, 2014 7:01 PM, Donald Coffin =
 wrote:

I would like to get the views and comments of the OAuth 2.0 IETF WG on =
the following design and implementation question:

=20

I have an application that supports both =
=E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  The =
application allows a client to obtain data on a nightly basis for =
resource owners who have granted the application access to their data.  =
The client application retrieves energy usage information and can =
potentially need to retrieve data from a few accounts to several million =
accounts.  In order to eliminate the need for the client application to =
request the data from the resource server one account at a time, the =
client application has been designed to support =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  Per [RFC 6749 =
Section 4.4 =E2=80=93 =E2=80=9CClient Credentials Grant=E2=80=9D] The =
use of the =E2=80=9Cclient_credentials=E2=80=9D based access token will =
allow the client application to obtain access to the data with a single =
request, thus significantly reducing the amount of network traffic for =
both the client and the resource server.

=20

The question the design team is struggling with is what should the Scope =
string be for the =E2=80=9Cclient_credentials=E2=80=9D based access =
token and should there be a single access token or can there be multiple =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens?

=20

The client application currently supports the following Scope =
definitions:

=20

=C2=B7         =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13

=C2=B7         =
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13

=20

There are several allowable values for the FB=3D, IntervalDuration=3D, =
BlockDuration=3D, and HistoryLength=3D values.  At the moment, there are =
only two defined Scope values, but as you can see, there could easily be =
many more potential possibilities. =20

=20

The question being discussed, is does the =
=E2=80=9Cclient_credentials=E2=80=9D access token request Scope =
parameter need to match either of the above two strings or can it be =
something altogether different?  In the event the =
=E2=80=9Cclient_credentials=E2=80=9D access token request Scope =
parameter needs to match a defined Scope string, does that mean that =
there MUST be multiple =E2=80=9Cclient_credentials=E2=80=9D based access =
tokens?

=20

Thanks in advance for helping clarify our understanding of the =
relationship between =E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20


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

--=20
You received this message because you are subscribed to the Google =
Groups "greenbutton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send =
an email to greenbutton-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

=20


------=_NextPart_000_0055_01CF2B69.EC4B6C00
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Bill,
 
We =
understand, per [RFC 6749], the granted SCOPE does not have to match the =
requested SCOPE, however, in our application a client does an exchange =
of supported Authorization Server Scopes to ensure the resource owner is =
NOT asked by the client to select a SCOPE parameter the Authorization =
Server will be forced to override.
 
We also =
understand, per [RFC 6740], the SCOPE parameter is a space delimited =
list.=C2=A0 Therefore, the following two examples are not the =
same:
 
=C2=B7         =
FB=3D4_5_15;IntervalDuration=3D90=
0;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04

=C2=B7         =
FB=3D4_5_15 =
IntervalDuration=3D900 BlockDuration=3Dmonthly HistoryLength=3D13 =
BR=3D04
 
The =
first string represents a single SCOPE parameter, but the second string =
represents five (5) different SCOPE parameters.=C2=A0 Our original =
definition of the SCOPE string used commas (=E2=80=9C,=E2=80=9D) where =
the first example has semi-colons (=E2=80=9C;=E2=80=9D), however, we =
found the Spring Security OAuth 2.0 framework treats commas as blanks to =
support a Facebook SCOPE implementation.=C2=A0 This has recently been =
refactored to support the [RFC 6749] SCOPE definition, as it was found =
that though Facebook=E2=80=99s documentation calls for commas as SCOPE =
parameter separators, this was never implemented by =
Facebook.
 
The =
following table defines a potential table of access tokens based on =
granted SCOPE strings:
 
Owner=

SCOPE=

Grant =
Type
Access =
Token
Accessible by =
Access Token
Client
=

FB=3D4_5_16;IntervalDuration=3D90=
0;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D05
Client_credentials
Token =
1
NA**
RO =
1
FB=3D4_5_15;IntervalDuration=3D90=
0;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04
Code
Token =
2
Token =
2
RO =
1
FB=3D4_5_16;IntervalDuration=3D90=
0;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04
Code
Token =
3
Token =
3
RO =
2
FB=3D4_5_15;IntervalDuration=3D90=
0;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D05
Code
Token =
4
Token =
4
RO =
3
FB=3D4_5_16;IntervalDuration=3D90=
0;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D05
Code
Token =
5
Token 5 & Token =
1
RO =
4
FB=3D4_5_16;IntervalDuration=3D90=
0;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D05
Code
Token =
6
Token 6 & Token =
1
 
** Token =
1 is owned by the client and therefore does NOT own any resources for =
which access can be authorized.
 
The =
question we are attempting to resolve is which resources can the owner =
of Token 1 access given the above table?=C2=A0 If the owner of Token 1 =
is allowed to access ALL resources represented by Tokens 2 =E2=80=93 6, =
then we do not need to worry about identifying which resources can be =
accessed by using Token 1.=C2=A0 However, if Token 1 can only be used to =
access the resources authorized by resource owner (RO) 3 and 4, then =
what is the criteria that must be used to validate that Token 1, when =
used, is able to access the requested resource?
 
 
=

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
=

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA=C2=A0 92688-3836
 
=

Phone:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 (949) 636-8571
Email:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 donald.coffin@reminetworks.com=

 
=

From:=
 =
Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: Sunday, =
February 16, 2014 10:02 PM
To: Marty Burns; Donald Coffin; =
oauth@ietf.org
Cc: greenbutton-dev
Subject: Re: =
[OAUTH-WG] Scope parameter values for "authorization_code" and =
"client_credentials" based access =
tokens
 
The scope =
requested does not have to match the scope granted. =
 
 
Also note =
that space is the scope separator per the spec, so BR=3D04 is not equal =
to FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3D=
monthly;HistoryLength=3D13;BR=3D04 but =
it's your implementation of how you want to interpret =
scopes.
 
O=
n Sunday, February 16, 2014 5:36 PM, Marty Burns <marty@hypertek.us> =
wrote:
Don,
 
Good comment. One point =E2=80=93 the authorizations covered by BulkId=3D04 would have Scopes =
of:
  &n=
bsp;           &nb=
sp;         FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3D=
monthly;HistoryLength=3D13;BR=3D04
Marty
 
 
From: greenbutton-dev@googlegroups.com [mailto:greenbutton-dev@googlegroups.com] On Behalf Of =
Donald Coffin
Sent: Sunday, February 16, 2014 8:14 =
PM
To: 'Bill Mills'; oauth@ietf.org
Cc: =
'greenbutton-dev'
Subject: RE: [OAUTH-WG] Scope parameter =
values for "authorization_code" and =
"client_credentials" based access tokens
 
Bill,
 
Thanks for =
your reply, but I=E2=80=99m not sure you fully understand the situation =
I am attempting to resolve.
 
For example, =
does an access token obtained via the =
=E2=80=9Cclient_credentials=E2=80=9D request with the following SCOPE =
parameter:

         &=
nbsp;           &n=
bsp;  BulkID=3D04

allow a client to ask for resources when =
the individual access token contained the following SCOPE =
parameter:

         &=
nbsp;           &n=
bsp;  =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13
 
The question =
is what individual access token authorization should be covered by the =
=E2=80=9Cclient_credentials=E2=80=9D based access =
token?
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
22751 El =
Prado Suite 6216
Rancho Santa =
Margarita, CA  92688-3836
 
Phone: &n=
bsp;    (949) 636-8571
Email: &n=
bsp;     donald.coffin@reminetworks.com
 
From: Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: =
Saturday, February 15, 2014 8:30 PM
To: Donald Coffin; oauth@ietf.org
Cc: =
greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values =
for "authorization_code" and "client_credentials" =
based access tokens
 
To tokens =
themselves don't differ based on how they are obtained unless you want =
them to.  No requirement to match scope to the client ID either, =
but again it's up to you.
 
You do want =
to get this right.  The challenge here is that your resource =
servers have to get updated to support new scopes.  If they support =
auto-updates then it's not quite as big a deal but it's still =
non-trivial.
 
-bill
 
 
 
On Saturday, February 15, 2014 7:01 PM, Donald Coffin <donald.coffin@reminetworks.com> =
wrote:
I would like =
to get the views and comments of the OAuth 2.0 IETF WG on the following =
design and implementation =
question:
 
I have an =
application that supports both =E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  The =
application allows a client to obtain data on a nightly basis for =
resource owners who have granted the application access to their =
data.  The client application retrieves energy usage information =
and can potentially need to retrieve data from a few accounts to several =
million accounts.  In order to eliminate the need for the client =
application to request the data from the resource server one account at =
a time, the client application has been designed to support =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  Per [RFC =
6749 Section 4.4 =E2=80=93 =E2=80=9CClient Credentials Grant=E2=80=9D] =
The use of the =E2=80=9Cclient_credentials=E2=80=9D based access token =
will allow the client application to obtain access to the data with a =
single request, thus significantly reducing the amount of network =
traffic for both the client and the resource =
server.
 
The question =
the design team is struggling with is what should the Scope string be =
for the =E2=80=9Cclient_credentials=E2=80=9D based access token and =
should there be a single access token or can there be multiple =
=E2=80=9Cclient_credentials=E2=80=9D based access =
tokens?
 
The client =
application currently supports the following Scope =
definitions:
 
=C2=B7         FB=3D4_5_15;In=
tervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13
=C2=B7         FB=3D4_5_16;In=
tervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13
 
There are =
several allowable values for the FB=3D, IntervalDuration=3D, =
BlockDuration=3D, and HistoryLength=3D values.  At the moment, =
there are only two defined Scope values, but as you can see, there could =
easily be many more potential possibilities.  =

 
The question =
being discussed, is does the =E2=80=9Cclient_credentials=E2=80=9D access =
token request Scope parameter need to match either of the above two =
strings or can it be something altogether different?  In the event =
the =E2=80=9Cclient_credentials=E2=80=9D access token request Scope =
parameter needs to match a defined Scope string, does that mean that =
there MUST be multiple =E2=80=9Cclient_credentials=E2=80=9D based access =
tokens?
 
Thanks in =
advance for helping clarify our understanding of the relationship =
between =E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access =
tokens.
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
22751 El =
Prado Suite 6216
Rancho Santa =
Margarita, CA  =
92688-3836
 
Phone: &n=
bsp;    (949) =
636-8571
Email: &n=
bsp;     donald.coffin@reminetworks.com
 

__________=
_____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
-- 
You =
received this message because you are subscribed to the Google Groups =
"greenbutton-dev" group.
To unsubscribe from this group and =
stop receiving emails from it, send an email to greenbutton-dev+unsubscribe@googlegroups.com.
Fo=
r more options, visit https://groups.google.com/groups/opt_out.
 

------=_NextPart_000_0055_01CF2B69.EC4B6C00--


From nobody Mon Feb 17 09:09:53 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500061A0246 for ; Mon, 17 Feb 2014 09:09:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiH27qXMbCwB for ; Mon, 17 Feb 2014 09:09:39 -0800 (PST)
Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) by ietfa.amsl.com (Postfix) with ESMTP id 61D001A00E6 for ; Mon, 17 Feb 2014 09:09:39 -0800 (PST)
Received: from [66.196.81.173] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 17:09:36 -0000
Received: from [98.139.212.226] by tm19.bullet.mail.bf1.yahoo.com with NNFMP;  17 Feb 2014 17:09:36 -0000
Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 17:09:36 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 671803.52286.bm@omp1035.mail.bf1.yahoo.com
Received: (qmail 93268 invoked by uid 60001); 17 Feb 2014 17:09:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392656976; bh=jn4/b+jXZTeq+t6rVfmjzYkVBMMsFxWjf8EpVmmSkzM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AGo7AVRGYesaL5bhSHpgDnhv8UBnu3b5/wsKdG0Xr5QFzD7m/Rc6HNh2BIQfAxdOZQocf9d7RVPwP2HfD1iEyhWxgTPnR5YHNdLPo9rInErKdjcGqbsMySWvl4hiOpLg6DRerZF3AXAy9qghCH1j4zIctAv/4+nuqx0dqsb0q7A=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MC3j2eq0kzFxtT7rnQ079e6C66sJGfv+l5U19TJgIFNE4fiWL/grJw/tQCOoW/r3MM4QiHsR5Gy5grAFbPto7jJMuL2XXDoptQziq2E0oJqWHeyDkUqPj7QNADqpdTeVZFvpJVs7kLcEkfjJmo0EkzRrZ7+JAWN5d2cSct/arGU=;
X-YMail-OSG: GDT6H90VM1lqZgNGw99lmAHxf6VBMv6aiHCABTyetuLoFWk ARLPnG5wn5t5G37RuVGDFjSHQCrLKcF39xHAMNzqgFaF345N5Bw4Zz9_7kIT HLR7gdHdRYI7vRWL1iapA8vM.dSSf3VDgi9.Jsz4FYfaQkhjxnjnbKVHaxyL TOp0cuHtrxbzlCzHlKHtJZXQPhuQF9K.9XLqMT_83kbr.yahDf.KCM7FEAqL USO4KQFwpK4ua.sQ7hWZ6U19GqsT9sfaBKlwH7pz8U0wLF3qNcP4c0DVPL.p VDZLA5fU0hfnh5tYvQqoccGihuzkc.CLk4DklTxZcyvWgDzk5kYQggZ.wc5W Yuiai1Lp64UEsqhaqPasAVevQMyFVrJGcWKzbsoICeDyZEBWtN4rw7JI.wvB frCIij4hXlo2Qw7AksUnmPfOIcg_iLGYe1jvF0jXlI6YX5Xl2a2r.T22CQLI 9327tzEHvfK45Gfug35zCyaMxaPQNJ14AGX8pORncTK5Moa5ub5AdTqtzLB5 Wtoh6hiGlZtvwOaA3ypFyBlgLxyEtn4BZVpTYflEbi845yVW13FHzHYuN.IM 6umnU_mK9W7J8EfW0XClki5ZAKv_yu5MjknQBVqmO0SO4T6UQ7CvkiTUTCwk iVCkFmtqKz.REyi0396FXLimau1eU98qtuPiH2ondoOoRPnk4IUundVWUmWC 9NpTdZqI-
Received: from [99.31.212.42] by web142805.mail.bf1.yahoo.com via HTTP; Mon, 17 Feb 2014 09:09:36 PST
X-Rocket-MIMEInfo: 002.001, WWVzLCB0b2tlbiAjMSB3aXRoIHRoYXQgc2NvcGUgY291bGQgb25seSBhY2Nlc3MgcmVzb3VyY2UgIzMgYW5kICM0IGluIHlvdXIgZXhhbXBsZSwgdGhlIG90aGVyIHJlc291cmNlcyBkb24ndCBhbGxvdyB0aGF0IHNjb3BlLiBUaGUgb25seSBzb2x1dGlvbiBpbiBzcGVjIGlzIHRvIGhhdmUgdGhlIG90aGVyIHJlc291cmNlIG93bmVycyBhbGxvdyBhIHNjb3BlIHRoYXQgdG9rZW4gIzEgaGFzLgoKWW91J3JlIGFwcGFyZW50bHkgb3ZlcmxvYWRpbmcgYSBidW5jaCBvZiBzdHVmZiBpbiB0aGUgc2NvcGUgdGhhdCABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.177.636
References: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com> <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com> <000e01cf2b7d$79a66c90$6cf345b0$@reminetworks.com> <0e9117b9bb80c29d3e3a53ab64392e94@mail.gmail.com> <1392616900.46009.YahooMailNeo@web142801.mail.bf1.yahoo.com> <005401cf2bac$fa684360$ef38ca20$@reminetworks.com>
Message-ID: <1392656976.93122.YahooMailNeo@web142805.mail.bf1.yahoo.com>
Date: Mon, 17 Feb 2014 09:09:36 -0800 (PST)
From: Bill Mills 
To: Donald Coffin , 'Marty Burns' , "oauth@ietf.org" 
In-Reply-To: <005401cf2bac$fa684360$ef38ca20$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1583497461-44519506-1392656976=:93122"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/m1gtByZFq1_2WOQ1IYgEblCytfQ
Cc: 'greenbutton-dev' 
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2014 17:09:44 -0000

--1583497461-44519506-1392656976=:93122
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Yes, token #1 with that scope could only access resource #3 and #4 in your =
example, the other resources don't allow that scope. The only solution in s=
pec is to have the other resource owners allow a scope that token #1 has.=
=0A=0AYou're apparently overloading a bunch of stuff in the scope that most=
 would put in the access token. =C2=A0Are you trying to give a hint to the =
client about the token?=0A=0A=0A=0AOn Sunday, February 16, 2014 10:54 PM, D=
onald Coffin  wrote:=0A =0ABill,=0A=C2=A0=
=0AWe understand, per [RFC 6749], the granted SCOPE does not have to match =
the requested SCOPE, however, in our application a client does an exchange =
of supported Authorization Server Scopes to ensure the resource owner is NO=
T asked by the client to select a SCOPE parameter the Authorization Server =
will be forced to override.=0A=C2=A0=0AWe also understand, per [RFC 6740], =
the SCOPE parameter is a space delimited list.=C2=A0 Therefore, the followi=
ng two examples are not the same:=0A=C2=A0=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=
=3Dmonthly;HistoryLength=3D13;BR=3D04=0A=0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_15 IntervalDuration=3D900 BlockDuratio=
n=3Dmonthly HistoryLength=3D13 BR=3D04=0A=C2=A0=0AThe first string represen=
ts a single SCOPE parameter, but the second string represents five (5) diff=
erent SCOPE parameters.=C2=A0 Our original definition of the SCOPE string u=
sed commas (=E2=80=9C,=E2=80=9D) where the first example has semi-colons (=
=E2=80=9C;=E2=80=9D), however, we found the Spring Security OAuth 2.0 frame=
work treats commas as blanks to support a Facebook SCOPE implementation.=C2=
=A0 This has recently been refactored to support the [RFC 6749] SCOPE defin=
ition, as it was found that though Facebook=E2=80=99s documentation calls f=
or commas as SCOPE parameter separators, this was never implemented by Face=
book.=0A=C2=A0=0AThe following table defines a potential table of access to=
kens based on granted SCOPE strings:=0A=C2=A0=0AOwner SCOPE Grant Type Acce=
ss Token Accessible by Access Token =0AClient FB=3D4_5_16;IntervalDuration=
=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D05 Client_credential=
s Token 1 NA** =0ARO 1 FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dm=
onthly;HistoryLength=3D13;BR=3D04 Code Token 2 Token 2 =0ARO 1 FB=3D4_5_16;=
IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04 C=
ode Token 3 Token 3 =0ARO 2 FB=3D4_5_15;IntervalDuration=3D900;BlockDuratio=
n=3Dmonthly;HistoryLength=3D13;BR=3D05 Code Token 4 Token 4 =0ARO 3 FB=3D4_=
5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=
=3D05 Code Token 5 Token 5 & Token 1 =0ARO 4 FB=3D4_5_16;IntervalDuration=
=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D05 Code Token 6 Toke=
n 6 & Token 1 =0A=C2=A0=0A** Token 1 is owned by the client and therefore d=
oes NOT own any resources for which access can be authorized.=0A=C2=A0=0ATh=
e question we are attempting to resolve is which resources can the owner of=
 Token 1 access given the above table?=C2=A0 If the owner of Token 1 is all=
owed to access ALL resources represented by Tokens 2 =E2=80=93 6, then we d=
o not need to worry about identifying which resources can be accessed by us=
ing Token 1.=C2=A0 However, if Token 1 can only be used to access the resou=
rces authorized by resource owner (RO) 3 and 4, then what is the criteria t=
hat must be used to validate that Token 1, when used, is able to access the=
 requested resource?=0A=C2=A0=0A=C2=A0=0ABest regards,=0ADon=0ADonald F. Co=
ffin=0AFounder/CTO=0A=C2=A0=0AREMI Networks=0A22751 El Prado Suite 6216=0AR=
ancho Santa Margarita, CA=C2=A0 92688-3836=0A=C2=A0=0APhone:=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 (949) 636-8571=0AEmail:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 donald.coffin@reminetworks.com=0A=C2=A0=0AFrom:Bill Mills [mailto:wmills_9=
2105@yahoo.com] =0ASent: Sunday, February 16, 2014 10:02 PM=0ATo: Marty Bur=
ns; Donald Coffin; oauth@ietf.org=0ACc: greenbutton-dev=0ASubject: Re: [OAU=
TH-WG] Scope parameter values for "authorization_code" and "client_credenti=
als" based access tokens=0A=C2=A0=0AThe scope requested does not have to ma=
tch the scope granted. =C2=A0=0A=C2=A0=0AAlso note that space is the scope =
separator per the spec, so BR=3D04 is not equal to FB=3D4_5_15;IntervalDura=
tion=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04 but it's your=
 implementation of how you want to interpret scopes.=0A=C2=A0=0AOn Sunday, =
February 16, 2014 5:36 PM, Marty Burns  wrote:=0ADon,=0A=
=C2=A0=0AGood comment. One point =E2=80=93 the authorizations covered by Bu=
lkId=3D04 would have Scopes of:=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=
=3Dmonthly;HistoryLength=3D13;BR=3D04=0AMarty=0A=C2=A0=0A=C2=A0=0AFrom:gree=
nbutton-dev@googlegroups.com [mailto:greenbutton-dev@googlegroups.com] On B=
ehalf Of Donald Coffin=0ASent: Sunday, February 16, 2014 8:14 PM=0ATo: 'Bil=
l Mills'; oauth@ietf.org=0ACc: 'greenbutton-dev'=0ASubject: RE: [OAUTH-WG] =
Scope parameter values for "authorization_code" and "client_credentials" ba=
sed access tokens=0A=C2=A0=0ABill,=0A=C2=A0=0AThanks for your reply, but I=
=E2=80=99m not sure you fully understand the situation I am attempting to r=
esolve.=0A=C2=A0=0AFor example, does an access token obtained via the =E2=
=80=9Cclient_credentials=E2=80=9D request with the following SCOPE paramete=
r:=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Bu=
lkID=3D04=0A=0Aallow a client to ask for resources when the individual acce=
ss token contained the following SCOPE parameter:=0A=0A=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_15;IntervalDuration=
=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13=0A=C2=A0=0AThe question i=
s what individual access token authorization should be covered by the =E2=
=80=9Cclient_credentials=E2=80=9D based access token?=0A=C2=A0=0ABest regar=
ds,=0ADon=0ADonald F. Coffin=0AFounder/CTO=0A=C2=A0=0AREMI Networks=0A22751=
 El Prado Suite 6216=0ARancho Santa Margarita, CA=C2=A0 92688-3836=0A=C2=A0=
=0APhone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571=0AEmail:=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com=0A=C2=A0=0AFrom:Bil=
l Mills [mailto:wmills_92105@yahoo.com] =0ASent: Saturday, February 15, 201=
4 8:30 PM=0ATo: Donald Coffin; oauth@ietf.org=0ACc: greenbutton-dev=0ASubje=
ct: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "cli=
ent_credentials" based access tokens=0A=C2=A0=0ATo tokens themselves don't =
differ based on how they are obtained unless you want them to. =C2=A0No req=
uirement to match scope to the client ID either, but again it's up to you.=
=0A=C2=A0=0AYou do want to get this right. =C2=A0The challenge here is that=
 your resource servers have to get updated to support new scopes. =C2=A0If =
they support auto-updates then it's not quite as big a deal but it's still =
non-trivial.=0A=C2=A0=0A-bill=0A=C2=A0=0A=C2=A0=0A=C2=A0=0AOn Saturday, Feb=
ruary 15, 2014 7:01 PM, Donald Coffin  wrot=
e:=0AI would like to get the views and comments of the OAuth 2.0 IETF WG on=
 the following design and implementation question:=0A=C2=A0=0AI have an app=
lication that supports both =E2=80=9Cauthorization_code=E2=80=9D and =E2=80=
=9Cclient_credentials=E2=80=9D based access tokens.=C2=A0 The application a=
llows a client to obtain data on a nightly basis for resource owners who ha=
ve granted the application access to their data.=C2=A0 The client applicati=
on retrieves energy usage information and can potentially need to retrieve =
data from a few accounts to several million accounts.=C2=A0 In order to eli=
minate the need for the client application to request the data from the res=
ource server one account at a time, the client application has been designe=
d to support =E2=80=9Cclient_credentials=E2=80=9D based access tokens.=C2=
=A0 Per [RFC 6749 Section 4.4 =E2=80=93 =E2=80=9CClient Credentials Grant=
=E2=80=9D] The use of the =E2=80=9Cclient_credentials=E2=80=9D based access=
 token will allow the client application to obtain access to the data with =
a single request, thus significantly reducing the amount of network traffic=
 for both the client and the resource server.=0A=C2=A0=0AThe question the d=
esign team is struggling with is what should the Scope string be for the =
=E2=80=9Cclient_credentials=E2=80=9D based access token and should there be=
 a single access token or can there be multiple =E2=80=9Cclient_credentials=
=E2=80=9D based access tokens?=0A=C2=A0=0AThe client application currently =
supports the following Scope definitions:=0A=C2=A0=0A=C2=B7=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_15;IntervalDuration=3D900;BlockD=
uration=3Dmonthly;HistoryLength=3D13=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonth=
ly;HistoryLength=3D13=0A=C2=A0=0AThere are several allowable values for the=
 FB=3D, IntervalDuration=3D, BlockDuration=3D, and HistoryLength=3D values.=
=C2=A0 At the moment, there are only two defined Scope values, but as you c=
an see, there could easily be many more potential possibilities.=C2=A0 =0A=
=C2=A0=0AThe question being discussed, is does the =E2=80=9Cclient_credenti=
als=E2=80=9D access token request Scope parameter need to match either of t=
he above two strings or can it be something altogether different?=C2=A0 In =
the event the =E2=80=9Cclient_credentials=E2=80=9D access token request Sco=
pe parameter needs to match a defined Scope string, does that mean that the=
re MUST be multiple =E2=80=9Cclient_credentials=E2=80=9D based access token=
s?=0A=C2=A0=0AThanks in advance for helping clarify our understanding of th=
e relationship between =E2=80=9Cauthorization_code=E2=80=9D and =E2=80=9Ccl=
ient_credentials=E2=80=9D based access tokens.=0A=C2=A0=0ABest regards,=0AD=
on=0ADonald F. Coffin=0AFounder/CTO=0A=C2=A0=0AREMI Networks=0A22751 El Pra=
do Suite 6216=0ARancho Santa Margarita, CA=C2=A0 92688-3836=0A=C2=A0=0APhon=
e:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571=0AEmail:=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com=0A=C2=A0=0A=0A___________=
____________________________________=0AOAuth mailing list=0AOAuth@ietf.org=
=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A-- =0AYou received this me=
ssage because you are subscribed to the Google Groups "greenbutton-dev" gro=
up.=0ATo unsubscribe from this group and stop receiving emails from it, sen=
d an email to greenbutton-dev+unsubscribe@googlegroups.com.=0AFor more opti=
ons, visit https://groups.google.com/groups/opt_out.
--1583497461-44519506-1392656976=:93122
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Yes, token #1 with that scope could only access re=
source #3 and #4 in your example, the other resources don't allow that scop=
e. The only solution in spec is to have the other resource owners allow a s=
cope that token #1 has.

You're apparently overloading a bunch of stuff in the scope that m=
ost would put in the access token.  Are you trying to give a hint to
 the client about the token?
 
 
 
 
 
  On Sunday, February 16, 2014 10:54 PM, D=
onald Coffin <donald.coffin@reminetworks.com> wrote:
    
Bill,
 
Our =
design does not include any identifiable information be passed within =
the token, as the standard being implemented (Energy Service Provider =
Interface) has the requirement that no personal identifiable information =
be exchanged between Third Parties (i.e. clients) and Data Custodians =
(i.e. authorization and resource servers).=C2=A0 Therefore, the tokens =
being generated are ubiquitous values with no direct information the =
recipient can use to access resource =
information.
 
=

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
=

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA=C2=A0 92688-3836
 
=

Phone:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 (949) 636-8571
Email:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 donald.coffin@reminetworks.com=

 
=

From:=
 =
Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: Monday, =
February 17, 2014 9:10 AM
To: Donald Coffin; 'Marty Burns'; =
oauth@ietf.org
Cc: 'greenbutton-dev'
Subject: Re: =
[OAUTH-WG] Scope parameter values for "authorization_code" and =
"client_credentials" based access =
tokens
 
Yes, token #1 =
with that scope could only access resource #3 and #4 in your example, =
the other resources don't allow that scope. The only solution in spec is =
to have the other resource owners allow a scope that token #1 =
has.
 
You're =
apparently overloading a bunch of stuff in the scope that most would put =
in the access token.  Are you trying to give a hint to the client =
about the token?
 
O=
n Sunday, February 16, 2014 10:54 PM, Donald Coffin <donald.coffin@reminetworks=
.com> wrote:
Bill,
 
We =
understand, per [RFC 6749], the granted SCOPE does not have to match the =
requested SCOPE, however, in our application a client does an exchange =
of supported Authorization Server Scopes to ensure the resource owner is =
NOT asked by the client to select a SCOPE parameter the Authorization =
Server will be forced to override.
 
We also =
understand, per [RFC 6740], the SCOPE parameter is a space delimited =
list.  Therefore, the following two examples are not the =
same:
 
=C2=B7      =
;   FB=3D4_5_15;In=
tervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04
=C2=B7      =
;   FB=3D4_5_15 =
IntervalDuration=3D900 BlockDuration=3Dmonthly HistoryLength=3D13 =
BR=3D04
 
The first =
string represents a single SCOPE parameter, but the second string =
represents five (5) different SCOPE parameters.  Our original =
definition of the SCOPE string used commas (=E2=80=9C,=E2=80=9D) where =
the first example has semi-colons (=E2=80=9C;=E2=80=9D), however, we =
found the Spring Security OAuth 2.0 framework treats commas as blanks to =
support a Facebook SCOPE implementation.  This has recently been =
refactored to support the [RFC 6749] SCOPE definition, as it was found =
that though Facebook=E2=80=99s documentation calls for commas as SCOPE =
parameter separators, this was never implemented by =
Facebook.
 
The following =
table defines a potential table of access tokens based on granted SCOPE =
strings:
 
Owner
SCOPE
Grant =
Type
Access =
Token
Accessible by Access =
Token
Client
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D05
Client_credentials
Token 1
NA**
RO 1
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D04
Code
Token 2
Token 2
RO 1
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D04
Code
Token 3
Token 3
RO 2
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D05
Code
Token 4
Token 4
RO 3
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D05
Code
Token 5
Token 5 & Token =
1
RO 4
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D05
Code
Token 6
Token 6 & Token =
1
 
** Token 1 is =
owned by the client and therefore does NOT own any resources for which =
access can be authorized.
 
The question =
we are attempting to resolve is which resources can the owner of Token 1 =
access given the above table?  If the owner of Token 1 is allowed =
to access ALL resources represented by Tokens 2 =E2=80=93 6, then we do =
not need to worry about identifying which resources can be accessed by =
using Token 1.  However, if Token 1 can only be used to access the =
resources authorized by resource owner (RO) 3 and 4, then what is the =
criteria that must be used to validate that Token 1, when used, is able =
to access the requested resource?
 
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
22751 El =
Prado Suite 6216
Rancho Santa =
Margarita, CA  92688-3836
 
Phone: &n=
bsp;    (949) 636-8571
Email: &n=
bsp;     donald.coffin@reminetworks.com
 
From: Bill Mills [mailto:wmills_92105@yahoo.com]=
 
Sent: Sunday, February 16, 2014 10:02 PM
To: Marty =
Burns; Donald Coffin; oauth@ietf.org
Cc: =
greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values =
for "authorization_code" and "client_credentials" =
based access tokens
 
The scope =
requested does not have to match the scope granted. =
 
 
Also note =
that space is the scope separator per the spec, so BR=3D04 is not equal =
to FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3D=
monthly;HistoryLength=3D13;BR=3D04 but =
it's your implementation of how you want to interpret =
scopes.
 
On Sunday, February 16, 2014 5:36 PM, Marty Burns <marty@hypertek.us> wrote:
Don,
 
Good comment. One point =E2=80=93 the authorizations covered by BulkId=3D04 would have Scopes =
of:
  &n=
bsp;           &nb=
sp;         FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3D=
monthly;HistoryLength=3D13;BR=3D04
Marty
 
 
From: greenbutton-dev@googlegroups.com [mailto:greenbutton-dev@googlegroups.com] On Behalf Of =
Donald Coffin
Sent: Sunday, February 16, 2014 8:14 =
PM
To: 'Bill Mills'; oauth@ietf.org
Cc: =
'greenbutton-dev'
Subject: RE: [OAUTH-WG] Scope parameter =
values for "authorization_code" and =
"client_credentials" based access tokens
 
Bill,
 
Thanks for =
your reply, but I=E2=80=99m not sure you fully understand the situation =
I am attempting to =
resolve.
 
For example, =
does an access token obtained via the =
=E2=80=9Cclient_credentials=E2=80=9D request with the following SCOPE =
parameter:

         &=
nbsp;           &n=
bsp;  BulkID=3D04

allow a client to ask for resources when =
the individual access token contained the following SCOPE =
parameter:

         &=
nbsp;           &n=
bsp;  =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13
 
The question =
is what individual access token authorization should be covered by the =
=E2=80=9Cclient_credentials=E2=80=9D based access =
token?
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
22751 El =
Prado Suite 6216
Rancho Santa =
Margarita, CA  =
92688-3836
 
Phone: &n=
bsp;    (949) =
636-8571
Email: &n=
bsp;     donald.coffin@reminetworks.com
 
From: Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: =
Saturday, February 15, 2014 8:30 PM
To: Donald Coffin; oauth@ietf.org
Cc: =
greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values =
for "authorization_code" and "client_credentials" =
based access tokens
 
To tokens =
themselves don't differ based on how they are obtained unless you want =
them to.  No requirement to match scope to the client ID either, =
but again it's up to =
you.
 
You do want =
to get this right.  The challenge here is that your resource =
servers have to get updated to support new scopes.  If they support =
auto-updates then it's not quite as big a deal but it's still =
non-trivial.
 
-bill
 
 
 
On Saturday, February 15, 2014 7:01 PM, Donald Coffin <donald.coffin@reminetworks.com> =
wrote:
I would like =
to get the views and comments of the OAuth 2.0 IETF WG on the following =
design and implementation =
question:
 
I have an =
application that supports both =E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  The =
application allows a client to obtain data on a nightly basis for =
resource owners who have granted the application access to their =
data.  The client application retrieves energy usage information =
and can potentially need to retrieve data from a few accounts to several =
million accounts.  In order to eliminate the need for the client =
application to request the data from the resource server one account at =
a time, the client application has been designed to support =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  Per [RFC =
6749 Section 4.4 =E2=80=93 =E2=80=9CClient Credentials Grant=E2=80=9D] =
The use of the =E2=80=9Cclient_credentials=E2=80=9D based access token =
will allow the client application to obtain access to the data with a =
single request, thus significantly reducing the amount of network =
traffic for both the client and the resource =
server.
 
The question =
the design team is struggling with is what should the Scope string be =
for the =E2=80=9Cclient_credentials=E2=80=9D based access token and =
should there be a single access token or can there be multiple =
=E2=80=9Cclient_credentials=E2=80=9D based access =
tokens?
 
The client =
application currently supports the following Scope =
definitions:
 
=C2=B7         FB=3D4_5_15;In=
tervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13
=C2=B7         FB=3D4_5_16;In=
tervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13
 
There are =
several allowable values for the FB=3D, IntervalDuration=3D, =
BlockDuration=3D, and HistoryLength=3D values.  At the moment, =
there are only two defined Scope values, but as you can see, there could =
easily be many more potential possibilities.  =

 
The question =
being discussed, is does the =E2=80=9Cclient_credentials=E2=80=9D access =
token request Scope parameter need to match either of the above two =
strings or can it be something altogether different?  In the event =
the =E2=80=9Cclient_credentials=E2=80=9D access token request Scope =
parameter needs to match a defined Scope string, does that mean that =
there MUST be multiple =E2=80=9Cclient_credentials=E2=80=9D based access =
tokens?
 
Thanks in =
advance for helping clarify our understanding of the relationship =
between =E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access =
tokens.
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
22751 El =
Prado Suite =
6216
Rancho Santa =
Margarita, CA  =
92688-3836
 
Phone: &n=
bsp;    (949) =
636-8571
Email: &n=
bsp;     donald.coffin@reminetworks.com
 

__________=
_____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<=
p class=3DMsoNormal style=3D'background:white'>-- 
You =
received this message because you are subscribed to the Google Groups =
"greenbutton-dev" group.
To unsubscribe from this group and =
stop receiving emails from it, send an email to greenbutton-dev+unsubscribe@googlegroups.com.
Fo=
r more options, visit https://groups.google.com/groups/opt_out.
 
 

------=_NextPart_000_0086_01CF2BC6.E8337880--


From nobody Mon Feb 17 10:22:52 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF1C1A0275 for ; Mon, 17 Feb 2014 10:22:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZZrWi0bp0v3 for ; Mon, 17 Feb 2014 10:22:44 -0800 (PST)
Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) by ietfa.amsl.com (Postfix) with ESMTP id A95CC1A0239 for ; Mon, 17 Feb 2014 10:22:43 -0800 (PST)
Received: from [66.196.81.174] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 18:22:40 -0000
Received: from [98.139.212.196] by tm20.bullet.mail.bf1.yahoo.com with NNFMP;  17 Feb 2014 18:22:40 -0000
Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 18:22:40 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 816603.70636.bm@omp1005.mail.bf1.yahoo.com
Received: (qmail 9893 invoked by uid 60001); 17 Feb 2014 18:22:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392661360; bh=tRR9fiiE4Ochpb5TtFVnBYvaJgfwUOah28RKWecKT+w=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Rg2my511kbHt+zsqaeHhmbwDLUb5VI9jlyqGPqzGd5Jg+q0RnPTroN/xWPGpLPWBXtOnTfaUoNVE7JKDetQX4WV9S39lh3clPn+0dN/wyYV8baUOdGNdrnBHCVd+UPJ+AJp9R+bZBkMPXnGeRsVigUe6Mj1KA5xckdKX3taQibo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wky//Qf4bVqWRnKfw7tqkWoqd/SIYcL59LJz+2Cp+p3+8e/wODsj5QLvKRMZIn8eK7dmOCCgB7o0JxCyndengm2I+Rq/l2d41p7zpddyQl5hnNgkHSZZJvOVPv56qXYKvyo9ZLPJNDJLQydi8MRsGmKUXuVCk1jxkD64+6VH4T0=;
X-YMail-OSG: DNJvlGgVM1meTiRRifq6zVUcZK.MyIAx0qtF2aMO82UaqZ_ bXEpcY4IxT0dO6ChsoWBE0ukXelWJRkCbDWgL5JFVvK_DKwWmqLwcV17cPZQ _eK8C_0_ssLGwwdyuOCtIqsB61XrCIVxHyAmWNzp.JI4MnlzL_hFUU7yUu7r DJITitv2T6.6rPhBHhJtdcNowTpe5D52QhlGIwlflxh2KhLjhrUdoXF23ICN syRIMueAPHH3jpmizB5FxCOZH2qdprx79E3vHpmvbYCfpzrxlYb.pdVg.j8W Ldjszg.nHeVikk3Jwy1aEx_HDVVu9wuAzrvreWW_dJxkr6WD1DCGLq.FJonO sugLPiwPdo3sW4huCtrP69kndAGV6uqki.3EXsTJ.de81ImGTYm10JyQP.oB Ga_AG5zx7cX0Fm4xJmuuNQcEPfWgFoVpr.9U67WnShnloqo0FzWCxOggs69L iCnvJ38.TvUN9keJt57n2pXxhpDCOkBQIyAOXdnhfTVU05LShkD71cocl5wn 2A1qj3Re4DdQ1.A8pk1WGCbRitjTd9qy7qNJHDHsyXnhFP.7Sl_M4g0BsRmP HGOs66ug9FeoaDwIL8DviZOfLszIsZ4Vetueod3TUf0qUdSuNccM_uS12MqT o5gtR_JncGkFWWtAlx8XSzsYVyEVqRsyfMF4pX9_5n6ZksSavP1PDW.KOkHd fsgES9w--
Received: from [99.31.212.42] by web142803.mail.bf1.yahoo.com via HTTP; Mon, 17 Feb 2014 10:22:40 PST
X-Rocket-MIMEInfo: 002.001, QW5kIGhvdyBleGFjdGx5IGRvZXMgdGhhdCBhcHBseSB0byBzY29wZSBuYW1lLCBleHBpcnksIG9yIG1heCBhbGxvd2FibGUgcmVjb3JkcyBmZXRjaGVkPwoKCgpPbiBNb25kYXksIEZlYnJ1YXJ5IDE3LCAyMDE0IDk6NTkgQU0sIERvbmFsZCBDb2ZmaW4gPGRvbmFsZC5jb2ZmaW5AcmVtaW5ldHdvcmtzLmNvbT4gd3JvdGU6CiAKQmlsbCwKwqAKT3VyIGRlc2lnbiBkb2VzIG5vdCBpbmNsdWRlIGFueSBpZGVudGlmaWFibGUgaW5mb3JtYXRpb24gYmUgcGFzc2VkIHdpdGhpbiB0aGUgdG9rZW4sIGFzIHRoZSBzdGEBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.177.636
References: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com> <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com> <000e01cf2b7d$79a66c90$6cf345b0$@reminetworks.com> <0e9117b9bb80c29d3e3a53ab64392e94@mail.gmail.com> <1392616900.46009.YahooMailNeo@web142801.mail.bf1.yahoo.com> <005401cf2bac$fa684360$ef38ca20$@reminetworks.com> <1392656976.93122.YahooMailNeo@web142805.mail.bf1.yahoo.com> <008501cf2c09$f6504fe0$e2f0efa0$@reminetworks.com>
Message-ID: <1392661360.99627.YahooMailNeo@web142803.mail.bf1.yahoo.com>
Date: Mon, 17 Feb 2014 10:22:40 -0800 (PST)
From: Bill Mills 
To: Donald Coffin , 'Marty Burns' , "oauth@ietf.org" 
In-Reply-To: <008501cf2c09$f6504fe0$e2f0efa0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="905790552-934378879-1392661360=:99627"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wbnUYPUwpWZfbBbPE0FK4ykTx4o
Cc: 'greenbutton-dev' 
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2014 18:22:48 -0000

--905790552-934378879-1392661360=:99627
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

And how exactly does that apply to scope name, expiry, or max allowable rec=
ords fetched?=0A=0A=0A=0AOn Monday, February 17, 2014 9:59 AM, Donald Coffi=
n  wrote:=0A =0ABill,=0A=C2=A0=0AOur design=
 does not include any identifiable information be passed within the token, =
as the standard being implemented (Energy Service Provider Interface) has t=
he requirement that no personal identifiable information be exchanged betwe=
en Third Parties (i.e. clients) and Data Custodians (i.e. authorization and=
 resource servers).=C2=A0 Therefore, the tokens being generated are ubiquit=
ous values with no direct information the recipient can use to access resou=
rce information.=0A=C2=A0=0ABest regards,=0ADon=0ADonald F. Coffin=0AFounde=
r/CTO=0A=C2=A0=0AREMI Networks=0A22751 El Prado Suite 6216=0ARancho Santa M=
argarita, CA=C2=A0 92688-3836=0A=C2=A0=0APhone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 (949) 636-8571=0AEmail:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coff=
in@reminetworks.com=0A=C2=A0=0AFrom:Bill Mills [mailto:wmills_92105@yahoo.c=
om] =0ASent: Monday, February 17, 2014 9:10 AM=0ATo: Donald Coffin; 'Marty =
Burns'; oauth@ietf.org=0ACc: 'greenbutton-dev'=0ASubject: Re: [OAUTH-WG] Sc=
ope parameter values for "authorization_code" and "client_credentials" base=
d access tokens=0A=C2=A0=0AYes, token #1 with that scope could only access =
resource #3 and #4 in your example, the other resources don't allow that sc=
ope. The only solution in spec is to have the other resource owners allow a=
 scope that token #1 has.=0A=C2=A0=0AYou're apparently overloading a bunch =
of stuff in the scope that most would put in the access token. =C2=A0Are yo=
u trying to give a hint to the client about the token?=0A=C2=A0=0AOn Sunday=
, February 16, 2014 10:54 PM, Donald Coffin  wrote:=0ABill,=0A=C2=A0=0AWe understand, per [RFC 6749], the granted SCOP=
E does not have to match the requested SCOPE, however, in our application a=
 client does an exchange of supported Authorization Server Scopes to ensure=
 the resource owner is NOT asked by the client to select a SCOPE parameter =
the Authorization Server will be forced to override.=0A=C2=A0=0AWe also und=
erstand, per [RFC 6740], the SCOPE parameter is a space delimited list.=C2=
=A0 Therefore, the following two examples are not the same:=0A=C2=A0=0A=C2=
=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0FB=3D4_5_15;IntervalDura=
tion=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04=0A=C2=B7=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0FB=3D4_5_15 IntervalDuration=
=3D900 BlockDuration=3Dmonthly HistoryLength=3D13 BR=3D04=0A=C2=A0=0AThe fi=
rst string represents a single SCOPE parameter, but the second string repre=
sents five (5) different SCOPE parameters.=C2=A0 Our original definition of=
 the SCOPE string used commas (=E2=80=9C,=E2=80=9D) where the first example=
 has semi-colons (=E2=80=9C;=E2=80=9D), however, we found the Spring Securi=
ty OAuth 2.0 framework treats commas as blanks to support a Facebook SCOPE =
implementation.=C2=A0 This has recently been refactored to support the [RFC=
 6749] SCOPE definition, as it was found that though Facebook=E2=80=99s doc=
umentation calls for commas as SCOPE parameter separators, this was never i=
mplemented by Facebook.=0A=C2=A0=0AThe following table defines a potential =
table of access tokens based on granted SCOPE strings:=0A=C2=A0=0AOwner SCO=
PE Grant Type Access Token Accessible by Access Token =0AClient FB=3D4_5_16=
;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D05 =
Client_credentials Token 1 NA** =0ARO 1 FB=3D4_5_15;IntervalDuration=3D900;=
BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04 Code Token 2 Token 2 =0A=
RO 1 FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLeng=
th=3D13;BR=3D04 Code Token 3 Token 3 =0ARO 2 FB=3D4_5_15;IntervalDuration=
=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D05 Code Token 4 Toke=
n 4 =0ARO 3 FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;Hist=
oryLength=3D13;BR=3D05 Code Token 5 Token 5 & Token 1 =0ARO 4 FB=3D4_5_16;I=
ntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D05 Co=
de Token 6 Token 6 & Token 1 =0A=C2=A0=0A** Token 1 is owned by the client =
and therefore does NOT own any resources for which access can be authorized=
.=0A=C2=A0=0AThe question we are attempting to resolve is which resources c=
an the owner of Token 1 access given the above table?=C2=A0 If the owner of=
 Token 1 is allowed to access ALL resources represented by Tokens 2 =E2=80=
=93 6, then we do not need to worry about identifying which resources can b=
e accessed by using Token 1.=C2=A0 However, if Token 1 can only be used to =
access the resources authorized by resource owner (RO) 3 and 4, then what i=
s the criteria that must be used to validate that Token 1, when used, is ab=
le to access the requested resource?=0A=C2=A0=0A=C2=A0=0ABest regards,=0ADo=
n=0ADonald F. Coffin=0AFounder/CTO=0A=C2=A0=0AREMI Networks=0A22751 El Prad=
o Suite 6216=0ARancho Santa Margarita, CA=C2=A0 92688-3836=0A=C2=A0=0APhone=
:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571=0AEmail:=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com=0A=C2=A0=0AFrom:Bill Mill=
s [mailto:wmills_92105@yahoo.com] =0ASent: Sunday, February 16, 2014 10:02 =
PM=0ATo: Marty Burns; Donald Coffin; oauth@ietf.org=0ACc: greenbutton-dev=
=0ASubject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" =
and "client_credentials" based access tokens=0A=C2=A0=0AThe scope requested=
 does not have to match the scope granted. =C2=A0=0A=C2=A0=0AAlso note that=
 space is the scope separator per the spec, so BR=3D04 is not equal to FB=
=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13=
;BR=3D04 but it's your implementation of how you want to interpret scopes.=
=0A=C2=A0=0AOn Sunday, February 16, 2014 5:36 PM, Marty Burns  wrote:=0ADon,=0A=C2=A0=0AGood comment. One point =E2=80=93 the autho=
rizations covered by BulkId=3D04 would have Scopes of:=0A=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_15;IntervalDuration=
=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04=0AMarty=0A=C2=A0=
=0A=C2=A0=0AFrom:greenbutton-dev@googlegroups.com [mailto:greenbutton-dev@g=
ooglegroups.com] On Behalf Of Donald Coffin=0ASent: Sunday, February 16, 20=
14 8:14 PM=0ATo: 'Bill Mills'; oauth@ietf.org=0ACc: 'greenbutton-dev'=0ASub=
ject: RE: [OAUTH-WG] Scope parameter values for "authorization_code" and "c=
lient_credentials" based access tokens=0A=C2=A0=0ABill,=0A=C2=A0=0AThanks f=
or your reply, but I=E2=80=99m not sure you fully understand the situation =
I am attempting to resolve.=0A=C2=A0=0AFor example, does an access token ob=
tained via the =E2=80=9Cclient_credentials=E2=80=9D request with the follow=
ing SCOPE parameter:=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 BulkID=3D04=0A=0Aallow a client to ask for resources when t=
he individual access token contained the following SCOPE parameter:=0A=0A=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_15=
;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13=0A=C2=A0=
=0AThe question is what individual access token authorization should be cov=
ered by the =E2=80=9Cclient_credentials=E2=80=9D based access token?=0A=C2=
=A0=0ABest regards,=0ADon=0ADonald F. Coffin=0AFounder/CTO=0A=C2=A0=0AREMI =
Networks=0A22751 El Prado Suite 6216=0ARancho Santa Margarita, CA=C2=A0 926=
88-3836=0A=C2=A0=0APhone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571=0AEm=
ail:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com=0A=
=C2=A0=0AFrom:Bill Mills [mailto:wmills_92105@yahoo.com] =0ASent: Saturday,=
 February 15, 2014 8:30 PM=0ATo: Donald Coffin; oauth@ietf.org=0ACc: greenb=
utton-dev=0ASubject: Re: [OAUTH-WG] Scope parameter values for "authorizati=
on_code" and "client_credentials" based access tokens=0A=C2=A0=0ATo tokens =
themselves don't differ based on how they are obtained unless you want them=
 to. =C2=A0No requirement to match scope to the client ID either, but again=
 it's up to you.=0A=C2=A0=0AYou do want to get this right. =C2=A0The challe=
nge here is that your resource servers have to get updated to support new s=
copes. =C2=A0If they support auto-updates then it's not quite as big a deal=
 but it's still non-trivial.=0A=C2=A0=0A-bill=0A=C2=A0=0A=C2=A0=0A=C2=A0=0A=
On Saturday, February 15, 2014 7:01 PM, Donald Coffin  wrote:=0AI would like to get the views and comments of the OAut=
h 2.0 IETF WG on the following design and implementation question:=0A=C2=A0=
=0AI have an application that supports both =E2=80=9Cauthorization_code=E2=
=80=9D and =E2=80=9Cclient_credentials=E2=80=9D based access tokens.=C2=A0 =
The application allows a client to obtain data on a nightly basis for resou=
rce owners who have granted the application access to their data.=C2=A0 The=
 client application retrieves energy usage information and can potentially =
need to retrieve data from a few accounts to several million accounts.=C2=
=A0 In order to eliminate the need for the client application to request th=
e data from the resource server one account at a time, the client applicati=
on has been designed to support =E2=80=9Cclient_credentials=E2=80=9D based =
access tokens.=C2=A0 Per [RFC 6749 Section 4.4 =E2=80=93 =E2=80=9CClient Cr=
edentials Grant=E2=80=9D] The use of the =E2=80=9Cclient_credentials=E2=80=
=9D based access token will allow the client application to obtain access t=
o the data with a single request, thus significantly reducing the amount of=
 network traffic for both the client and the resource server.=0A=C2=A0=0ATh=
e question the design team is struggling with is what should the Scope stri=
ng be for the =E2=80=9Cclient_credentials=E2=80=9D based access token and s=
hould there be a single access token or can there be multiple =E2=80=9Cclie=
nt_credentials=E2=80=9D based access tokens?=0A=C2=A0=0AThe client applicat=
ion currently supports the following Scope definitions:=0A=C2=A0=0A=C2=B7=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_15;IntervalDurati=
on=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13=0A=C2=B7=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FB=3D4_5_16;IntervalDuration=3D900;BlockD=
uration=3Dmonthly;HistoryLength=3D13=0A=C2=A0=0AThere are several allowable=
 values for the FB=3D, IntervalDuration=3D, BlockDuration=3D, and HistoryLe=
ngth=3D values.=C2=A0 At the moment, there are only two defined Scope value=
s, but as you can see, there could easily be many more potential possibilit=
ies.=C2=A0 =0A=C2=A0=0AThe question being discussed, is does the =E2=80=9Cc=
lient_credentials=E2=80=9D access token request Scope parameter need to mat=
ch either of the above two strings or can it be something altogether differ=
ent?=C2=A0 In the event the =E2=80=9Cclient_credentials=E2=80=9D access tok=
en request Scope parameter needs to match a defined Scope string, does that=
 mean that there MUST be multiple =E2=80=9Cclient_credentials=E2=80=9D base=
d access tokens?=0A=C2=A0=0AThanks in advance for helping clarify our under=
standing of the relationship between =E2=80=9Cauthorization_code=E2=80=9D a=
nd =E2=80=9Cclient_credentials=E2=80=9D based access tokens.=0A=C2=A0=0ABes=
t regards,=0ADon=0ADonald F. Coffin=0AFounder/CTO=0A=C2=A0=0AREMI Networks=
=0A22751 El Prado Suite 6216=0ARancho Santa Margarita, CA=C2=A0 92688-3836=
=0A=C2=A0=0APhone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571=0AEmail:=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com=0A=C2=A0=
=0A=0A_______________________________________________=0AOAuth mailing list=
=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A-- =0AYou=
 received this message because you are subscribed to the Google Groups "gre=
enbutton-dev" group.=0ATo unsubscribe from this group and stop receiving em=
ails from it, send an email to greenbutton-dev+unsubscribe@googlegroups.com=
.=0AFor more options, visit https://groups.google.com/groups/opt_out.
--905790552-934378879-1392661360=:99627
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


And how exactly does that apply to scope name, exp=
iry, or max allowable records fetched?
 
 
 
 
 
  On Monday, February 17, 2014 9:=
59 AM, Donald Coffin <donald.coffin@reminetworks.com> wrote:
  
  
#yiv2978925844 #yiv2978925844 --=0A =0A _filtered #yiv2978925844 {font-fam=
ily:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;}=0A _filtered #yiv2978925844 {=
panose-1:2 4 5 3 5 4 6 3 2 4;}=0A _filtered #yiv2978925844 {font-family:Cam=
bria;panose-1:2 4 5 3 5 4 6 3 2 4;}=0A _filtered #yiv2978925844 {font-famil=
y:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}=0A _filtered #yiv2978925844 {font=
-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}=0A _filtered #yiv2978925844 =
{panose-1:3 6 8 2 4 4 6 7 3 4;}=0A#yiv2978925844  =0A#yiv2978925844 p.yiv29=
78925844MsoNormal, #yiv2978925844 li.yiv2978925844MsoNormal, #yiv2978925844=
 div.yiv2978925844MsoNormal=0A=09{margin:0in;margin-bottom:.0001pt;font-siz=
e:12.0pt;}=0A#yiv2978925844 a:link, #yiv2978925844 span.yiv2978925844MsoHyp=
erlink=0A=09{color:blue;text-decoration:underline;}=0A#yiv2978925844 a:visi=
ted, #yiv2978925844 span.yiv2978925844MsoHyperlinkFollowed=0A=09{color:purp=
le;text-decoration:underline;}=0A#yiv2978925844 p=0A=09{margin-right:0in;ma=
rgin-left:0in;font-size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844MsoAcetate=
, #yiv2978925844 li.yiv2978925844MsoAcetate, #yiv2978925844 div.yiv29789258=
44MsoAcetate=0A=09{margin:0in;margin-bottom:.0001pt;font-size:8.0pt;}=0A#yi=
v2978925844 p.yiv2978925844msoacetate, #yiv2978925844 li.yiv2978925844msoac=
etate, #yiv2978925844 div.yiv2978925844msoacetate=0A=09{margin-right:0in;ma=
rgin-left:0in;font-size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844msolistpar=
agraph, #yiv2978925844 li.yiv2978925844msolistparagraph, #yiv2978925844 div=
.yiv2978925844msolistparagraph=0A=09{margin-right:0in;margin-left:0in;font-=
size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844msonormal, #yiv2978925844 li.=
yiv2978925844msonormal, #yiv2978925844 div.yiv2978925844msonormal=0A=09{mar=
gin-right:0in;margin-left:0in;font-size:12.0pt;}=0A#yiv2978925844 p.yiv2978=
925844msochpdefault, #yiv2978925844 li.yiv2978925844msochpdefault, #yiv2978=
925844 div.yiv2978925844msochpdefault=0A=09{margin-right:0in;margin-left:0i=
n;font-size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844msonormal1, #yiv297892=
5844 li.yiv2978925844msonormal1, #yiv2978925844 div.yiv2978925844msonormal1=
=0A=09{margin-right:0in;margin-left:0in;font-size:12.0pt;}=0A#yiv2978925844=
 p.yiv2978925844msolistparagraph1, #yiv2978925844 li.yiv2978925844msolistpa=
ragraph1, #yiv2978925844 div.yiv2978925844msolistparagraph1=0A=09{margin-ri=
ght:0in;margin-left:0in;font-size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844=
msochpdefault1, #yiv2978925844 li.yiv2978925844msochpdefault1, #yiv29789258=
44 div.yiv2978925844msochpdefault1=0A=09{margin-right:0in;margin-left:0in;f=
ont-size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844msonormal2, #yiv297892584=
4 li.yiv2978925844msonormal2, #yiv2978925844 div.yiv2978925844msonormal2=0A=
=09{margin-right:0in;margin-left:0in;font-size:12.0pt;}=0A#yiv2978925844 p.=
yiv2978925844msoacetate1, #yiv2978925844 li.yiv2978925844msoacetate1, #yiv2=
978925844 div.yiv2978925844msoacetate1=0A=09{margin-right:0in;margin-left:0=
in;font-size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844msolistparagraph2, #y=
iv2978925844 li.yiv2978925844msolistparagraph2, #yiv2978925844 div.yiv29789=
25844msolistparagraph2=0A=09{margin-right:0in;margin-left:0in;font-size:12.=
0pt;}=0A#yiv2978925844 p.yiv2978925844msonormal3, #yiv2978925844 li.yiv2978=
925844msonormal3, #yiv2978925844 div.yiv2978925844msonormal3=0A=09{margin-r=
ight:0in;margin-left:0in;font-size:12.0pt;}=0A#yiv2978925844 p.yiv297892584=
4msochpdefault2, #yiv2978925844 li.yiv2978925844msochpdefault2, #yiv2978925=
844 div.yiv2978925844msochpdefault2=0A=09{margin-right:0in;margin-left:0in;=
font-size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844msonormal11, #yiv2978925=
844 li.yiv2978925844msonormal11, #yiv2978925844 div.yiv2978925844msonormal1=
1=0A=09{margin-right:0in;margin-left:0in;font-size:12.0pt;}=0A#yiv297892584=
4 p.yiv2978925844msolistparagraph11, #yiv2978925844 li.yiv2978925844msolist=
paragraph11, #yiv2978925844 div.yiv2978925844msolistparagraph11=0A=09{margi=
n-right:0in;margin-left:0in;font-size:12.0pt;}=0A#yiv2978925844 p.yiv297892=
5844msochpdefault11, #yiv2978925844 li.yiv2978925844msochpdefault11, #yiv29=
78925844 div.yiv2978925844msochpdefault11=0A=09{margin-right:0in;margin-lef=
t:0in;font-size:12.0pt;}=0A#yiv2978925844 span.yiv2978925844msohyperlink=0A=
=09{}=0A#yiv2978925844 span.yiv2978925844msohyperlinkfollowed=0A=09{}=0A#yi=
v2978925844 span.yiv2978925844msohyperlink2=0A=09{}=0A#yiv2978925844 span.y=
iv2978925844msohyperlinkfollowed2=0A=09{}=0A#yiv2978925844 span.yiv29789258=
44msohyperlink11=0A=09{}=0A#yiv2978925844 span.yiv2978925844msohyperlinkfol=
lowed11=0A=09{}=0A#yiv2978925844 span.yiv2978925844emailstyle1711=0A=09{}=
=0A#yiv2978925844 span.yiv2978925844emailstyle291=0A=09{}=0A#yiv2978925844 =
span.yiv2978925844emailstyle311=0A=09{}=0A#yiv2978925844 span.yiv2978925844=
emailstyle51=0A=09{}=0A#yiv2978925844 p.yiv2978925844msonormal4, #yiv297892=
5844 li.yiv2978925844msonormal4, #yiv2978925844 div.yiv2978925844msonormal4=
=0A=09{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}=0A#yiv2978925844=
 span.yiv2978925844msohyperlink1=0A=09{color:blue;text-decoration:underline=
;}=0A#yiv2978925844 span.yiv2978925844msohyperlinkfollowed1=0A=09{color:pur=
ple;text-decoration:underline;}=0A#yiv2978925844 p.yiv2978925844msoacetate2=
, #yiv2978925844 li.yiv2978925844msoacetate2, #yiv2978925844 div.yiv2978925=
844msoacetate2=0A=09{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}=0A=
#yiv2978925844 p.yiv2978925844msolistparagraph3, #yiv2978925844 li.yiv29789=
25844msolistparagraph3, #yiv2978925844 div.yiv2978925844msolistparagraph3=
=0A=09{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}=0A#yiv2978925844=
 p.yiv2978925844msonormal5, #yiv2978925844 li.yiv2978925844msonormal5, #yiv=
2978925844 div.yiv2978925844msonormal5=0A=09{margin-right:0in;margin-left:0=
in;font-size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844msochpdefault3, #yiv2=
978925844 li.yiv2978925844msochpdefault3, #yiv2978925844 div.yiv2978925844m=
sochpdefault3=0A=09{margin-right:0in;margin-left:0in;font-size:12.0pt;}=0A#=
yiv2978925844 p.yiv2978925844msonormal12, #yiv2978925844 li.yiv2978925844ms=
onormal12, #yiv2978925844 div.yiv2978925844msonormal12=0A=09{margin-right:0=
in;margin-left:0in;font-size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844msoli=
stparagraph12, #yiv2978925844 li.yiv2978925844msolistparagraph12, #yiv29789=
25844 div.yiv2978925844msolistparagraph12=0A=09{margin-right:0in;margin-lef=
t:0in;font-size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844msochpdefault12, #=
yiv2978925844 li.yiv2978925844msochpdefault12, #yiv2978925844 div.yiv297892=
5844msochpdefault12=0A=09{margin-right:0in;margin-left:0in;font-size:12.0pt=
;}=0A#yiv2978925844 p.yiv2978925844msonormal21, #yiv2978925844 li.yiv297892=
5844msonormal21, #yiv2978925844 div.yiv2978925844msonormal21=0A=09{margin:0=
in;margin-bottom:.0001pt;font-size:12.0pt;}=0A#yiv2978925844 span.yiv297892=
5844msohyperlink21=0A=09{color:blue;text-decoration:underline;}=0A#yiv29789=
25844 span.yiv2978925844msohyperlinkfollowed21=0A=09{color:purple;text-deco=
ration:underline;}=0A#yiv2978925844 p.yiv2978925844msoacetate11, #yiv297892=
5844 li.yiv2978925844msoacetate11, #yiv2978925844 div.yiv2978925844msoaceta=
te11=0A=09{margin:0in;margin-bottom:.0001pt;font-size:8.0pt;}=0A#yiv2978925=
844 p.yiv2978925844msolistparagraph21, #yiv2978925844 li.yiv2978925844msoli=
stparagraph21, #yiv2978925844 div.yiv2978925844msolistparagraph21=0A=09{mar=
gin-right:0in;margin-left:0in;font-size:12.0pt;}=0A#yiv2978925844 p.yiv2978=
925844msonormal31, #yiv2978925844 li.yiv2978925844msonormal31, #yiv29789258=
44 div.yiv2978925844msonormal31=0A=09{margin-right:0in;margin-left:0in;font=
-size:12.0pt;}=0A#yiv2978925844 p.yiv2978925844msochpdefault21, #yiv2978925=
844 li.yiv2978925844msochpdefault21, #yiv2978925844 div.yiv2978925844msochp=
default21=0A=09{margin-right:0in;margin-left:0in;font-size:12.0pt;}=0A#yiv2=
978925844 p.yiv2978925844msonormal111, #yiv2978925844 li.yiv2978925844msono=
rmal111, #yiv2978925844 div.yiv2978925844msonormal111=0A=09{margin:0in;marg=
in-bottom:.0001pt;font-size:11.0pt;}=0A#yiv2978925844 p.yiv2978925844msolis=
tparagraph111, #yiv2978925844 li.yiv2978925844msolistparagraph111, #yiv2978=
925844 div.yiv2978925844msolistparagraph111=0A=09{margin-top:0in;margin-rig=
ht:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:1=
1.0pt;}=0A#yiv2978925844 p.yiv2978925844msochpdefault111, #yiv2978925844 li=
.yiv2978925844msochpdefault111, #yiv2978925844 div.yiv2978925844msochpdefau=
lt111=0A=09{margin-right:0in;margin-left:0in;font-size:12.0pt;}=0A#yiv29789=
25844 span.yiv2978925844msohyperlink111=0A=09{color:blue;text-decoration:un=
derline;}=0A#yiv2978925844 span.yiv2978925844msohyperlinkfollowed111=0A=09{=
color:purple;text-decoration:underline;}=0A#yiv2978925844 span.yiv297892584=
4emailstyle17111=0A=09{color:windowtext;}=0A#yiv2978925844 span.yiv29789258=
44emailstyle2911=0A=09{color:windowtext;font-weight:normal;font-style:norma=
l;}=0A#yiv2978925844 span.yiv2978925844emailstyle3111=0A=09{color:#1F497D;f=
ont-weight:normal;font-style:normal;}=0A#yiv2978925844 span.yiv2978925844em=
ailstyle511=0A=09{color:windowtext;font-weight:normal;font-style:normal;}=
=0A#yiv2978925844 span.yiv2978925844grame=0A=09{}=0A#yiv2978925844 span.yiv=
2978925844spelle=0A=09{}=0A#yiv2978925844 span.yiv2978925844BalloonTextChar=
=0A=09{}=0A#yiv2978925844 span.yiv2978925844EmailStyle73=0A=09{color:window=
text;font-weight:normal;font-style:normal;}=0A#yiv2978925844 .yiv2978925844=
MsoChpDefault=0A=09{font-size:10.0pt;}=0A _filtered #yiv2978925844 {margin:=
1.0in 1.0in 1.0in 1.0in;}=0A#yiv2978925844 div.yiv2978925844WordSection1=0A=
=09{}=0A#yiv2978925844 
Bill,
=

  
=

Our design does not =
include any identifiable information be passed within the token, as the sta=
ndard being implemented (Energy Service Provider Interface) has the require=
ment that no personal identifiable information be exchanged between Third P=
arties (i.e. clients) and Data Custodians (i.e. authorization and resource =
servers).  Therefore, the tokens being generated are ubiquitous values=
 with no direct information the recipient can use to access resource inform=
ation.
 =
 
Best regards,
Don
Donald F. Coffin
Founder/CTO
  
REMI Networks
22751 El Prado Suite 6216
Rancho Santa=
 Margarita, CA  92688-3836
  
Phone:      (949) 636-8571=

Email:&=
nbsp;      donald.coffin@reminetworks.com
  
From: Bill =
Mills [mailto:wmills_92105@yahoo.com] 
Sent: Monda=
y, February 17, 2014 9:10 AM
To: Donald Coffin; 'M=
arty Burns'; oauth@ietf.org
Cc: 'greenbutton-dev'<=
br clear=3D"none">Subject: Re: [OAUTH-WG] Scope parameter values for=
 "authorization_code" and "client_credentials" based access tokens
  
Yes, token #1
 with that scope could only access resource #3 and #4 in your example, the =
other resources don't allow that scope. The only solution in spec is to hav=
e the other resource owners allow a scope that token #1 has.
  
=
You're apparently overloading a bunch of stuff in the scope that most would=
 put in the access token.  Are you trying to give a hint to the client=
 about the token?
 &nbs=
p;
On Sunday, Februar=
y 16, 2014 10:54 PM, Donald Coffin <donald.coffin@reminetworks.=
com> wrote:
Bill,
 
We understand, per [RFC 6749], =
the granted SCOPE does not have to match the requested SCOPE, however, in o=
ur application a client does an exchange of supported Authorization Server =
Scopes to ensure the resource owner is NOT asked by the client to select a =
SCOPE parameter the Authorization Server will be forced to override.=

 
We also understand, per [RFC =
6740], the SCOPE parameter is a space delimited list.  Therefore, the =
following two examples are not the same:
&n=
bsp;
=C2=B7        =
;=
 FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=
=3Dmonthly;HistoryLength=3D13;BR=3D04
=C2=B7      =
;   FB=3D4_5_15 IntervalDuration=3D900 Blo=
ckDuration=3Dmonthly HistoryLength=3D13 BR=3D04
 
The first string represents a s=
ingle SCOPE parameter, but the second string represents five (5) different =
SCOPE parameters.  Our original definition of the SCOPE string used co=
mmas (=E2=80=9C,=E2=80=9D) where the first example has semi-colons (=E2=80=
=9C;=E2=80=9D), however, we found the Spring Security OAuth 2.0 framework t=
reats commas as blanks to support a Facebook SCOPE implementation.  Th=
is has recently been refactored to support the [RFC 6749] SCOPE definition,=
 as it was found that though Facebook=E2=80=99s
 documentation calls for commas as SCOPE parameter separators, this was nev=
er implemented by Facebook.
 
The following table defines a potential table of acce=
ss tokens based on granted SCOPE strings:
&n=
bsp;
Owner
SCOPE
<=
span style=3D"font-size:14.0pt;">Grant Type
Access =
Token
Accessible by=
 Access Token
Client
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;History=
Length=3D13;BR=3D05
Client_credentials
Token 1
NA**
RO 1
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLen=
gth=3D13;BR=3D04
Code=

Token 2
Token 2
RO 1
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=
=3D13;BR=3D04
Code
Token 3
Token 3=

RO 2
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly=
;HistoryLength=3D13;BR=3D05
Code
Token 4
Token 4
RO 3
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly=
;HistoryLength=3D13;BR=3D05
Code
Token 5
Token 5 & Token 1
RO 4
FB=3D4_5_16;IntervalDu=
ration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D05
=
=

Code
Token 6
Token 6 & Token 1
 
** Token 1 is owned by the client and therefore does NOT own any reso=
urces for which access can be authorized.
&n=
bsp;
The
 question we are attempting to resolve is which resources can the owner of =
Token 1 access given the above table?  If the owner of Token 1 is allo=
wed to access ALL resources represented by Tokens 2 =E2=80=93 6, then we do=
 not need to worry about identifying which resources can be accessed by usi=
ng Token 1.  However, if Token 1 can only be used to access the resour=
ces authorized by resource owner (RO) 3 and 4, then what is the criteria th=
at must be used to validate that Token 1, when used, is able to access the =
requested resource?
 
 
Best regards,
Don
=

Donald F. Coffin
Founder/CTO
 
REMI Net=
works
22751 El Prado Suite 6216
=

Rancho Santa Margarita, CA  92688-3836
=

 
Phone:    =
;  (949) 636-8571
Email:  &nb=
sp;    donald.coffin@reminetworks.com
=

 
From: Bill Mills [mailto:wmills_92105@yahoo.com] =

Sent: Sunday, February 16, 2014 10:02 PM
To: Marty Burns; Donald Coffin; oauth@ietf.org
Cc: greenbutt=
on-dev
Subject: Re: [OAUTH-WG] Scope parameter val=
ues for "authorization_code" and "client_credentials" based access tokens
 
The scope requested does not have t=
o match the scope granted.  
 
Also note that=
 space is the scope separator per the spec, so BR=3D04 is not equal to FB=
=3D4_5_15;IntervalDuration=3D900;=
BlockDuration=3Dmonthly;HistoryLength=3D1=
3;BR=3D04 but it's your implementation of how you want to interpret scopes.=

<=
div class=3D"yiv2978925844MsoNormal" style=3D"background:white;"> 
On Sunday, February 16, 2014 5:36 PM, Marty Burns <marty@hypertek.us> wrote:
Don,
 
Good comment. One point =E2=80=93 the authorizations co=
vered by BulkId=3D04 would have =
Scopes of:
       &nb=
sp;            =
    FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=
=3Dmonthly;HistoryLength=3D13;BR=3D04
Marty
 
 
From: greenbutton-dev@googlegroups.c=
om [mailto:greenbutton-dev@googlegroups.com] On Behalf Of Donald Coffin
Sent: Sunday, February 16, 2014 8:=
14 PM
To: 'Bill Mills'; oauth@ietf.org
Cc: 'greenbut=
ton-dev'
Subject: RE: [OAUTH-WG] Scope parameter v=
alues for "authorization_code" and "client_credentials" based access tokens=

 
Bill,
 
=

Thanks for your reply, but I=E2=80=99m not sure you fully understan=
d the situation I am attempting to resolve.
 
=

For example, does an access token obtained via the =E2=80=9Ccl=
ient_credentials=E2=80=9D request with the following SCOPE parameter:

          =
;            &n=
bsp; BulkID=3D04

allow a client to ask=
 for resources when the individual access token contained the following SCO=
PE parameter:

    =
            &nb=
sp;       FB=3D4_5_15;IntervalDuration=3D900;=
BlockDuration=3Dmonthly;HistoryLength=3D13
 
The question is =
what individual access token authorization should be covered by the =E2=80=
=9Cclient_credentials=E2=80=9D based access token?
=

 
Best regards,
Don
Donald F. Coffin
Founder/CTO
<=
span style=3D""> 
REMI Netwo=
rks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  92688-3836
<=
div>
=
 
Phone:&nb=
sp;     (949) 636-8571
 <=
/div>
From: Bill Mills [mailto:wmills_92105@yahoo.com] 
S=
ent: Saturday, February 15, 2014 8:30 PM
To: D=
onald Coffin; oauth@ietf.org=

Cc: greenbutton-dev
Subject:=
 Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "cl=
ient_credentials" based access tokens
<=
/div>
 
To=
 tokens themselves don't differ based on how they are obtained unless you w=
ant them to.  No requirement to match scope to the client ID either, b=
ut again it's up to you.
 
You do want =
to get this right.  The challenge here is that your resource servers h=
ave to get updated to support new scopes.  If they support auto-update=
s then it's not quite as big a deal but it's still non-trivial.
 
-b=
ill
 
 
 
On Saturda=
y, February 15, 2014 7:01 PM, Donald Coffin <donald.coffin@reminetwork=
s.com> wrote:
<=
div>
I would like to get the views and comments =
of the OAuth 2.0 IETF WG on the following design and implementation questio=
n:
 
=

I have an application that support=
s both =E2=80=9Cauthorization_code=E2=80=9D and =E2=80=9Cclient_credentials=
=E2=80=9D based access tokens.  The application allows a client to obt=
ain data on a nightly basis for resource owners who have granted the applic=
ation access to their data.  The client application retrieves energy u=
sage information and can potentially need to retrieve data from a few accou=
nts to several million accounts. 
 In order to eliminate the need for the client application to request the d=
ata from the resource server one account at a time, the client application =
has been designed to support =E2=80=9Cclient_credentials=E2=80=9D based acc=
ess tokens.  Per [RFC 6749 Section 4.4 =E2=80=93 =E2=80=9CClient Crede=
ntials Grant=E2=80=9D] The use of the =E2=80=9Cclient_credentials=E2=80=9D =
based access token will allow the client application to obtain access to th=
e data with a single request, thus significantly reducing the amount of net=
work traffic for both the client and the resource server.
 
The question the design team is struggling with is wha=
t should the Scope string be for the =E2=80=9Cclient_credentials=E2=80=9D b=
ased access token and should there be a single access token
 or can there be multiple =E2=80=9Cclient_credentials=E2=80=9D based access=
 tokens?
 =

The client application curre=
ntly supports the following Scope definitions:
 
=C2=B7         FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=
=3D13
=C2=B7   &nbs=
p;     FB=3D4_5_16;IntervalDura=
tion=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13
 
<=
div>
=
There are several allowable values for the FB=3D, Interval=
Duration=3D, BlockDuration=3D, and HistoryLength=3D values.  At the mo=
ment, there are only two defined Scope values, but as you can see, there co=
uld easily be many more potential possibilities.  
<=
/div>
 
Th=
e question being discussed, is does the =E2=80=9Cclient_credentials=E2=80=
=9D access token request Scope parameter need to match either of the above =
two strings or can it be something altogether different?  In the event=
 the =E2=80=9Cclient_credentials=E2=80=9D access token request Scope parame=
ter needs to match a defined Scope string, does that mean that there MUST b=
e multiple =E2=80=9Cclient_credentials=E2=80=9D based access tokens?=

 
Thanks in advance for helping clarify our u=
nderstanding of the relationship between =E2=80=9Cauthorization_code=E2=80=
=9D and =E2=80=9Cclient_credentials=E2=80=9D based access
 tokens.
 =

Best regards,
Don
Donald F. Co=
ffin
Founder/CTO
 
REMI
 Networks
22751 El Pra=
do Suite 6216
Rancho S=
anta Margarita, CA  92688-3836
 
P=
hone:      (949) 636-8571
=

 <=
/div>
<=
span style=3D"">
________________________________________=
_______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
-- 
You received this
 message because you are subscribed to the Google Groups "greenbutton-dev" =
group.
To unsubscribe from this group and stop receiving =
emails from it, send an email to greenbutton-de=
v+unsubscribe@googlegroups.com.
For more options, vis=
it https://groups.google.com/groups/opt_out=
.
 
=


  
<=
br>
  
 
  
 

--905790552-934378879-1392661360=:99627--


From nobody Mon Feb 17 10:54:22 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D911A0275 for ; Mon, 17 Feb 2014 10:54:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEhBBDFl2MGp for ; Mon, 17 Feb 2014 10:54:16 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 23A511A01D6 for ; Mon, 17 Feb 2014 10:54:16 -0800 (PST)
Received: (qmail 28087 invoked by uid 0); 17 Feb 2014 18:54:07 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 17 Feb 2014 18:54:07 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw3 with  id Tdu31n0062is6CS01du6AS; Mon, 17 Feb 2014 18:54:06 -0700
X-Authority-Analysis: v=2.1 cv=RodWckWK c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=d-K1uXnm4cMA:10 a=8dE94GJacnkA:10 a=UGkfVyPCAAAA:8 a=S71PjDr2FGoA:10 a=rE68L1KyjUoA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=CjxXgO3LAAAA:8 a=48vgC7mUAAAA:8 a=4RBUngkUAAAA:8 a=1XWaLZrsAAAA:8 a=gixh_PhHDU-PWTW1PUcA:9 a=MjkDcUoFo5yP9Q5e:21 a=RWVy7Aawaag9Ay2c:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=c4S9Whzb7AQA:10 a=0qEjrYlnuRwA:10 a=rC2wZJ5BpNYA:10 a=lZB815dzVvQA:10 a=nsSs_srodhIA:10 a=Bm6qEjDGwGEA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=6C7RrwKVwbBGpfTs:21 a=y9_PSBz55XQQh9lx:21 a=39qFx1uVXpT0N5Ag:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=JMCLvN/rKGrtPXc/xC4TsRuSfPwvKtl8H08uHWygb/8=;  b=YlQQgcaoNr6sdtDR5edFrQaD+UnfaZTJZQspYcx3f6NVWbbzfLirQWIMsMsfHEbzhpdkqqD2jXPzAiknsVp/HZNTJ4UlKsOFvs9gGtGr8EGe9Iwpi1nxpzRi9gzFY4BF;
Received: from [68.5.51.152] (port=50173 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1WFTKO-0001Xp-CC; Mon, 17 Feb 2014 11:54:04 -0700
From: "Donald Coffin" 
To: "'Bill Mills'" , "'Marty Burns'" , 
References: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com> <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com> <000e01cf2b7d$79a66c90$6cf345b0$@reminetworks.com> <0e9117b9bb80c29d3e3a53ab64392e94@mail.gmail.com> <1392616900.46009.YahooMailNeo@web142801.mail.bf1.yahoo.com> <005401cf2bac$fa684360$ef38ca20$@reminetworks.com> <1392656976.93122.YahooMailNeo@web142805.mail.bf1.yahoo.com> <008501cf2c09$f6504fe0$e2f0efa0$@reminetworks.com> <1392661360.99627.YahooMailNeo@web142803.mail.bf1.yahoo.com>
In-Reply-To: <1392661360.99627.YahooMailNeo@web142803.mail.bf1.yahoo.com>
Date: Mon, 17 Feb 2014 10:53:31 -0800
Organization: REMI Networks
Message-ID: <00a701cf2c11$8f2c1210$ad843630$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01CF2BCE.811184A0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEnOl+8JZU1HiFwOiLE96BHahHifwH2C3usAiM9j6kCwG9IxgKKA/s1AbcqxNsBkstolgKirZe+AXuQexCbg03acA==
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.5.51.152 authed with donald.coffin@reminetworks.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/eKXzy2HMWIWttwypGncapS6bzDo
Cc: 'greenbutton-dev' 
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2014 18:54:20 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00A8_01CF2BCE.811184A0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Bill,

=20

Expiration of the access token is defined by the authorization server =
and returned to the client as part of the access token JSON response.  =
I=E2=80=99m not sure I understand the =E2=80=9Cscope name=E2=80=9D and =
=E2=80=9Cmax allowable records=E2=80=9D portion of your question.  Can =
you clarify?

=20

Some of the group believe the contents of the SCOPE parameter is a =
suggestion to the client of the data available from the resource server =
and NOT a limiting value of the data a client may access.  Can you =
comment on your interpretation of the meaning of the SCOPE parameter?

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:         =
donald.coffin@reminetworks.com

=20

From: Bill Mills [mailto:wmills_92105@yahoo.com]=20
Sent: Monday, February 17, 2014 10:23 AM
To: Donald Coffin; 'Marty Burns'; oauth@ietf.org
Cc: 'greenbutton-dev'
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" =
and "client_credentials" based access tokens

=20

And how exactly does that apply to scope name, expiry, or max allowable =
records fetched?

=20

On Monday, February 17, 2014 9:59 AM, Donald Coffin =
 wrote:

Bill,

=20

Our design does not include any identifiable information be passed =
within the token, as the standard being implemented (Energy Service =
Provider Interface) has the requirement that no personal identifiable =
information be exchanged between Third Parties (i.e. clients) and Data =
Custodians (i.e. authorization and resource servers).  Therefore, the =
tokens being generated are ubiquitous values with no direct information =
the recipient can use to access resource information.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20

From: Bill Mills [mailto:wmills_92105@yahoo.com]=20
Sent: Monday, February 17, 2014 9:10 AM
To: Donald Coffin; 'Marty Burns'; oauth@ietf.org
Cc: 'greenbutton-dev'
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" =
and "client_credentials" based access tokens

=20

Yes, token #1 with that scope could only access resource #3 and #4 in =
your example, the other resources don't allow that scope. The only =
solution in spec is to have the other resource owners allow a scope that =
token #1 has.

=20

You're apparently overloading a bunch of stuff in the scope that most =
would put in the access token.  Are you trying to give a hint to the =
client about the token?

=20

On Sunday, February 16, 2014 10:54 PM, Donald Coffin =
 wrote:

Bill,

=20

We understand, per [RFC 6749], the granted SCOPE does not have to match =
the requested SCOPE, however, in our application a client does an =
exchange of supported Authorization Server Scopes to ensure the resource =
owner is NOT asked by the client to select a SCOPE parameter the =
Authorization Server will be forced to override.

=20

We also understand, per [RFC 6740], the SCOPE parameter is a space =
delimited list.  Therefore, the following two examples are not the same:

=20

=C2=B7         =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D04

=C2=B7         FB=3D4_5_15 IntervalDuration=3D900 =
BlockDuration=3Dmonthly HistoryLength=3D13 BR=3D04

=20

The first string represents a single SCOPE parameter, but the second =
string represents five (5) different SCOPE parameters.  Our original =
definition of the SCOPE string used commas (=E2=80=9C,=E2=80=9D) where =
the first example has semi-colons (=E2=80=9C;=E2=80=9D), however, we =
found the Spring Security OAuth 2.0 framework treats commas as blanks to =
support a Facebook SCOPE implementation.  This has recently been =
refactored to support the [RFC 6749] SCOPE definition, as it was found =
that though Facebook=E2=80=99s documentation calls for commas as SCOPE =
parameter separators, this was never implemented by Facebook.

=20

The following table defines a potential table of access tokens based on =
granted SCOPE strings:

=20


Owner

SCOPE

Grant Type

Access Token

Accessible by Access Token


Client

FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D05

Client_credentials

Token 1

NA**


RO 1

FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D04

Code

Token 2

Token 2


RO 1

FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D04

Code

Token 3

Token 3


RO 2

FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D05

Code

Token 4

Token 4


RO 3

FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D05

Code

Token 5

Token 5 & Token 1


RO 4

FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D05

Code

Token 6

Token 6 & Token 1

=20

** Token 1 is owned by the client and therefore does NOT own any =
resources for which access can be authorized.

=20

The question we are attempting to resolve is which resources can the =
owner of Token 1 access given the above table?  If the owner of Token 1 =
is allowed to access ALL resources represented by Tokens 2 =E2=80=93 6, =
then we do not need to worry about identifying which resources can be =
accessed by using Token 1.  However, if Token 1 can only be used to =
access the resources authorized by resource owner (RO) 3 and 4, then =
what is the criteria that must be used to validate that Token 1, when =
used, is able to access the requested resource?

=20

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20

From: Bill Mills [mailto:wmills_92105@yahoo.com]=20
Sent: Sunday, February 16, 2014 10:02 PM
To: Marty Burns; Donald Coffin; oauth@ietf.org
Cc: greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" =
and "client_credentials" based access tokens

=20

The scope requested does not have to match the scope granted. =20

=20

Also note that space is the scope separator per the spec, so BR=3D04 is =
not equal to =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D04 but it's your implementation of how you want to interpret =
scopes.

=20

On Sunday, February 16, 2014 5:36 PM, Marty Burns  =
wrote:

Don,

=20

Good comment. One point =E2=80=93 the authorizations covered by =
BulkId=3D04 would have Scopes of:

                        =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D04

Marty

=20

=20

From: greenbutton-dev@googlegroups.com =
[mailto:greenbutton-dev@googlegroups.com] On Behalf Of Donald Coffin
Sent: Sunday, February 16, 2014 8:14 PM
To: 'Bill Mills'; oauth@ietf.org
Cc: 'greenbutton-dev'
Subject: RE: [OAUTH-WG] Scope parameter values for "authorization_code" =
and "client_credentials" based access tokens

=20

Bill,

=20

Thanks for your reply, but I=E2=80=99m not sure you fully understand the =
situation I am attempting to resolve.

=20

For example, does an access token obtained via the =
=E2=80=9Cclient_credentials=E2=80=9D request with the following SCOPE =
parameter:

                        BulkID=3D04

allow a client to ask for resources when the individual access token =
contained the following SCOPE parameter:

                        =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13

=20

The question is what individual access token authorization should be =
covered by the =E2=80=9Cclient_credentials=E2=80=9D based access token?

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20

From: Bill Mills [mailto:wmills_92105@yahoo.com]=20
Sent: Saturday, February 15, 2014 8:30 PM
To: Donald Coffin; oauth@ietf.org
Cc: greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" =
and "client_credentials" based access tokens

=20

To tokens themselves don't differ based on how they are obtained unless =
you want them to.  No requirement to match scope to the client ID =
either, but again it's up to you.

=20

You do want to get this right.  The challenge here is that your resource =
servers have to get updated to support new scopes.  If they support =
auto-updates then it's not quite as big a deal but it's still =
non-trivial.

=20

-bill

=20

=20

=20

On Saturday, February 15, 2014 7:01 PM, Donald Coffin =
 wrote:

I would like to get the views and comments of the OAuth 2.0 IETF WG on =
the following design and implementation question:

=20

I have an application that supports both =
=E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  The =
application allows a client to obtain data on a nightly basis for =
resource owners who have granted the application access to their data.  =
The client application retrieves energy usage information and can =
potentially need to retrieve data from a few accounts to several million =
accounts.  In order to eliminate the need for the client application to =
request the data from the resource server one account at a time, the =
client application has been designed to support =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  Per [RFC 6749 =
Section 4.4 =E2=80=93 =E2=80=9CClient Credentials Grant=E2=80=9D] The =
use of the =E2=80=9Cclient_credentials=E2=80=9D based access token will =
allow the client application to obtain access to the data with a single =
request, thus significantly reducing the amount of network traffic for =
both the client and the resource server.

=20

The question the design team is struggling with is what should the Scope =
string be for the =E2=80=9Cclient_credentials=E2=80=9D based access =
token and should there be a single access token or can there be multiple =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens?

=20

The client application currently supports the following Scope =
definitions:

=20

=C2=B7         =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13

=C2=B7         =
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13

=20

There are several allowable values for the FB=3D, IntervalDuration=3D, =
BlockDuration=3D, and HistoryLength=3D values.  At the moment, there are =
only two defined Scope values, but as you can see, there could easily be =
many more potential possibilities. =20

=20

The question being discussed, is does the =
=E2=80=9Cclient_credentials=E2=80=9D access token request Scope =
parameter need to match either of the above two strings or can it be =
something altogether different?  In the event the =
=E2=80=9Cclient_credentials=E2=80=9D access token request Scope =
parameter needs to match a defined Scope string, does that mean that =
there MUST be multiple =E2=80=9Cclient_credentials=E2=80=9D based access =
tokens?

=20

Thanks in advance for helping clarify our understanding of the =
relationship between =E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20


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

--=20
You received this message because you are subscribed to the Google =
Groups "greenbutton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send =
an email to greenbutton-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

=20

=20

=20


------=_NextPart_000_00A8_01CF2BCE.811184A0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Bill,
 
Expiration of the access token =
is defined by the authorization server and returned to the client as =
part of the access token JSON response.=C2=A0 I=E2=80=99m not sure I =
understand the =E2=80=9Cscope name=E2=80=9D and =E2=80=9Cmax allowable =
records=E2=80=9D portion of your question.=C2=A0 Can you =
clarify?
 
Some of =
the group believe the contents of the SCOPE parameter is a suggestion to =
the client of the data available from the resource server and NOT a =
limiting value of the data a client may access.=C2=A0 Can you comment on =
your interpretation of the meaning of the SCOPE =
parameter?
 
=

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
=

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA=C2=A0 92688-3836
 
=

Phone:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 (949) 636-8571
Email:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 donald.coffin@reminetworks.com=

 
=

From:=
 =
Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: Monday, =
February 17, 2014 10:23 AM
To: Donald Coffin; 'Marty Burns'; =
oauth@ietf.org
Cc: 'greenbutton-dev'
Subject: Re: =
[OAUTH-WG] Scope parameter values for "authorization_code" and =
"client_credentials" based access =
tokens
 
And how =
exactly does that apply to scope name, expiry, or max allowable records =
fetched?
 
O=
n Monday, February 17, 2014 9:59 AM, Donald Coffin <donald.coffin@reminetworks=
.com> wrote:
Bill,
 
Our design =
does not include any identifiable information be passed within the =
token, as the standard being implemented (Energy Service Provider =
Interface) has the requirement that no personal identifiable information =
be exchanged between Third Parties (i.e. clients) and Data Custodians =
(i.e. authorization and resource servers).  Therefore, the tokens =
being generated are ubiquitous values with no direct information the =
recipient can use to access resource =
information.
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
22751 El =
Prado Suite 6216
Rancho Santa =
Margarita, CA  92688-3836
 
Phone: &n=
bsp;    (949) 636-8571
Email: &n=
bsp;     donald.coffin@reminetworks.com
 
From: Bill Mills [mailto:wmills_92105@yahoo.com]=
 
Sent: Monday, February 17, 2014 9:10 AM
To: Donald =
Coffin; 'Marty Burns'; oauth@ietf.org
Cc: =
'greenbutton-dev'
Subject: Re: [OAUTH-WG] Scope parameter =
values for "authorization_code" and =
"client_credentials" based access tokens
 
Yes, token #1 =
with that scope could only access resource #3 and #4 in your example, =
the other resources don't allow that scope. The only solution in spec is =
to have the other resource owners allow a scope that token #1 =
has.
 
You're =
apparently overloading a bunch of stuff in the scope that most would put =
in the access token.  Are you trying to give a hint to the client =
about the token?
 
On Sunday, February 16, 2014 10:54 PM, Donald Coffin <donald.coffin@reminetworks.com> =
wrote:
Bill,
 
We =
understand, per [RFC 6749], the granted SCOPE does not have to match the =
requested SCOPE, however, in our application a client does an exchange =
of supported Authorization Server Scopes to ensure the resource owner is =
NOT asked by the client to select a SCOPE parameter the Authorization =
Server will be forced to =
override.
 
We also =
understand, per [RFC 6740], the SCOPE parameter is a space delimited =
list.  Therefore, the following two examples are not the =
same:
 
=C2=B7         FB=3D4_5_15;In=
tervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04
=C2=B7         FB=3D4_5_15 =
IntervalDuration=3D900 BlockDuration=3Dmonthly HistoryLength=3D13 =
BR=3D04
 
The first =
string represents a single SCOPE parameter, but the second string =
represents five (5) different SCOPE parameters.  Our original =
definition of the SCOPE string used commas (=E2=80=9C,=E2=80=9D) where =
the first example has semi-colons (=E2=80=9C;=E2=80=9D), however, we =
found the Spring Security OAuth 2.0 framework treats commas as blanks to =
support a Facebook SCOPE implementation.  This has recently been =
refactored to support the [RFC 6749] SCOPE definition, as it was found =
that though Facebook=E2=80=99s documentation calls for commas as SCOPE =
parameter separators, this was never implemented by =
Facebook.
 
The following =
table defines a potential table of access tokens based on granted SCOPE =
strings:
 
Owner
SCOPE
Grant =
Type
Access =
Token
Accessible by Access =
Token
Client
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D05
Client_credentials
Token 1
NA**
RO 1
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D04
Code
Token 2
Token 2
RO 1
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D04
Code
Token 3
Token 3
RO 2
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D05
Code
Token 4
Token 4
RO 3
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D05
Code
Token 5
Token 5 & Token =
1
RO 4
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmont=
hly;HistoryLength=3D13;BR=3D05
Code
Token 6
Token 6 & Token =
1
 
** Token 1 is =
owned by the client and therefore does NOT own any resources for which =
access can be authorized.
 
The question =
we are attempting to resolve is which resources can the owner of Token 1 =
access given the above table?  If the owner of Token 1 is allowed =
to access ALL resources represented by Tokens 2 =E2=80=93 6, then we do =
not need to worry about identifying which resources can be accessed by =
using Token 1.  However, if Token 1 can only be used to access the =
resources authorized by resource owner (RO) 3 and 4, then what is the =
criteria that must be used to validate that Token 1, when used, is able =
to access the requested =
resource?
 
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
22751 El =
Prado Suite 6216
Rancho Santa =
Margarita, CA  =
92688-3836
 
Phone: &n=
bsp;    (949) =
636-8571
Email: &n=
bsp;     donald.coffin@reminetworks.com
 
From: Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: =
Sunday, February 16, 2014 10:02 PM
To: Marty Burns; Donald =
Coffin; oauth@ietf.org
Cc: =
greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values =
for "authorization_code" and "client_credentials" =
based access tokens
 
The scope =
requested does not have to match the scope granted. =
 
 
Also note =
that space is the scope separator per the spec, so BR=3D04 is not equal =
to FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3D=
monthly;HistoryLength=3D13;BR=3D04 but =
it's your implementation of how you want to interpret =
scopes.
 
On Sunday, February 16, 2014 5:36 PM, Marty Burns <marty@hypertek.us> wrote:
Don,
 
Good comment. One point =E2=80=93 the authorizations covered by BulkId=3D04 would have Scopes =
of:
  &n=
bsp;           &nb=
sp;         FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3D=
monthly;HistoryLength=3D13;BR=3D04
Marty
 
 
From: greenbutton-dev@googlegroups.com [mailto:greenbutton-dev@googlegroups.com] On Behalf Of =
Donald Coffin
Sent: Sunday, February 16, 2014 8:14 =
PM
To: 'Bill Mills'; oauth@ietf.org
Cc: =
'greenbutton-dev'
Subject: RE: [OAUTH-WG] Scope parameter =
values for "authorization_code" and =
"client_credentials" based access tokens
 
Bill,
 
Thanks for =
your reply, but I=E2=80=99m not sure you fully understand the situation =
I am attempting to =
resolve.
 
For example, =
does an access token obtained via the =
=E2=80=9Cclient_credentials=E2=80=9D request with the following SCOPE =
parameter:

         &=
nbsp;           &n=
bsp;  BulkID=3D04

allow a client to ask for resources when =
the individual access token contained the following SCOPE =
parameter:

         &=
nbsp;           &n=
bsp;  =
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13
 
The question =
is what individual access token authorization should be covered by the =
=E2=80=9Cclient_credentials=E2=80=9D based access =
token?
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
22751 El =
Prado Suite =
6216
Rancho Santa =
Margarita, CA  =
92688-3836
 
Phone: &n=
bsp;    (949) =
636-8571
Email: &n=
bsp;     donald.coffin@reminetworks.com
 
From: Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: =
Saturday, February 15, 2014 8:30 PM
To: Donald Coffin; oauth@ietf.org
Cc: =
greenbutton-dev
Subject: Re: [OAUTH-WG] Scope parameter values =
for "authorization_code" and "client_credentials" =
based access tokens
 
To tokens =
themselves don't differ based on how they are obtained unless you want =
them to.  No requirement to match scope to the client ID either, =
but again it's up to =
you.
 
You do want =
to get this right.  The challenge here is that your resource =
servers have to get updated to support new scopes.  If they support =
auto-updates then it's not quite as big a deal but it's still =
non-trivial.
=

 
-bill
 
 
 
On Saturday, February 15, 2014 7:01 PM, Donald Coffin <donald.coffin@reminetworks.com> =
wrote:
I would like =
to get the views and comments of the OAuth 2.0 IETF WG on the following =
design and implementation =
question:
 
I have an =
application that supports both =E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  The =
application allows a client to obtain data on a nightly basis for =
resource owners who have granted the application access to their =
data.  The client application retrieves energy usage information =
and can potentially need to retrieve data from a few accounts to several =
million accounts.  In order to eliminate the need for the client =
application to request the data from the resource server one account at =
a time, the client application has been designed to support =
=E2=80=9Cclient_credentials=E2=80=9D based access tokens.  Per [RFC =
6749 Section 4.4 =E2=80=93 =E2=80=9CClient Credentials Grant=E2=80=9D] =
The use of the =E2=80=9Cclient_credentials=E2=80=9D based access token =
will allow the client application to obtain access to the data with a =
single request, thus significantly reducing the amount of network =
traffic for both the client and the resource =
server.
=

 
The question =
the design team is struggling with is what should the Scope string be =
for the =E2=80=9Cclient_credentials=E2=80=9D based access token and =
should there be a single access token or can there be multiple =
=E2=80=9Cclient_credentials=E2=80=9D based access =
tokens?
=

 
The client =
application currently supports the following Scope =
definitions:
=

 
=C2=B7         FB=3D4_5_15;In=
tervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13
=C2=B7         FB=3D4_5_16;In=
tervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13
 
There are =
several allowable values for the FB=3D, IntervalDuration=3D, =
BlockDuration=3D, and HistoryLength=3D values.  At the moment, =
there are only two defined Scope values, but as you can see, there could =
easily be many more potential possibilities.  =

 
The question =
being discussed, is does the =E2=80=9Cclient_credentials=E2=80=9D access =
token request Scope parameter need to match either of the above two =
strings or can it be something altogether different?  In the event =
the =E2=80=9Cclient_credentials=E2=80=9D access token request Scope =
parameter needs to match a defined Scope string, does that mean that =
there MUST be multiple =E2=80=9Cclient_credentials=E2=80=9D based access =
tokens?
=

 
Thanks in =
advance for helping clarify our understanding of the relationship =
between =E2=80=9Cauthorization_code=E2=80=9D and =
=E2=80=9Cclient_credentials=E2=80=9D based access =
tokens.
=

 
Best =
regards,
Don
Donald F. =
Coffin
<=
p class=3DMsoNormal style=3D'background:white'>Founder/CTO
 
REMI =
Networks
22751 El =
Prado Suite =
6216
Rancho Santa =
Margarita, CA  =
92688-3836
 
Phone: &n=
bsp;    (949) =
636-8571
Email: &n=
bsp;     donald.coffin@reminetworks.com
 

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

-- 
You =
received this message because you are subscribed to the Google Groups =
"greenbutton-dev" group.
To unsubscribe from this group and =
stop receiving emails from it, send an email to greenbutton-dev+unsubscribe@googlegroups.com.
Fo=
r more options, visit https://groups.google.com/groups/opt_out.
 
 
 

------=_NextPart_000_00A8_01CF2BCE.811184A0--



From nobody Wed Feb 19 12:38:07 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8A31A05FB for ; Wed, 19 Feb 2014 12:38:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l25ESbd6Bxps for ; Wed, 19 Feb 2014 12:38:03 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id E78B61A05F2 for ; Wed, 19 Feb 2014 12:38:01 -0800 (PST)
Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.878.16; Wed, 19 Feb 2014 20:37:50 +0000
Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.20]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.20]) with mapi id 15.00.0878.008; Wed, 19 Feb 2014 20:37:49 +0000
From: Antonio Sanso 
To: "oauth@ietf.org" 
Thread-Topic: Some OAuth related vulnerability in Google and Facebook
Thread-Index: AQHPLbJ0fQi4oDuockSjxlMQGRZj1Q==
Date: Wed, 19 Feb 2014 20:37:49 +0000
Message-ID: <88EEAE70-42ED-4900-AD3A-CFCCC5FF7DF0@adobe.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [178.83.47.250]
x-forefront-prvs: 012792EC17
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(189002)(199002)(15975445006)(51856001)(69226001)(95666001)(95416001)(77096001)(94316002)(76796001)(81342001)(76786001)(81816001)(53806001)(74366001)(54356001)(94946001)(56776001)(54316002)(74706001)(33656001)(76482001)(36756003)(81686001)(93516002)(74876001)(93136001)(82746002)(76176001)(86362001)(87936001)(4396001)(80976001)(63696002)(92726001)(15202345003)(87266001)(85306002)(49866001)(56816005)(83322001)(19580395003)(47446002)(47736001)(74662001)(83716003)(66066001)(81542001)(74502001)(65816001)(92566001)(83072002)(47976001)(558084003)(85852003)(59766001)(31966008)(50986001)(77982001)(2656002)(90146001)(46102001)(80022001)(79102001)(15302535010); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; CLIP:178.83.47.250; FPR:72F2F4FE.27AF65C8.7859697F.F0CA9C88.20077; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <06285E9884B94A4C9C3C0A392C5D3532@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/IVEo6ianActfVYfdw3RgoNTGTEI
Subject: [OAUTH-WG] Some OAuth related vulnerability in Google and Facebook
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2014 20:38:05 -0000

hi *,

just sharing with you some implementation OAuth related leak in Google and =
Facebook. Some details in:

http://intothesymmetry.blogspot.ch/2014/02/oauth-2-attacks-and-bug-bounties=
.html

regards

antonio=


From marty@hypertek.us  Mon Feb 17 06:20:46 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9281A04E1 for ; Mon, 17 Feb 2014 06:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.967
X-Spam-Level: 
X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0MCRBCfBZXv for ; Mon, 17 Feb 2014 06:20:39 -0800 (PST)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7D61A04DB for ; Mon, 17 Feb 2014 06:20:39 -0800 (PST)
Received: by mail-qc0-f177.google.com with SMTP id i8so23395634qcq.8 for ; Mon, 17 Feb 2014 06:20:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=3bd2Cf7futs+p5n70J5P/iSjwhTCnawkee085QuWJ5w=; b=CsjmpCQlhJxZAPp3WllI0fXj2A2HLHGN+29ssAejjQyPoW6DBzSk0TIKLhZLj5oNxm yrNiWvpRyCmfa8RPKayo1Mky/h/odJk6s+yOfzk3dhIyI35Qu7aIMCJ99Okyy7G62Zph 0/BfARciJQJt+xXpYMbdmwhyn0rjeFuU5ksU72frH9kExKbkkZzbitXC2VQNEbjG5ZNc HjMg2sLB9MGUOg8LWBwGqu6kTnWZhQpm3kABo+riqcEF1ePCoC1pWbTh3YGNDKs+ZHw2 WuJ1g7WYmukxn1MIj/y6f6wzw7Io4VRLQRDpynY2/R/O62bGZf5ZT3TxXrf94ENy9iY7 HqKw==
X-Gm-Message-State: ALoCoQlRckxg/mD4Jk3dzSgayUQDeUP/OVRx2WmDG35LX8Fl5y2wNyuCOkaUiHb7oEa2q7SevHrr
X-Received: by 10.140.20.17 with SMTP id 17mr33186796qgi.28.1392646836553; Mon, 17 Feb 2014 06:20:36 -0800 (PST)
From: Marty Burns 
References: <002301cf2ac2$f0053990$d00facb0$@reminetworks.com> <1392525020.7390.YahooMailNeo@web142801.mail.bf1.yahoo.com> <000e01cf2b7d$79a66c90$6cf345b0$@reminetworks.com> <0e9117b9bb80c29d3e3a53ab64392e94@mail.gmail.com> 
In-Reply-To: 
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEnOl+8JZU1HiFwOiLE96BHahHifwH2C3usAiM9j6kCwG9IxgIvFMcvm8EXRGA=
Date: Mon, 17 Feb 2014 09:18:43 -0500
Message-ID: <76ed1104de52640d8052ca596136ca6a@mail.gmail.com>
To: "Teeter, John" , Donald Coffin ,  Bill Mills , oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a11c124f6fd9a1404f29adb99
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YY44sY0KQ8mUAMf-EOKuF0ZJjJU
X-Mailman-Approved-At: Fri, 21 Feb 2014 12:21:28 -0800
Cc: greenbutton-dev 
Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2014 14:22:54 -0000

--001a11c124f6fd9a1404f29adb99
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Don's email describes why we changed from space to comma for separator
between Scopes. The reason we don't use space inside a scope string is that
we wanted the OAuth layer to treat a scope string as an atomic thing,
rather than a list of independent parameters. The use of space delimits
independent scopes in OAuth.  So we wanted to keep each Scope string as a
separate "scope-token" (see definition below).



Each data custodian will support a small finite set of permutations of the
Scope string (often only one). It is the set that describes the scope.



BTW, here is the full description of the Scope parameter from RFC 6749:

      *3.3**.
Access Token Scope*

   The authorization and token endpoints allow the client to specify the

   scope of the access request using the "scope" request parameter.  In

   turn, the authorization server uses the "scope" response parameter to

   inform the client of the scope of the access token issued.



   The value of the scope parameter is expressed as a list of space-

   delimited, case-sensitive strings.  The strings are defined by the

   authorization server.  If the value contains multiple space-delimited

   strings, their order does not matter, and each string adds an

   additional access range to the requested scope.



     scope       =3D scope-token *( SP scope-token )

     scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E )



   The authorization server MAY fully or partially ignore the scope

   requested by the client, based on the authorization server policy or

   the resource owner's instructions.  If the issued access token scope

   is different from the one requested by the client, the authorization

   server MUST include the "scope" response parameter to inform the

   client of the actual scope granted.



   If the client omits the scope parameter when requesting

   authorization, the authorization server MUST either process the

   request using a pre-defined default value or fail the request

   indicating an invalid scope.  The authorization server SHOULD

   document its scope requirements and default value (if defined).





HTH,

Marty



*From:* Teeter, John [mailto:john.teeter@nist.gov]
*Sent:* Monday, February 17, 2014 8:41 AM
*To:* Marty Burns; Donald Coffin; Bill Mills; oauth@ietf.org
*Cc:* greenbutton-dev
*Subject:* Re: [OAUTH-WG] Scope parameter values for "authorization_code"
and "client_credentials" based access tokens



Remind be again please why we still do not use "space" as a separator in
our Scope?  Seem so me the appropriate scope for the example below should
be:



  "FB=3D4_*5_*15 IntervalDuration=3D900 BlockDuration=3Dmonthly HistoryLeng=
th=3D13
BR=3D04"



If we do use "space' as a separator, I can understand the way that the BR
value can be mixed in to the non BR scopes.



So why do we not use the "space" separator?



jt



*From: *Marty Burns 
*Date: *Sunday, February 16, 2014 8:34 PM
*To: *Donald Coffin , Bill Mills <
wmills_92105@yahoo.com>, "oauth@ietf.org" 
*Cc: *greenbutton-dev 
*Subject: *RE: [OAUTH-WG] Scope parameter values for "authorization_code"
and "client_credentials" based access tokens



Don,



Good comment. One point - the authorizations covered by BulkId=3D04 would
have Scopes of:


FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13;BR=3D04

Marty





*From:*greenbutton-dev@googlegroups.com [mailto:
greenbutton-dev@googlegroups.com] *On Behalf Of *Donald Coffin
*Sent:* Sunday, February 16, 2014 8:14 PM
*To:* 'Bill Mills'; oauth@ietf.org
*Cc:* 'greenbutton-dev'
*Subject:* RE: [OAUTH-WG] Scope parameter values for "authorization_code"
and "client_credentials" based access tokens



Bill,



Thanks for your reply, but I'm not sure you fully understand the situation
I am attempting to resolve.



For example, does an access token obtained via the "client_credentials"
request with the following SCOPE parameter:

                        BulkID=3D04

allow a client to ask for resources when the individual access token
contained the following SCOPE parameter:


FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13



The question is what individual access token authorization should be
covered by the "client_credentials" based access token?



Best regards,

Don

Donald F. Coffin

Founder/CTO



REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836



Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com



*From:* Bill Mills [mailto:wmills_92105@yahoo.com ]
*Sent:* Saturday, February 15, 2014 8:30 PM
*To:* Donald Coffin; oauth@ietf.org
*Cc:* greenbutton-dev
*Subject:* Re: [OAUTH-WG] Scope parameter values for "authorization_code"
and "client_credentials" based access tokens



To tokens themselves don't differ based on how they are obtained unless you
want them to.  No requirement to match scope to the client ID either, but
again it's up to you.



You do want to get this right.  The challenge here is that your resource
servers have to get updated to support new scopes.  If they support
auto-updates then it's not quite as big a deal but it's still non-trivial.



-bill







On Saturday, February 15, 2014 7:01 PM, Donald Coffin <
donald.coffin@reminetworks.com> wrote:

I would like to get the views and comments of the OAuth 2.0 IETF WG on the
following design and implementation question:



I have an application that supports both "authorization_code" and
"client_credentials" based access tokens.  The application allows a client
to obtain data on a nightly basis for resource owners who have granted the
application access to their data.  The client application retrieves energy
usage information and can potentially need to retrieve data from a few
accounts to several million accounts.  In order to eliminate the need for
the client application to request the data from the resource server one
account at a time, the client application has been designed to support
"client_credentials" based access tokens.  Per [RFC 6749 Section 4.4 -
"Client Credentials Grant"] The use of the "client_credentials" based
access token will allow the client application to obtain access to the data
with a single request, thus significantly reducing the amount of network
traffic for both the client and the resource server.



The question the design team is struggling with is what should the Scope
string be for the "client_credentials" based access token and should there
be a single access token or can there be multiple "client_credentials"
based access tokens?



The client application currently supports the following Scope definitions:



=B7
FB=3D4_5_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13

=B7
FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D=
13



There are several allowable values for the FB=3D, IntervalDuration=3D,
BlockDuration=3D, and HistoryLength=3D values.  At the moment, there are on=
ly
two defined Scope values, but as you can see, there could easily be many
more potential possibilities.



The question being discussed, is does the "client_credentials" access token
request Scope parameter need to match either of the above two strings or
can it be something altogether different?  In the event the
"client_credentials" access token request Scope parameter needs to match a
defined Scope string, does that mean that there MUST be multiple
"client_credentials" based access tokens?



Thanks in advance for helping clarify our understanding of the relationship
between "authorization_code" and "client_credentials" based access tokens.



Best regards,

Don

Donald F. Coffin

Founder/CTO



REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836



Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com




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

--=20
You received this message because you are subscribed to the Google Groups
"greenbutton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to greenbutton-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--=20
You received this message because you are subscribed to the Google Groups
"greenbutton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to greenbutton-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--001a11c124f6fd9a1404f29adb99
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Don’s email describes why we changed from space to comma for sepa=
rator between Scopes. The reason we don’t use space inside a scope st=
ring is that we wanted the OAuth layer to treat a scope string as an atomic=
 thing, rather than a list of independent parameters. The use of space deli=
mits independent scopes in OAuth.  So we wanted to =
keep each Scope string as a separate “scope-token” (see definit=
ion below).


 
Each data custodian will support =
a small finite set of permutations of the Scope string (often only one). It=
 is the set that describes the scope. 


 
BTW, here is the full description=
 of the Scope parameter from RFC 6749:


   =
   3.3.  Access Token Scope


   The authorization and tok=
en endpoints allow the client to specify the
   scope of the acc=
ess request using the "scope" request parameter. =
; In


   tur=
n, the authorization server uses the "scope" response para=
meter to


   inform the client of the scope of the access token i=
ssued.


 
 &nb=
sp; The value of the scope parameter is expressed as a list of space=
-


   del=
imited, case-sensitive strings.  The strings=
 are defined by the


   aut=
horization server.  If the value contains mu=
ltiple space-delimited


   str=
ings, their order does not matter, and each string adds an

   additional access range t=
o the requested scope.
 


     scope       =3D scope-token *( SP scope-token )

     scope-token =
=3D 1*( %x21 / %x23-5B / %x5D-7E )
<=
span lang=3D"EN" style=3D"font-family:"Courier New""> 


   The aut=
horization server MAY fully or partially ignore the scope

   requested by the client, based on the authorization server policy or

   the res=
ource owner's instructions.  If the issued acce=
ss token scope


   is different from the one requested by the client, th=
e authorization


   server MUST include the "scope" response pa=
rameter to inform the


   client of the actual scope granted.

 
&nb=
sp;  If the client omits the scope parameter when requesting


   authorization, the authorization server MUST either p=
rocess the


   request using a pre-defined default value or fail the=
 request


   indicating an invalid scope.  The authorization server SHOULD


   document its scope requirements and default value (if=
 defined).


 
 


HTH,
Marty


 
 


From: <=
span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s=
erif";color:black">Marty Burns <marty@hypertek.us>

Date: Sunday, February 16, 2014 8:34 PM
To: Donald Coffin =
<donald.coffin@reminet=
works.com>, Bill Mills <wmills_92105@yahoo.com>, "oa=
uth@ietf.org" <oauth@ietf.org=
>

Cc: greenbutton-dev <greenbutton-dev@googlegroups.com>
Subject: RE: [OA=
UTH-WG] Scope parameter values for "authorization_code" and "=
;client_credentials" based access tokens


 
Don,


 
Good comment. One point – the authorizations covered by BulkId=3D0=
4 would have Scopes of:


   &nbs=
p;            &=
nbsp;       FB=3D4_5_15;IntervalDuration=3D90=
0;BlockDuration=3Dmonthly;HistoryLength=3D13;BR=3D04


Marty
 


 


From:gr=
eenbutton-dev@googlegroups.com [mailto:greenbutton-dev@googlegroups.com] On Behalf Of <=
/b>Donald Coffin

Sent: Sunday, February 16, 2014 8:14 PM
To: 'Bill Mill=
s'; oauth@ietf.org
Cc: =
'greenbutton-dev'
Subject: RE: [OAUTH-WG] Scope parameter=
 values for "authorization_code" and "client_credentials&quo=
t; based access tokens


 
Bill,

 
Thanks for your reply, but I’m not sure you fully understand th=
e situation I am attempting to resolve.<=
/span>


 <=
/p>
For example, does a=
n access token obtained via the “client_credentials” request wi=
th the following SCOPE parameter:


            =
;            BulkID=
=3D04

allow a client to ask for resources when the individual access=
 token contained the following SCOPE parameter:

   &n=
bsp;            =
;        FB=3D4_5_15;IntervalDuration=3D=
900;BlockDuration=3Dmonthly;HistoryLength=3D13


 <=
/p>
The question is what individual access token a=
uthorization should be covered by the “client_credentials” base=
d access token?


 <=
/p>
Best regards,


Don
Donald F. Coffin


Founder/CTO
 


REMI Networks
22751 El Prado Suite 6216


Rancho Santa Margarita, CA  92688-3836<=
/span>
 


Phone:      (949) 6=
36-8571
Email:       donald.coffin@reminetworks.com


 


From: Bill Mills [mailto:wmills_92105@yahoo.com] 

Sent: Saturday, February 15, 2014 8:30 PM
To: Donald Coffi=
n; oauth@ietf.org
Cc: green=
button-dev
Subject: Re: [OAUTH-WG] Scope parameter values for &qu=
ot;authorization_code" and "client_credentials" based access=
 tokens


 
=
To tokens themselves don't differ based on how they are obtained unless=
 you want them to.  No requirement to match scope to the client ID eit=
her, but again it's up to you.


 
You do wan=
t to get this right.  The challenge here is that your resource servers=
 have to get updated to support new scopes.  If they support auto-upda=
tes then it's not quite as big a deal but it's still non-trivial.


 
-bill


 
 


 
<=
div>


On=
 Saturday, February 15, 2014 7:01 PM, Donald Coffin <donald.coffin@reminetworks.com> wrote=
:


I would like to get the views and comments of=
 the OAuth 2.0 IETF WG on the following design and implementation question:=



 

I have an application that supports both “authorization_code&rdquo=
; and “client_credentials” based access tokens.  The appli=
cation allows a client to obtain data on a nightly basis for resource owner=
s who have granted the application access to their data.  The client a=
pplication retrieves energy usage information and can potentially need to r=
etrieve data from a few accounts to several million accounts.  In orde=
r to eliminate the need for the client application to request the data from=
 the resource server one account at a time, the client application has been=
 designed to support “client_credentials” based access tokens.&=
nbsp; Per [RFC 6749 Section 4.4 – “Client Credentials Grant&rdq=
uo;] The use of the “client_credentials” based access token wil=
l allow the client application to obtain access to the data with a single r=
equest, thus significantly reducing the amount of network traffic for both =
the client and the resource server.


 

The question the design team is struggling with is what should the Scope=
 string be for the “client_credentials” based access token and =
should there be a single access token or can there be multiple “clien=
t_credentials” based access tokens?


 

The client application currently supports the following Scope definition=
s:

 

=B7         FB=3D4_5=
_15;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLength=3D13


=B7         FB=3D4_5_16;IntervalDuration=3D900;BlockDuration=3Dmonthly;HistoryLeng=
th=3D13


 

There are several allowable values for the FB=3D, IntervalDuration=3D, B=
lockDuration=3D, and HistoryLength=3D values.  At the moment, there ar=
e only two defined Scope values, but as you can see, there could easily be =
many more potential possibilities.  


 

The question being discussed, is does the “client_credentials&rdqu=
o; access token request Scope parameter need to match either of the above t=
wo strings or can it be something altogether different?  In the event =
the “client_credentials” access token request Scope parameter n=
eeds to match a defined Scope string, does that mean that there MUST be mul=
tiple “client_credentials” based access tokens?


 

Thanks in advance for helping clarify our understanding of the relations=
hip between “authorization_code” and “client_credentials&=
rdquo; based access tokens.


 

Best regards,
=

Don=



Dona=
ld F. Coffin

Founder/CTO
 


REMI=
 Networks

22751 El Prado Suite 6216
Rancho Santa Margarita, CA  92688-3836


&nbs=
p;

Phone:      (949) 636-8571
&nbs=
p;


_______________________________________________
OAuth mail=
ing list
OAuth@ietf.org
https://=
www.ietf.org/mailman/listinfo/oauth<=
/span>


-- 
You received this message because you are subscribed to the Go=
ogle Groups "greenbutton-dev" group.
To unsubscribe from this =
group and stop receiving emails from it, send an email to greenbutton-dev+unsubscribe@=
googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
-- 

You received this message because you are subscribed to the Google Groups &=
quot;greenbutton-dev" group.
To unsubscribe from this group and sto=
p receiving emails from it, send an email to greenbutton-dev+unsubscribe@googlegroups.=
com.

For more options, visit https://groups.google.com/groups/opt_out.


--001a11c124f6fd9a1404f29adb99--


From nobody Mon Feb 24 10:47:22 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07141A0264 for ; Mon, 24 Feb 2014 10:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.977
X-Spam-Level: 
X-Spam-Status: No, score=0.977 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24ykW3McR17d for ; Mon, 24 Feb 2014 10:47:19 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id B2C621A0249 for ; Mon, 24 Feb 2014 10:47:18 -0800 (PST)
Received: from [217.140.96.21] by 3capp-gmx-bs13 with HTTP; Mon, 24 Feb 2014 19:47:16 +0100
MIME-Version: 1.0
Message-ID: 
From: "Hannes Tschofenig" 
To: oauth@ietf.org
Content-Type: text/html; charset=UTF-8
Date: Mon, 24 Feb 2014 19:47:16 +0100
Importance: normal
Sensitivity: Normal
X-Priority: 3
X-Provags-ID: V03:K0:8vtcjjX142ZCO5YO9xfuU55joF+BfZHB3uD0zkTwFMG hPei2VnwcRfEbYiVJOOzEzdG5cu28MhU1sXZjIAog3i9Aor9ST U+MVwbyKfx6JVnf2krh6X08WWlz8rKZPFTP6OicSD8lUEWucKH NCdHT0qirl+hoPQFFVfHw3aciNmu7VxoSeQ1ZwxWNLDMYQPx7o VdnbC/w2HOzbVTqth6YAfatKsS4iSW08QYOLp3oyrmmLnyHu+o gJL7/45mH+gMrmK/YZ2z2uZmZQQuAKkhxS5wKM/OufkcQJmYf+ kUSIW8=
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5bO7jx35YNIXWgYDXk7X3boyQ6g
Subject: [OAUTH-WG] Draft Agenda
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Feb 2014 18:47:21 -0000


Hi all, 



 



we put a draft agenda online:



http://www.ietf.org/proceedings/89/agenda/agenda-89-oauth



 



Let us know whether this sounds reasonable for you.



 



Ciao

Hannes & Derek



From nobody Mon Feb 24 15:53:43 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F9A1A0349 for ; Mon, 24 Feb 2014 15:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.047
X-Spam-Level: 
X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbn7LjQ9jCQK for ; Mon, 24 Feb 2014 15:53:39 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED231A034D for ; Mon, 24 Feb 2014 15:53:39 -0800 (PST)
Received: from [192.168.10.243] ([80.43.126.29]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MZD0K-1WYVlU3daG-00L02k for ; Tue, 25 Feb 2014 00:53:37 +0100
Message-ID: <530BDB7E.9020302@gmx.net>
Date: Tue, 25 Feb 2014 00:53:34 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <530BDB5F.5030400@gmx.net>
In-Reply-To: <530BDB5F.5030400@gmx.net>
X-Enigmail-Version: 1.5.2
X-Forwarded-Message-Id: <530BDB5F.5030400@gmx.net>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DvSJxRsX4KpDNMDvKrEshAdUac273vml3"
X-Provags-ID: V03:K0:UoyTR76sLWcYo6OXwYhJSDi5G70QHiJ/Q2OAS1o3SkI4TvSi1y2 Z6SsLqKMifOkPzTR9E5RBphiOIkn9a4EOOR123Cwz5aeMB4AuKdvgw+CwsUT3Wv1l5PSNn4 3g0+LnAbhhiQH3UBbiVBTcdU4Umus/Ga9PE/nCpPepoOXW7zXA6gBl7p1Z1s8FQyBF+BIMy jInwsFSjmUMtuKzRUzMKw==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ok96T2YyYs2nwQDOIp6NM3YQBtE
Subject: [OAUTH-WG] Fwd: Tutorials (OAuth, Kerberos, PKI) for ACE BOF Preparation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Feb 2014 23:53:41 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--DvSJxRsX4KpDNMDvKrEshAdUac273vml3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,

in preparation for the ACE BOF at this IETF I thought it would be useful
to have some tutorials about relevant IETF technologies.
These tutorials will take place this week (via Webex, 1 hour session).

In case you are not on the IETF ACE mailing list I thought it makes
sense to forward it also to SAAG.

** Kerberos Tutorial
Presenter: Thomas Hardjono
Date: Tuesday, February 25, 2014
Time: 1:00 pm, GMT Time (London, GMT)
Meeting Number: 644 999 834
Meeting Password: kerberos
Online meeting:
https://ietf.webex.com/ietf/j.php?MTID=3Dm1ece1ae3939e5d85a28b2b235160458=
c
Audio conference information
 - Call-in toll number (US/Canada): 1-650-479-3208
 - Access code:644 999 834
To add this meeting to your calendar program:
https://ietf.webex.com/ietf/j.php?MTID=3Dmbf017fcbf20fad698c6f2b5b704c384=
7

** PKI Tutorial
Presenter: Sean Turner
Date: Wednesday, February 26, 2014
Time: 1:00 pm, GMT Time (London, GMT)
Meeting Number: 647 365 244
Meeting Password: sean

Online meeting:
https://ietf.webex.co/ietf/j.php?MTID=3Dmc596baf62b263e8a7ced4831061a994d=

Audio conference information
 - Call-in toll number (US/Canada): 1-650-479-3208
 - Access code:647 365 244
To add this meeting to your calendar program:
https://ietf.webex.co/ietf/j.php?MTID=3Dma0d75a19ae69ce587599dcb25dc48d04=


** OAuth Tutorial
Presenter: Justin Richer
Date: Thursday, February 27, 2014
Time: 1:00 pm, GMT Time (London, GMT)
Meeting Number: 646 901 997
Meeting Password: justin
Online meeting:
https://ietf.webex.co/ietf/j.php?MTID=3Dm51cdea08122259237c6193380a3ccdd4=

Audio conference information:
- Call-in toll number (US/Canada): 1-650-479-3208
- Access code:646 901 997
To add this meeting to your calendar program
https://ietf.webex.co/ietf/j.php?MTID=3Dm8bcee257eb3ab56e51c9b02c5b63b123=


Ciao
Hannes

PS: I was told that the IETF Webex bridge does not offer other dial-in
numbers. If you want to dial-in from remote please use Skype or some
other VoIP tool to keep the costs at a reasonable level.




--DvSJxRsX4KpDNMDvKrEshAdUac273vml3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTC9t+AAoJEGhJURNOOiAtcJsH/2oRYhMIgEAy+QZ4uj6raOz9
tmHe2xLgM7uJC4h2ymUJQ5Pch7q+g6oPE7QX50R1tYxXfYn91wXXGNfdEl2AYExa
6rzq8Tw/nJAj40kp27wX/XlNkGpvNJRa0KPIpPzDVLh22fdnD+MQ6bjZ8khiKwOM
Jm6K4IsBKCo6Jg56SjDauEeztBWH1Iog42WmMYOCBfWGjY4BjWF4RgYMKUPJ7v9o
pHhHkDUZ42LXSmlTlB2QcjZZq4SQQlAAKP8CkaeDkHh/DQUBxjeperqGpfeA6I2Z
oyYgR8njhi620xEUyMUuBYH4adJQGPnW2AhkckBi9xXvR8Y2HhcNnma6E9Ei+dw=
=Wp64
-----END PGP SIGNATURE-----

--DvSJxRsX4KpDNMDvKrEshAdUac273vml3--


From nobody Mon Feb 24 23:32:27 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27F71A0545 for ; Mon, 24 Feb 2014 23:32:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsMw3IrPdcHK for ; Mon, 24 Feb 2014 23:32:23 -0800 (PST)
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 661F11A0537 for ; Mon, 24 Feb 2014 23:32:23 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id t61so13945wes.22 for ; Mon, 24 Feb 2014 23:32:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=M/59i41FFsNCmdDqi8pIaBP47oOtZPTkC9XdRy0HYMk=; b=gmYTxtGndM5QNJH0/jleaaQpDzMz+yxyaIbvcDRJdqU5HU4omKT1O/kYBQwg+ZVZXc RLmgEKhT1R6Slwe0PugBnvuo0V7GXstaFDWL5YF951I7KgO+dj91u/RjJYCZ4OHT2I5R EAz3wtKrrCf9KVS+aeFr+IpKl2M7rA3kxdJyOj6uslutKqr5nu79B/eIVJRuxoZ3G8dz 264N2qHy9NhOSx8FaVqs5UxH+hAPoi5URZToudFYAE6k3J5lpJZ3oCSXytSAKOTBXZeP GloI18/PWa3rS5IDhOXyOk3+o2+JzzmVvlYooDIL1hRNSotHw7a6MsPoymXnrs+WyM39 4Ciw==
X-Gm-Message-State: ALoCoQlC+LI2yQlh/sAWyXznGdqc2Z1z+wr7KWq7UZg9O8Oxcxh6pMR9NttF8XWFRgm0EqlPPxsS
X-Received: by 10.194.170.167 with SMTP id an7mr22757883wjc.39.1393313542120;  Mon, 24 Feb 2014 23:32:22 -0800 (PST)
Received: from [192.168.48.250] (80.224.32.125.static.user.ono.com. [80.224.32.125]) by mx.google.com with ESMTPSA id de3sm48402965wjb.8.2014.02.24.23.32.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 23:32:20 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_1EE6CF2F-F12B-4496-9074-64563B32D846"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley 
In-Reply-To: <530BDB7E.9020302@gmx.net>
Date: Tue, 25 Feb 2014 08:32:08 +0100
Message-Id: <2AE29C39-808C-46D8-8002-98989467FFC3@ve7jtb.com>
References: <530BDB5F.5030400@gmx.net> <530BDB7E.9020302@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9OoTwM1n6E0ieqtQ4QWZfO4jt8M
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Fwd: Tutorials (OAuth, Kerberos, PKI) for ACE BOF Preparation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 07:32:25 -0000

--Apple-Mail=_1EE6CF2F-F12B-4496-9074-64563B32D846
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hannes,

Is the OAuth Proof of possession meeting going to be at 10am Sunday =
March 2?

I was talking to some WG members yesterday who thought that we were =
meeting in the afternoon after the Connect meeting.

John B.

On Feb 25, 2014, at 12:53 AM, Hannes Tschofenig =
 wrote:

> Hi all,
>=20
> in preparation for the ACE BOF at this IETF I thought it would be =
useful
> to have some tutorials about relevant IETF technologies.
> These tutorials will take place this week (via Webex, 1 hour session).
>=20
> In case you are not on the IETF ACE mailing list I thought it makes
> sense to forward it also to SAAG.
>=20
> ** Kerberos Tutorial
> Presenter: Thomas Hardjono
> Date: Tuesday, February 25, 2014
> Time: 1:00 pm, GMT Time (London, GMT)
> Meeting Number: 644 999 834
> Meeting Password: kerberos
> Online meeting:
> =
https://ietf.webex.com/ietf/j.php?MTID=3Dm1ece1ae3939e5d85a28b2b235160458c=

> Audio conference information
> - Call-in toll number (US/Canada): 1-650-479-3208
> - Access code:644 999 834
> To add this meeting to your calendar program:
> =
https://ietf.webex.com/ietf/j.php?MTID=3Dmbf017fcbf20fad698c6f2b5b704c3847=

>=20
> ** PKI Tutorial
> Presenter: Sean Turner
> Date: Wednesday, February 26, 2014
> Time: 1:00 pm, GMT Time (London, GMT)
> Meeting Number: 647 365 244
> Meeting Password: sean
>=20
> Online meeting:
> =
https://ietf.webex.co/ietf/j.php?MTID=3Dmc596baf62b263e8a7ced4831061a994d
> Audio conference information
> - Call-in toll number (US/Canada): 1-650-479-3208
> - Access code:647 365 244
> To add this meeting to your calendar program:
> =
https://ietf.webex.co/ietf/j.php?MTID=3Dma0d75a19ae69ce587599dcb25dc48d04
>=20
> ** OAuth Tutorial
> Presenter: Justin Richer
> Date: Thursday, February 27, 2014
> Time: 1:00 pm, GMT Time (London, GMT)
> Meeting Number: 646 901 997
> Meeting Password: justin
> Online meeting:
> =
https://ietf.webex.co/ietf/j.php?MTID=3Dm51cdea08122259237c6193380a3ccdd4
> Audio conference information:
> - Call-in toll number (US/Canada): 1-650-479-3208
> - Access code:646 901 997
> To add this meeting to your calendar program
> =
https://ietf.webex.co/ietf/j.php?MTID=3Dm8bcee257eb3ab56e51c9b02c5b63b123
>=20
> Ciao
> Hannes
>=20
> PS: I was told that the IETF Webex bridge does not offer other dial-in
> numbers. If you want to dial-in from remote please use Skype or some
> other VoIP tool to keep the costs at a reasonable level.
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_1EE6CF2F-F12B-4496-9074-64563B32D846
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjI1MDczMjA5WjAjBgkqhkiG9w0BCQQxFgQUcnGu80f1
HKO1D2YUbCXLycL1nOUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAQ3I0z8kp8AWpPwitciqVvCK6SAb/L98z0FDzIgkV
4h1BvGNUtZnwLsj/QLjT6QyRfQ4Ucm+Hcx43cXfBqFbqHPoHxSMM7PV5HMeRWKO54WfVDWGoE2Rg
Syq07O+UUBlMFqdtU+b8Is3KB5mQtLqafZCGN9/TpTh+ygnis/Yx0Mcvyi4cyRseSmg3UsHUl5Yo
dO9siFVKCzPlWIlVUxaWUNwycZWhlr0HEwR281ip8m3O19YhiXV64G86m/Reps2HR69x4m3nT9Hl
6IW6PcKgBHx3f4f0uNm0cS+zm9ypBw0fW3qcI4DfyVQ4t+afSCYJvOWSlaH08ydl/aIgklj+AwAA
AAAAAA==

--Apple-Mail=_1EE6CF2F-F12B-4496-9074-64563B32D846--


From nobody Mon Feb 24 23:38:00 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2953B1A0537 for ; Mon, 24 Feb 2014 23:37:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo3oQjS_9v0J for ; Mon, 24 Feb 2014 23:37:57 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id B947A1A0346 for ; Mon, 24 Feb 2014 23:37:56 -0800 (PST)
Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB589.namprd03.prod.outlook.com (10.255.124.35) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 07:37:55 +0000
Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 07:37:55 +0000
From: Anthony Nadalin 
To: Hannes Tschofenig , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Draft Agenda
Thread-Index: AQHPMZDdhK6J4sg1F0ySKuql2KRwVJrFIrkA
Date: Tue, 25 Feb 2014 07:37:54 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [12.149.152.131]
x-forefront-prvs: 01334458E5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(53754006)(189002)(199002)(377454003)(81342001)(65816001)(15202345003)(54356001)(66066001)(80022001)(69226001)(77982001)(47976001)(59766001)(94316002)(81542001)(54316002)(50986001)(49866001)(47736001)(90146001)(93136001)(76796001)(76786001)(56776001)(76576001)(93516002)(4396001)(63696002)(46102001)(74876001)(85852003)(76482001)(53806001)(87936001)(79102001)(47446002)(92566001)(86362001)(86612001)(95416001)(94946001)(74502001)(74316001)(31966008)(74662001)(19300405004)(87266001)(74366001)(81816001)(85306002)(74706001)(51856001)(80976001)(15975445006)(16236675002)(19580405001)(83322001)(19580395003)(2656002)(33646001)(81686001)(83072002)(95666003)(42262001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB589; H:BLUPR03MB309.namprd03.prod.outlook.com; CLIP:12.149.152.131; FPR:BC94E930.1CB3AFD9.A2F4BFA0.D4FA53EF.200DC; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_f65bffc40d234a91b3e357c13b170bf5BLUPR03MB309namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/4iQyrxVP3UG8Ex6yMdw8Mw_oKLk
Subject: Re: [OAUTH-WG] Draft Agenda
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 07:37:59 -0000

--_000_f65bffc40d234a91b3e357c13b170bf5BLUPR03MB309namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Q291bGQgZWl0aGVyIE1pa2Ugb3IgSSBnZXQgNSBtaW4gZm9yIEFjdEFTL09uQmVoYWxmIG9mIHVw
ZGF0ZT8NCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcNClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIw
MTQgMTA6NDcgQU0NClRvOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogW09BVVRILVdHXSBEcmFm
dCBBZ2VuZGENCg0KSGkgYWxsLA0KDQp3ZSBwdXQgYSBkcmFmdCBhZ2VuZGEgb25saW5lOg0KaHR0
cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84OS9hZ2VuZGEvYWdlbmRhLTg5LW9hdXRoDQoN
CkxldCB1cyBrbm93IHdoZXRoZXIgdGhpcyBzb3VuZHMgcmVhc29uYWJsZSBmb3IgeW91Lg0KDQpD
aWFvDQpIYW5uZXMgJiBEZXJlaw0K

--_000_f65bffc40d234a91b3e357c13b170bf5BLUPR03MB309namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg
NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg
bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7
fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
c3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D
aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w
cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox
LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl
ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8
bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2
bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvdWxk
IGVpdGhlciBNaWtlIG9yIEkgZ2V0IDUgbWluIGZvciBBY3RBUy9PbkJlaGFsZiBvZiB1cGRhdGU/
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01h
aWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g
MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0
aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkhh
bm5lcyBUc2Nob2ZlbmlnPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMjQsIDIw
MTQgMTA6NDcgQU08YnI+DQo8Yj5Ubzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVj
dDo8L2I+IFtPQVVUSC1XR10gRHJhZnQgQWdlbmRhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+SGkgYWxsLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+d2UgcHV0IGEgZHJhZnQgYWdlbmRhIG9ubGlu
ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh
bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm
Lm9yZy9wcm9jZWVkaW5ncy84OS9hZ2VuZGEvYWdlbmRhLTg5LW9hdXRoIj5odHRwOi8vd3d3Lmll
dGYub3JnL3Byb2NlZWRpbmdzLzg5L2FnZW5kYS9hZ2VuZGEtODktb2F1dGg8L2E+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5MZXQgdXMga25vdyB3aGV0aGVyIHRoaXMgc291bmRzIHJlYXNvbmFibGUgZm9yIHlvdS48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPkNpYW88YnI+DQpIYW5uZXMgJmFtcDsgRGVyZWs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_f65bffc40d234a91b3e357c13b170bf5BLUPR03MB309namprd03pro_--


From nobody Tue Feb 25 08:17:26 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA241A0174 for ; Tue, 25 Feb 2014 08:17:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.655
X-Spam-Level: 
X-Spam-Status: No, score=0.655 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVNeYmi4FYNS for ; Tue, 25 Feb 2014 08:17:22 -0800 (PST)
Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) by ietfa.amsl.com (Postfix) with ESMTP id 0008F1A00A3 for ; Tue, 25 Feb 2014 08:17:21 -0800 (PST)
Received: from [98.139.215.143] by nm18.bullet.mail.bf1.yahoo.com with NNFMP;  25 Feb 2014 16:17:21 -0000
Received: from [98.139.212.212] by tm14.bullet.mail.bf1.yahoo.com with NNFMP;  25 Feb 2014 16:17:20 -0000
Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 25 Feb 2014 16:17:20 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 934916.58125.bm@omp1021.mail.bf1.yahoo.com
Received: (qmail 36383 invoked by uid 60001); 25 Feb 2014 16:17:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1393345040; bh=wEI6bPuAIaYVa5ce4AZ9lyhxJvrrhUhiDg9Dx97P0io=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1vK+U+tNRoLizA+JPfJp4YOvW/IgwxYQYP7vWCNLuw0VdCOAUYgh8RzNGYk57WGFmSb+dcpCtd7D2u7nIHXKTLR4P0vxZSE9/n+v6o4j8+9tFGZd5fA97yA+gzXrqmajUTPt8Xbh/gDTUxQrstsM80tprpfLj0Vv25fHFy3EbHo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Nos+4c3y4PIroqcj1VllDIISe/6nbCqHrU86UzPuhZHqT3ukgplhd1zcv3Ukf4LnD/PV/tczBStHA22KYZKPkhnG15Z8UythogevBdZbiGhCuTw52LRkE1+EKQFLigeZgscSi6UbVhSfYm42bWg74KhA6jFxGSsRkssB1MAGCIY=;
X-YMail-OSG: BNsS4uIVM1lKnoJJkCpvcQEeHxTyjX4b.wYTllITyZCN7Yo kZuyXjpX2Foqn_9NowTguNq0x8oSB5c0.e82UCE8mnUo5ksm6y.4dNmcrHHX Wc858DWdjDPVKI4gSYFyIqNghHMRs1JJAgAuN2EMPvngSN56YO.I5VY2ETgb VoTStWlZ8ActW7Abxmxc2hpEqsaeAGgrRdIXZTLgavYFfyl8o8Xp28fbQIkI c0MDHU0wIrwJ5Vhs_Qx319JYvbv732Ye8CZIVujD_0U8LBG6FyWUD8V_dc0h zjPl2gclS6kRA6oMtu4pCvNNZ8HjSlIZLT_VDCsX378lS5KYXBiuvoxlTWns z5YD1GMVGRmeIX9Oh2qOCehpSLcHyjYN6M5aykRjwHshY97gd17XVi4IWTHg 8rgeuWnALNYAjWNqxmtIa8Hu3AkZBl2vf3RLsR6lgcrik0OUIarNI1UkqPNq D62lRTX9G2WBXsEG.e9nVT6F2lfUDwK4s4igU9i3TQYS.JXTnfGhHy0y1rXX E74ZBln70OCaAHS3BUFmxZ0hMZ.ixHDBHnmL5UWRXPeS6lNO5XapOCItTsuL RKm1mIwWPmLKMLc1OoYR0LGYYlsVIUIdG1U_imdwaHUbymiIzEqxakrWNqlb J1w2tqPxq5_C_RSKtH3FTmquHxbQEfYflN4I4tbMfD2RCLL8JaNXohjfYwNO fQkKnQ.hN2.PVjaGGg8F6Ja0edGb1to.CtCWbbDc.sBqFeUqbSpCOwUIwOmj 0itolGLnlb_Wk7X86OxIofo33_rcfXAxJ9Hk_GAVcYSAjhR_9BvH5xz8mWZj HpF3lq6v4.N5p0qzBhg--
Received: from [209.131.62.115] by web142802.mail.bf1.yahoo.com via HTTP; Tue, 25 Feb 2014 08:17:20 PST
X-Rocket-MIMEInfo: 002.001, SSBoYXZlbid0IGhlYXJkIHRoZSB0aW1lIG9yIHBsYWNlIG9mIHRoZSBDb25uZWN0IG1lZXRpbmcsIGFuZCBJJ2QgY29tZSB0byBib3RoLiDCoEZZSSBteSBwbGFuZSBkb2Vzbid0IGxhbmQgdW50aWwgMTA6MzAgSSB0aGluay4KCgoKT24gTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCAxMTozMiBQTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT4gd3JvdGU6CiAKSGFubmVzLAoKSXMgdGhlIE9BdXRoIFByb29mIG9mIHBvc3Nlc3Npb24gbWVldGluZyBnb2luZyB0byBiZSBhdCAxMGFtIFN1bmRheSABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.177.636
References: <530BDB5F.5030400@gmx.net> <530BDB7E.9020302@gmx.net> <2AE29C39-808C-46D8-8002-98989467FFC3@ve7jtb.com>
Message-ID: <1393345040.8248.YahooMailNeo@web142802.mail.bf1.yahoo.com>
Date: Tue, 25 Feb 2014 08:17:20 -0800 (PST)
From: Bill Mills 
To: John Bradley , Hannes Tschofenig 
In-Reply-To: <2AE29C39-808C-46D8-8002-98989467FFC3@ve7jtb.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1397251415-1130842307-1393345040=:8248"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/14VHD9F2QW2-eTJyx9ohX4_nJFw
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Fwd: Tutorials (OAuth, Kerberos, PKI) for ACE BOF Preparation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 16:17:24 -0000

--1397251415-1130842307-1393345040=:8248
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I haven't heard the time or place of the Connect meeting, and I'd come to b=
oth. =A0FYI my plane doesn't land until 10:30 I think.=0A=0A=0A=0AOn Monday=
, February 24, 2014 11:32 PM, John Bradley  wrote:=0A =
=0AHannes,=0A=0AIs the OAuth Proof of possession meeting going to be at 10a=
m Sunday March 2?=0A=0AI was talking to some WG members yesterday who thoug=
ht that we were meeting in the afternoon after the Connect meeting.=0A=0AJo=
hn B.=0A=0A=0AOn Feb 25, 2014, at 12:53 AM, Hannes Tschofenig  wrote:=0A=0A> Hi all,=0A> =0A> in preparation for the ACE BO=
F at this IETF I thought it would be useful=0A> to have some tutorials abou=
t relevant IETF technologies.=0A> These tutorials will take place this week=
 (via Webex, 1 hour session).=0A> =0A> In case you are not on the IETF ACE =
mailing list I thought it makes=0A> sense to forward it also to SAAG.=0A> =
=0A> ** Kerberos Tutorial=0A> Presenter: Thomas Hardjono=0A> Date: Tuesday,=
 February 25, 2014=0A> Time: 1:00 pm, GMT Time (London, GMT)=0A> Meeting Nu=
mber: 644 999 834=0A> Meeting Password: kerberos=0A> Online meeting:=0A> ht=
tps://ietf.webex.com/ietf/j.php?MTID=3Dm1ece1ae3939e5d85a28b2b235160458c=0A=
> Audio conference information=0A> - Call-in toll number (US/Canada): 1-650=
-479-3208=0A> - Access code:644 999 834=0A> To add this meeting to your cal=
endar program:=0A> https://ietf.webex.com/ietf/j.php?MTID=3Dmbf017fcbf20fad=
698c6f2b5b704c3847=0A> =0A> ** PKI Tutorial=0A> Presenter: Sean Turner=0A> =
Date: Wednesday, February 26, 2014=0A> Time: 1:00 pm, GMT Time (London, GMT=
)=0A> Meeting Number: 647 365 244=0A> Meeting Password: sean=0A> =0A> Onlin=
e meeting:=0A> https://ietf.webex.co/ietf/j.php?MTID=3Dmc596baf62b263e8a7ce=
d4831061a994d=0A> Audio conference information=0A> - Call-in toll number (U=
S/Canada): 1-650-479-3208=0A> - Access code:647 365 244=0A> To add this mee=
ting to your calendar program:=0A> https://ietf.webex.co/ietf/j.php?MTID=3D=
ma0d75a19ae69ce587599dcb25dc48d04=0A> =0A> ** OAuth Tutorial=0A> Presenter:=
 Justin Richer=0A> Date: Thursday, February 27, 2014=0A> Time: 1:00 pm, GMT=
 Time (London, GMT)=0A> Meeting Number: 646 901 997=0A> Meeting Password: j=
ustin=0A> Online meeting:=0A> https://ietf.webex.co/ietf/j.php?MTID=3Dm51cd=
ea08122259237c6193380a3ccdd4=0A> Audio conference information:=0A> - Call-i=
n toll number (US/Canada): 1-650-479-3208=0A> - Access code:646 901 997=0A>=
 To add this meeting to your calendar program=0A> https://ietf.webex.co/iet=
f/j.php?MTID=3Dm8bcee257eb3ab56e51c9b02c5b63b123=0A> =0A> Ciao=0A> Hannes=
=0A> =0A> PS: I was told that the IETF Webex bridge does not offer other di=
al-in=0A> numbers. If you want to dial-in from remote please use Skype or s=
ome=0A> other VoIP tool to keep the costs at a reasonable level.=0A> =0A> =
=0A> =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.ietf.org/mailman/listinfo/oauth
--1397251415-1130842307-1393345040=:8248
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


I haven't heard the time or place of the Connect m=
eeting, and I'd come to both.  FYI my plane doesn't land until 10:30 I=
 think.
 =

 
 
 
 
  On Monday, February 24, 2014 11:32 PM, John Bradley <ve7jtb=
@ve7jtb.com> wrote:
  
  
H=
annes,

Is the OAuth Proof of possessio=
n meeting going to be at 10am Sunday March 2?

I was
 talking to some WG members yesterday who thought that we were meeting in t=
he afternoon after the Connect meeting.

John B.
=

On Feb 25, 2014, at 12:53 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

> Hi all,
> 
> in preparation for the ACE BOF at this IETF I thought it wou=
ld be useful
> to have some tutorials about relevant I=
ETF technologies.
> These tutorials will take place th=
is week (via Webex, 1 hour session).
> 
> In case you are not on the IETF ACE mailing list I thought it make=
s
> sense to forward it also to SAAG.
> 
> **
 Kerberos Tutorial
> Presenter: Thomas Hardjono
> Date: Tuesday, February 25, 2014
> Ti=
me: 1:00 pm, GMT Time (London, GMT)
> Meeting Number: =
644 999 834
> Meeting Password: kerberos
> Online meeting:
> https://ietf.webex.com/ietf/j.php?MTID=3Dm1ece1ae3939e5d=
85a28b2b235160458c
> Audio conference information<=
br clear=3D"none">> - Call-in toll number (US/Canada): 1-650-479-3208> - Access code:644 999 834
> To ad=
d this meeting to your calendar program:
> https://ietf.webex.com/ietf/j.php?MTID=3Dmbf017fcbf20fad=
698c6f2b5b704c3847
> 
> ** PK=
I Tutorial
> Presenter: Sean Turner
=
> Date: Wednesday, February 26, 2014
> Time: 1:00 p=
m, GMT Time (London, GMT)
> Meeting Number: 647 365 24=
4
> Meeting Password: sean
> 
> Online meeting:
> https://ietf.webex.co/ietf/j.php?MTID=3Dmc596ba=
f62b263e8a7ced4831061a994d
> Audio conference info=
rmation
> - Call-in toll number (US/Canada): 1-650-479=
-3208
> - Access code:647 365 244
&g=
t; To add this meeting to your calendar program:
> https://ietf.webex.co/ietf/j.php?MTID=3Dma0d75a1=
9ae69ce587599dcb25dc48d04
> 
>=
; ** OAuth Tutorial
> Presenter: Justin Richer
> Date: Thursday, February 27, 2014
> Ti=
me: 1:00 pm, GMT Time (London, GMT)
> Meeting Number: =
646 901 997
> Meeting Password: justin
> Online meeting:
> https://ietf.webex.co/ietf/j.php?MTID=3Dm51cdea08122259237c=
6193380a3ccdd4
> Audio conference information:
> - Call-in toll number (US/Canada): 1-650-479-3208
> - Access code:646 901 997
> To add t=
his meeting to your calendar
 program
> https://ietf.webex.co/ietf/j.php?MTID=3Dm8bcee257eb3ab56e51c9b02c5b63b123<=
/a>
> 
> Ciao
&=
gt; Hannes
> 
> PS: I was told th=
at the IETF Webex bridge does not offer other dial-in
>=
; numbers. If you want to dial-in from remote please use Skype or some
> other VoIP tool to keep the costs at a reasonable level.=

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

________=
_______________________________________
OAuth mailing lis=
t
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


  
 
  
 

--1397251415-1130842307-1393345040=:8248--


From nobody Tue Feb 25 08:29:11 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B139A1A0056 for ; Tue, 25 Feb 2014 08:29:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VF9YRBQbuv7q for ; Tue, 25 Feb 2014 08:29:08 -0800 (PST)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id D4A181A00EA for ; Tue, 25 Feb 2014 08:29:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6C1E0E2033; Tue, 25 Feb 2014 11:29:06 -0500 (EST)
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 04418-08; Tue, 25 Feb 2014 11:29:03 -0500 (EST)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id 9EA3DE2034; Tue, 25 Feb 2014 11:29:03 -0500 (EST)
Received: from 192.168.248.230 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 25 Feb 2014 11:29:03 -0500
Message-ID: 
In-Reply-To: <1393345040.8248.YahooMailNeo@web142802.mail.bf1.yahoo.com>
References: <530BDB5F.5030400@gmx.net> <530BDB7E.9020302@gmx.net> <2AE29C39-808C-46D8-8002-98989467FFC3@ve7jtb.com> <1393345040.8248.YahooMailNeo@web142802.mail.bf1.yahoo.com>
Date: Tue, 25 Feb 2014 11:29:03 -0500
From: "Derek Atkins" 
To: "Bill Mills" 
User-Agent: SquirrelMail/1.4.22-13.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JF4AlaYY0hTdG0NBbP6gfJrEAXA
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Fwd: Tutorials (OAuth, Kerberos, PKI) for ACE BOF Preparation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 16:29:10 -0000

My understanding is that OAuth will meet *before* Connect on Sunday,
starting at 10am (or was it 10:30?)

-derek

On Tue, February 25, 2014 11:17 am, Bill Mills wrote:
> I haven't heard the time or place of the Connect meeting, and I'd come to
> both.  FYI my plane doesn't land until 10:30 I think.
>
>
>
> On Monday, February 24, 2014 11:32 PM, John Bradley 
> wrote:
>
> Hannes,
>
> Is the OAuth Proof of possession meeting going to be at 10am Sunday March
> 2?
>
> I was talking to some WG members yesterday who thought that we were
> meeting in the afternoon after the Connect meeting.
>
> John B.
>
>
> On Feb 25, 2014, at 12:53 AM, Hannes Tschofenig
>  wrote:
>
>> Hi all,
>>
>> in preparation for the ACE BOF at this IETF I thought it would be useful
>> to have some tutorials about relevant IETF technologies.
>> These tutorials will take place this week (via Webex, 1 hour session).
>>
>> In case you are not on the IETF ACE mailing list I thought it makes
>> sense to forward it also to SAAG.
>>
>> ** Kerberos Tutorial
>> Presenter: Thomas Hardjono
>> Date: Tuesday, February 25, 2014
>> Time: 1:00 pm, GMT Time (London, GMT)
>> Meeting Number: 644 999 834
>> Meeting Password: kerberos
>> Online meeting:
>> https://ietf.webex.com/ietf/j.php?MTID=m1ece1ae3939e5d85a28b2b235160458c
>> Audio conference information
>> - Call-in toll number (US/Canada): 1-650-479-3208
>> - Access code:644 999 834
>> To add this meeting to your calendar program:
>> https://ietf.webex.com/ietf/j.php?MTID=mbf017fcbf20fad698c6f2b5b704c3847
>>
>> ** PKI Tutorial
>> Presenter: Sean Turner
>> Date: Wednesday, February 26, 2014
>> Time: 1:00 pm, GMT Time (London, GMT)
>> Meeting Number: 647 365 244
>> Meeting Password: sean
>>
>> Online meeting:
>> https://ietf.webex.co/ietf/j.php?MTID=mc596baf62b263e8a7ced4831061a994d
>> Audio conference information
>> - Call-in toll number (US/Canada): 1-650-479-3208
>> - Access code:647 365 244
>> To add this meeting to your calendar program:
>> https://ietf.webex.co/ietf/j.php?MTID=ma0d75a19ae69ce587599dcb25dc48d04
>>
>> ** OAuth Tutorial
>> Presenter: Justin Richer
>> Date: Thursday, February 27, 2014
>> Time: 1:00 pm, GMT Time (London, GMT)
>> Meeting Number: 646 901 997
>> Meeting Password: justin
>> Online meeting:
>> https://ietf.webex.co/ietf/j.php?MTID=m51cdea08122259237c6193380a3ccdd4
>> Audio conference information:
>> - Call-in toll number (US/Canada): 1-650-479-3208
>> - Access code:646 901 997
>> To add this meeting to your calendar program
>> https://ietf.webex.co/ietf/j.php?MTID=m8bcee257eb3ab56e51c9b02c5b63b123
>>
>> Ciao
>> Hannes
>>
>> PS: I was told that the IETF Webex bridge does not offer other dial-in
>> numbers. If you want to dial-in from remote please use Skype or some
>> other VoIP tool to keep the costs at a reasonable level.
>>
>>
>>
>> _______________________________________________
>> 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
>


-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant


From nobody Tue Feb 25 09:19:08 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3501A014C for ; Tue, 25 Feb 2014 09:19:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FU1gJToHUsA1 for ; Tue, 25 Feb 2014 09:19:02 -0800 (PST)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id BBDE61A0118 for ; Tue, 25 Feb 2014 09:19:01 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id e4so1052343wiv.16 for ; Tue, 25 Feb 2014 09:19:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Q1fcPu0gqwDRHdYIbCujAQgs3TOc+P0dHwdNcpR2Nw8=; b=fN8IysQXEFEuiUXWojSCno3dNLPyAlYxJN7NdR2YVTHr43JrPTtk0rjz/Q0t06jvr7 PrLXD3zNiPBbGPa2BnIH20uXIdH4sxPQUQ86c6JKAOF5tqi9pujBdpl4yEFEkKq2zRGp jg04BJ1AwfRJU/r7cRdVaEYgFB/OZnAidr9f9LtOy+hAKITuls4fXQWR9VF7rI9J7wTO HXT89JcUGBbvIHsNJdmSoGD5tY++2jkQEGQrNkFsHEGwJuPmFOgFc4+fYZTJOmq7o61J 0y9218EmBZAvNo2Ij64t1Rm19oe3+3a6j+egfHsbCnv9wIBEYAzxTkjKilCSV2DkP3TA 1gXw==
X-Gm-Message-State: ALoCoQmxRkUSIMa2mgC9NhbTj3B4zQP9rxZ+shL4noSyYFxbDLh11sS4tACfyFLy74+Ks3RVy2ZC
X-Received: by 10.180.99.39 with SMTP id en7mr1133964wib.10.1393348740090; Tue, 25 Feb 2014 09:19:00 -0800 (PST)
Received: from [10.233.77.97] ([149.7.216.40]) by mx.google.com with ESMTPSA id f1sm36466765wik.1.2014.02.25.09.18.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 09:18:58 -0800 (PST)
References: <530BDB5F.5030400@gmx.net> <530BDB7E.9020302@gmx.net> <2AE29C39-808C-46D8-8002-98989467FFC3@ve7jtb.com> <1393345040.8248.YahooMailNeo@web142802.mail.bf1.yahoo.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1393345040.8248.YahooMailNeo@web142802.mail.bf1.yahoo.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-C4843ED8-BDBD-4B91-90F9-7EEF9C469E88
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (11B651)
From: John Bradley 
Date: Tue, 25 Feb 2014 18:18:57 +0100
To: Bill Mills 
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/yJbrAs-UIVn_qCQKMFtX26YCqSw
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Fwd: Tutorials (OAuth, Kerberos, PKI) for ACE BOF Preparation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 17:19:05 -0000

--Apple-Mail-C4843ED8-BDBD-4B91-90F9-7EEF9C469E88
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

The link for the OpenID meeting is
https://www.eventbrite.com/e/openid-meeting-at-ietf-89-tickets-10651772739



Sent from my iPhone

> On Feb 25, 2014, at 5:17 PM, Bill Mills  wrote:
>=20
> I haven't heard the time or place of the Connect meeting, and I'd come to b=
oth.  FYI my plane doesn't land until 10:30 I think.
>=20
>=20
> On Monday, February 24, 2014 11:32 PM, John Bradley  wr=
ote:
> Hannes,
>=20
> Is the OAuth Proof of possession meeting going to be at 10am Sunday March 2=
?
>=20
> I was talking to some WG members yesterday who thought that we were meetin=
g in the afternoon after the Connect meeting.
>=20
> John B.
>=20
> On Feb 25, 2014, at 12:53 AM, Hannes Tschofenig  wrote:
>=20
> > Hi all,
> >=20
> > in preparation for the ACE BOF at this IETF I thought it would be useful=

> > to have some tutorials about relevant IETF technologies.
> > These tutorials will take place this week (via Webex, 1 hour session).
> >=20
> > In case you are not on the IETF ACE mailing list I thought it makes
> > sense to forward it also to SAAG.
> >=20
> > ** Kerberos Tutorial
> > Presenter: Thomas Hardjono
> > Date: Tuesday, February 25, 2014
> > Time: 1:00 pm, GMT Time (London, GMT)
> > Meeting Number: 644 999 834
> > Meeting Password: kerberos
> > Online meeting:
> > https://ietf.webex.com/ietf/j.php?MTID=3Dm1ece1ae3939e5d85a28b2b23516045=
8c
> > Audio conference information
> > - Call-in toll number (US/Canada): 1-650-479-3208
> > - Access code:644 999 834
> > To add this meeting to your calendar program:
> > https://ietf.webex.com/ietf/j.php?MTID=3Dmbf017fcbf20fad698c6f2b5b704c38=
47
> >=20
> > ** PKI Tutorial
> > Presenter: Sean Turner
> > Date: Wednesday, February 26, 2014
> > Time: 1:00 pm, GMT Time (London, GMT)
> > Meeting Number: 647 365 244
> > Meeting Password: sean
> >=20
> > Online meeting:
> > https://ietf.webex.co/ietf/j.php?MTID=3Dmc596baf62b263e8a7ced4831061a994=
d
> > Audio conference information
> > - Call-in toll number (US/Canada): 1-650-479-3208
> > - Access code:647 365 244
> > To add this meeting to your calendar program:
> > https://ietf.webex.co/ietf/j.php?MTID=3Dma0d75a19ae69ce587599dcb25dc48d0=
4
> >=20
> > ** OAuth Tutorial
> > Presenter: Justin Richer
> > Date: Thursday, February 27, 2014
> > Time: 1:00 pm, GMT Time (London, GMT)
> > Meeting Number: 646 901 997
> > Meeting Password: justin
> > Online meeting:
> > https://ietf.webex.co/ietf/j.php?MTID=3Dm51cdea08122259237c6193380a3ccdd=
4
> > Audio conference information:
> > - Call-in toll number (US/Canada): 1-650-479-3208
> > - Access code:646 901 997
> > To add this meeting to your calendar  program
> > https://ietf.webex.co/ietf/j.php?MTID=3Dm8bcee257eb3ab56e51c9b02c5b63b12=
3
> >=20
> > Ciao
> > Hannes
> >=20
> > PS: I was told that the IETF Webex bridge does not offer other dial-in
> > numbers. If you want to dial-in from remote please use Skype or some
> > other VoIP tool to keep the costs at a reasonable level.
> >=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
>=20
>=20

--Apple-Mail-C4843ED8-BDBD-4B91-90F9-7EEF9C469E88
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


The link for the OpenID meeting is



Sent from my iPhone

On Feb 25, 2014, at 5:17 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

<=
span>I haven't heard the time or place of the Connect meeting, and I'd come t=
o both.  FYI my plane doesn't land until 10:30 I think.
 
 
 
 
 
  On Monday, Febr=
uary 24, 2014 11:32 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
  
  
Hannes,

Is the OAuth Proof of=
 possession meeting going to be at 10am Sunday March 2?
I was
 talking to some WG members yesterday who thought that we were meeting in th=
e afternoon after the Connect meeting.

=
John B.
On Feb 25, 2014, at 12:53 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

> Hi all,
> 
> in preparation for the ACE BOF at this IETF I thought it would be use=
ful
> to have some tutorials about relevant IETF techno=
logies.
> These tutorials will take place this week (vi=
a Webex, 1 hour session).
> 
> In c=
ase you are not on the IETF ACE mailing list I thought it makes
> sense to forward it also to SAAG.
> 
> **
 Kerberos Tutorial
> Presenter: Thomas Hardjono
> Date: Tuesday, February 25, 2014
> Time=
: 1:00 pm, GMT Time (London, GMT)
> Meeting Number: 644=
 999 834
> Meeting Password: kerberos
> Online meeting:
> https://ietf.webex.com/ietf/j.php?MTID=3Dm1ece1ae3939e5d85a28b2=
b235160458c
> Audio conference information
> - Call-in toll number (US/Canada): 1-650-479-3208
> - Access code:644 999 834
> To add this mee=
ting to your calendar program:
> https://ietf.webex.com/ietf/j.php?MTID=3Dmbf017fcbf20f=
ad698c6f2b5b704c3847
> 
> ** P=
KI Tutorial
> Presenter: Sean Turner
=
> Date: Wednesday, February 26, 2014
> Time: 1:00 pm=
, GMT Time (London, GMT)
> Meeting Number: 647 365 244<=
br clear=3D"none">> Meeting Password: sean
> 
> Online meeting:
> https://ietf.webex.co/ietf/j.php?MTID=3Dmc596baf62b26=
3e8a7ced4831061a994d
> Audio conference information=

> - Call-in toll number (US/Canada): 1-650-479-3208> - Access code:647 365 244
> To add=
 this meeting to your calendar program:
> https://ietf.webex.co/ietf/j.php?MTID=3Dma0d75=
a19ae69ce587599dcb25dc48d04
> 
&g=
t; ** OAuth Tutorial
> Presenter: Justin Richer
> Date: Thursday, February 27, 2014
> Tim=
e: 1:00 pm, GMT Time (London, GMT)
> Meeting Number: 64=
6 901 997
> Meeting Password: justin
=
> Online meeting:
> https://ietf.webex.co/ietf/j.php?MTID=3Dm51cdea08122259237c6193380a=
3ccdd4
> Audio conference information:
> - Call-in toll number (US/Canada): 1-650-479-3208
> - Access code:646 901 997
> To add this meeting=
 to your calendar
 program
> h=
ttps://ietf.webex.co/ietf/j.php?MTID=3Dm8bcee257eb3ab56e51c9b02c5b63b123=

> 
> Ciao
> H=
annes
> 
> PS: I was told that the=
 IETF Webex bridge does not offer other dial-in
> numbe=
rs. If you want to dial-in from remote please use Skype or some
> other VoIP tool to keep the costs at a reasonable level.
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oaut=
h

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


  
 
  
 
=

--Apple-Mail-C4843ED8-BDBD-4B91-90F9-7EEF9C469E88--


From nobody Tue Feb 25 09:22:37 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92941A0111 for ; Tue, 25 Feb 2014 09:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSJ-JEeSSyMS for ; Tue, 25 Feb 2014 09:22:32 -0800 (PST)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5583D1A0118 for ; Tue, 25 Feb 2014 09:22:32 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id f8so4819149wiw.1 for ; Tue, 25 Feb 2014 09:22:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Y+v5ChqS7cHbZZtxAiuoNqNdwHUNUppj0zph8B64A/A=; b=f7iR0cuOq/UbrKgXGq8uuQh7saK3jAfRtkCYpvptVw9vdDT+u8enZ+k5s1Rf6DqUMq B5gNLOGV63aDqhmk/Hf8BLBsXjAutrhrRNyCtzksw1RKcn/5j8Lf9TpMrv1WhsgKAOK1 YeBKG+p9n2jGRUyEnLjW40vextwUnNq9PtTstYIwk00VFqPvXnDjdOPTwNF7Nzwab6cp dS9IFYt2s5FrXFoeVX9eOUbkJ3xpShlTwsTcYFNqpoAN29MHkosdggp+PQWVKw7q/owE PRQTfNI1MpStLYYT4z+o0KLM1hhhkW3r8JKeCoaHX+iD2JDGib2kqC498OisLQlhnEFG WkQA==
X-Gm-Message-State: ALoCoQmhLItldojrz2CwqWntWFBKYolsreNpF3/EkoDz8rhoHn4/AmQMdq29aLGe1uENXDMwHRHw
X-Received: by 10.180.105.65 with SMTP id gk1mr1153732wib.12.1393348950914; Tue, 25 Feb 2014 09:22:30 -0800 (PST)
Received: from ?IPv6:2001:978:1200:1:84f5:6717:5a38:3631? ([2001:978:1200:1:84f5:6717:5a38:3631]) by mx.google.com with ESMTPSA id ff9sm1908466wib.11.2014.02.25.09.22.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 09:22:29 -0800 (PST)
References: <530BDB5F.5030400@gmx.net> <530BDB7E.9020302@gmx.net> <2AE29C39-808C-46D8-8002-98989467FFC3@ve7jtb.com> <1393345040.8248.YahooMailNeo@web142802.mail.bf1.yahoo.com> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (11B651)
From: John Bradley 
Date: Tue, 25 Feb 2014 18:22:28 +0100
To: Derek Atkins 
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FdF_2qhLSkfzmesMWNVb4sHkt4c
Cc: "oauth@ietf.org list" 
Subject: Re: [OAUTH-WG] Fwd: Tutorials (OAuth, Kerberos, PKI) for ACE BOF Preparation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 17:22:35 -0000

The room was booked for 10am.=20

You or Hannes can pick the start time as you like.=20

John B.=20

Sent from my iPhone

> On Feb 25, 2014, at 5:29 PM, "Derek Atkins"  wrote:
>=20
> My understanding is that OAuth will meet *before* Connect on Sunday,
> starting at 10am (or was it 10:30?)
>=20
> -derek
>=20
>> On Tue, February 25, 2014 11:17 am, Bill Mills wrote:
>> I haven't heard the time or place of the Connect meeting, and I'd come to=

>> both.  FYI my plane doesn't land until 10:30 I think.
>>=20
>>=20
>>=20
>> On Monday, February 24, 2014 11:32 PM, John Bradley 
>> wrote:
>>=20
>> Hannes,
>>=20
>> Is the OAuth Proof of possession meeting going to be at 10am Sunday March=

>> 2?
>>=20
>> I was talking to some WG members yesterday who thought that we were
>> meeting in the afternoon after the Connect meeting.
>>=20
>> John B.
>>=20
>>=20
>> On Feb 25, 2014, at 12:53 AM, Hannes Tschofenig
>>  wrote:
>>=20
>>> Hi all,
>>>=20
>>> in preparation for the ACE BOF at this IETF I thought it would be useful=

>>> to have some tutorials about relevant IETF technologies.
>>> These tutorials will take place this week (via Webex, 1 hour session).
>>>=20
>>> In case you are not on the IETF ACE mailing list I thought it makes
>>> sense to forward it also to SAAG.
>>>=20
>>> ** Kerberos Tutorial
>>> Presenter: Thomas Hardjono
>>> Date: Tuesday, February 25, 2014
>>> Time: 1:00 pm, GMT Time (London, GMT)
>>> Meeting Number: 644 999 834
>>> Meeting Password: kerberos
>>> Online meeting:
>>> https://ietf.webex.com/ietf/j.php?MTID=3Dm1ece1ae3939e5d85a28b2b23516045=
8c
>>> Audio conference information
>>> - Call-in toll number (US/Canada): 1-650-479-3208
>>> - Access code:644 999 834
>>> To add this meeting to your calendar program:
>>> https://ietf.webex.com/ietf/j.php?MTID=3Dmbf017fcbf20fad698c6f2b5b704c38=
47
>>>=20
>>> ** PKI Tutorial
>>> Presenter: Sean Turner
>>> Date: Wednesday, February 26, 2014
>>> Time: 1:00 pm, GMT Time (London, GMT)
>>> Meeting Number: 647 365 244
>>> Meeting Password: sean
>>>=20
>>> Online meeting:
>>> https://ietf.webex.co/ietf/j.php?MTID=3Dmc596baf62b263e8a7ced4831061a994=
d
>>> Audio conference information
>>> - Call-in toll number (US/Canada): 1-650-479-3208
>>> - Access code:647 365 244
>>> To add this meeting to your calendar program:
>>> https://ietf.webex.co/ietf/j.php?MTID=3Dma0d75a19ae69ce587599dcb25dc48d0=
4
>>>=20
>>> ** OAuth Tutorial
>>> Presenter: Justin Richer
>>> Date: Thursday, February 27, 2014
>>> Time: 1:00 pm, GMT Time (London, GMT)
>>> Meeting Number: 646 901 997
>>> Meeting Password: justin
>>> Online meeting:
>>> https://ietf.webex.co/ietf/j.php?MTID=3Dm51cdea08122259237c6193380a3ccdd=
4
>>> Audio conference information:
>>> - Call-in toll number (US/Canada): 1-650-479-3208
>>> - Access code:646 901 997
>>> To add this meeting to your calendar program
>>> https://ietf.webex.co/ietf/j.php?MTID=3Dm8bcee257eb3ab56e51c9b02c5b63b12=
3
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>> PS: I was told that the IETF Webex bridge does not offer other dial-in
>>> numbers. If you want to dial-in from remote please use Skype or some
>>> other VoIP tool to keep the costs at a reasonable level.
>>>=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______________________________=
_________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> --=20
>       Derek Atkins                 617-623-3745
>       derek@ihtfp.com             www.ihtfp.com
>       Computer and Internet Security Consultant
>=20


From nobody Tue Feb 25 09:23:13 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2631A0111 for ; Tue, 25 Feb 2014 09:23:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.177
X-Spam-Level: **
X-Spam-Status: No, score=2.177 tagged_above=-999 required=5 tests=[BAYES_80=2,  FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723,  RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEFbCFA4A77T for ; Tue, 25 Feb 2014 09:23:08 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id CBBFD1A0118 for ; Tue, 25 Feb 2014 09:23:07 -0800 (PST)
Received: from [217.140.96.21] by 3capp-gmx-bs24 with HTTP; Tue, 25 Feb 2014 18:23:05 +0100
MIME-Version: 1.0
Message-ID: 
From: "Hannes Tschofenig" 
To: oauth@ietf.org
Content-Type: text/html; charset=UTF-8
Date: Tue, 25 Feb 2014 18:23:05 +0100
Importance: normal
Sensitivity: Normal
X-Priority: 3
X-Provags-ID: V03:K0:ldRHhsGn4sQAZOy4Dcxgw3qOyh8dMIyonCurdP7Y+ai LN8uG/zWKW7ieBc4IKq4zC+Oebqfxw8Qccszk3Di7uCYGn9YKb 99SDzbOeJD0pWBZ1F+HzVk61iMsZVLzHgHQIn5RU2yoES6BEG4 FFziB5r5gGSgNAeAzmk1XsikdmO6rW6ascXJYRnQNc0AAPb3oa QW5CZy/IG9wA8Ts2YCt+5E6wTu7RNbV5xlWCjaxT3ZXfom2jKu /WgHCE8HFvlZ70tlsIuHZeMR3cbDfan9NY9q9OFysMb5ZbC4dP mcmPEA=
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8eczNtEwwbOoqZOkPZ91P8CAjQw
Subject: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 17:23:09 -0000


Hi all, 



 



Lucy organized a room for our informal discussion about OAuth (followed by the OpenID Connect meeting). We will start at 10am and the room is reserved till 3pm. Palace C is the meeting room. At some point in time the OAuth meeting will turn into the OpenID Connect meeting. For those who are interested I will give a privacy tutorial at 3pm in the Blenheim room. 



 



Mike, Nat, John, and others might have more information about the agenda for the OpenID Connect meeting. For the OAuth meeting Derek and I were planning to use the time to prepare the security discussions for the official OAuth WG meeting. I am sure we will arrange further meeting slots during the week to give enough room for socializing and generating new ideas.  



 



Ciao

Hannes



 



From nobody Tue Feb 25 11:17:09 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC261A01F4 for ; Tue, 25 Feb 2014 11:17:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.013
X-Spam-Level: 
X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITuxxX5xmwEZ for ; Tue, 25 Feb 2014 11:16:59 -0800 (PST)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCB51A01D3 for ; Tue, 25 Feb 2014 11:16:58 -0800 (PST)
Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUwzsKVUwpe9NX5QIx65PF+ch0Xa2/pnO@postini.com; Tue, 25 Feb 2014 11:16:58 PST
Received: by mail-ie0-f179.google.com with SMTP id to1so771853ieb.38 for ; Tue, 25 Feb 2014 11:16:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZqETa+CQxG6Jc3cD62Cl4j9J8wPU130sUJb4BhEuAx8=; b=K2sSvZtzfLVGUrairk+pwdX6JdnCvnAFFVemcYdemge9g0YSzFpC6px/cbkS4BjLvA wynUP57YIxwVacHph/jVtA7Nf5u+nt5FFzffgQ21BC/lXmQkPzpfEWri5EEidmp6m88e aZ6MegmYiNMH/otZMnLD2OAR/IXcoU5tkVH+Nk/EBI12Len6/x1TQRaxH6AsRuYTp4AD M2wsu8mXPEHrIjVp5sY6zmmQy3qY4/PFD2Ro+UNZogiMyZPgdjzgdiOx981YPezJusXZ 65ZVBtcayZE9CWMmxI0ZiwP5hZi26JzsFbZZbwhWBsgVVmwwBqS0uSqw53BqusYI58/K yVmQ==
X-Gm-Message-State: ALoCoQkB+MkYYrGWQEXKNHth2SmfYOQya7wJn7xN3DJdHF4RFqjHO6wIZ/GZQg7pSKGp5TUpRw3inbbaUPxUFDPQ9IBwCUHrRAtej82aVZ5L6409IwHATEWiqDklg5RQXVpdBfM40xH55woN01OekDc/V9u+OHcBBg==
X-Received: by 10.50.47.110 with SMTP id c14mr5619123ign.4.1393355816416; Tue, 25 Feb 2014 11:16:56 -0800 (PST)
X-Received: by 10.50.47.110 with SMTP id c14mr5619102ign.4.1393355816313; Tue, 25 Feb 2014 11:16:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.65.4 with HTTP; Tue, 25 Feb 2014 11:16:26 -0800 (PST)
In-Reply-To: 
References: 
From: Brian Campbell 
Date: Tue, 25 Feb 2014 12:16:26 -0700
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=089e013d0dca7a961b04f33feeb5
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jgRGNhTSDhZl0Q3CB0puS_48IhE
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 19:17:01 -0000

--089e013d0dca7a961b04f33feeb5
Content-Type: text/plain; charset=ISO-8859-1

Wasn't this originally announced with a different start time and Connect
and OAuth happening in the opposite order?


On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig <
Hannes.Tschofenig@gmx.net> wrote:

> Hi all,
>
> Lucy organized a room for our informal discussion about OAuth (followed by
> the OpenID Connect meeting). We will start at 10am and the room is reserved
> till 3pm. Palace C is the meeting room. At some point in time the OAuth
> meeting will turn into the OpenID Connect meeting. For those who are
> interested I will give a privacy tutorial at 3pm in the Blenheim room.
>
> Mike, Nat, John, and others might have more information about the agenda
> for the OpenID Connect meeting. For the OAuth meeting Derek and I were
> planning to use the time to prepare the security discussions for the
> official OAuth WG meeting. I am sure we will arrange further meeting slots
> during the week to give enough room for socializing and generating new
> ideas.
>
> Ciao
> Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--089e013d0dca7a961b04f33feeb5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Wasn't this originally announced with a different star=
t time and Connect and OAuth happening in the opposite order?


On Tue, Feb 25, 2=
014 at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net&=
gt; wrote:



Hi all,=A0



=A0



Lucy organized a room for our informal discussion about OAuth (followe=
d by the OpenID Connect meeting). We will start at 10am and the room is res=
erved till 3pm. Palace C is the meeting room. At some point in time the OAu=
th meeting will turn into the OpenID Connect meeting. For those who are int=
erested I will give a privacy tutorial at 3pm in the Blenheim room.=A0




=A0



Mike, Nat, John, and others might have more information about the agen=
da for the OpenID Connect meeting. For the OAuth meeting Derek and I were p=
lanning to use the time to prepare the security discussions for the officia=
l OAuth WG meeting. I am sure we will arrange further meeting slots during =
the week to give enough room for socializing and generating new ideas. =A0<=
/div>




=A0



Ciao

Hannes



=A0



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--089e013d0dca7a961b04f33feeb5--


From nobody Tue Feb 25 11:58:48 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2BA1A0243 for ; Tue, 25 Feb 2014 11:58:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9wB3v0uR0Ml for ; Tue, 25 Feb 2014 11:58:35 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A30A81A01CA for ; Tue, 25 Feb 2014 11:58:35 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id w7so9392919qcr.31 for ; Tue, 25 Feb 2014 11:58:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Z5QB45AOBluIhPfKjulBDROjPDBKDB793VNYBK0HsJc=; b=NPRMvze+ErfjrgmjcZMIzjP5/XyZKFew2tYmFfPOihcHxrjnyLAk9uZL0LRo163V0U YVsPCYNAeDaaNtDFFfqjfOd/wJuo28QyGM2/qO3DZb5eGHOmZALPGaaRjUdRHU6mSm2F qjXI9xuhNZXWECW2BTPyWpD7SaINiA2nPOFURJUYQ/q14CSeQLmDdZF9mTiwQOKCTgAR H5OYv6j/FxyGAkchCailxWfWDRGPO7QA/TOuXQVTyc28sfWLYmvDpJgvki6nGvpmCg+2 d1ln6Vt3zlyl2JogfN+TZKgSVvHe6Haw9NFxhX1qZFuLYeMI7IXcdc0HrAiOJe2ccIMF TjIA==
X-Gm-Message-State: ALoCoQmSoOR0Hni8hAildSC2KA4+I1pXmd5H40K3d9toLdGizlMNhspJza6uIsS0Vy8zRcw5GCSC
X-Received: by 10.140.20.17 with SMTP id 17mr2602525qgi.28.1393358314509; Tue, 25 Feb 2014 11:58:34 -0800 (PST)
Received: from [10.171.187.233] (111.sub-70-194-70.myvzw.com. [70.194.70.111]) by mx.google.com with ESMTPSA id t5sm2828361qat.6.2014.02.25.11.58.30 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 11:58:33 -0800 (PST)
References:  
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-FD08739E-DB0E-4079-BFFE-C1B03C5CE238
Content-Transfer-Encoding: 7bit
Message-Id: <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>
X-Mailer: iPhone Mail (11B651)
From: John Bradley 
Date: Tue, 25 Feb 2014 20:58:26 +0100
To: Brian Campbell 
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Ro60R4zWFeY8yWZnxToPJVR8JqQ
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 19:58:40 -0000

--Apple-Mail-FD08739E-DB0E-4079-BFFE-C1B03C5CE238
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Yes.=20

Things change that's life.=20



Sent from my iPhone

> On Feb 25, 2014, at 8:16 PM, Brian Campbell  w=
rote:
>=20
> Wasn't this originally announced with a different start time and Connect a=
nd OAuth happening in the opposite order?
>=20
>=20
>> On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig  wrote:
>> Hi all,=20
>> =20
>> Lucy organized a room for our informal discussion about OAuth (followed b=
y the OpenID Connect meeting). We will start at 10am and the room is reserve=
d till 3pm. Palace C is the meeting room. At some point in time the OAuth me=
eting will turn into the OpenID Connect meeting. For those who are intereste=
d I will give a privacy tutorial at 3pm in the Blenheim room.=20
>> =20
>> Mike, Nat, John, and others might have more information about the agenda f=
or the OpenID Connect meeting. For the OAuth meeting Derek and I were planni=
ng to use the time to prepare the security discussions for the official OAut=
h WG meeting. I am sure we will arrange further meeting slots during the wee=
k to give enough room for socializing and generating new ideas. =20
>> =20
>> Ciao
>> Hannes
>> =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-FD08739E-DB0E-4079-BFFE-C1B03C5CE238
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


Yes. 

Things change that's life. 



Sent from my iPhone

On Feb 25, 2014, at 8:16 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Wasn't this originally announced with a different start time and Connect and OAuth happening in the opposite order?


On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:



Hi all, 



 



Lucy organized a room for our informal discussion about OAuth (followed by the OpenID Connect meeting). We will start at 10am and the room is reserved till 3pm. Palace C is the meeting room. At some point in time the OAuth meeting will turn into the OpenID Connect meeting. For those who are interested I will give a privacy tutorial at 3pm in the Blenheim room. 





 



Mike, Nat, John, and others might have more information about the agenda for the OpenID Connect meeting. For the OAuth meeting Derek and I were planning to use the time to prepare the security discussions for the official OAuth WG meeting. I am sure we will arrange further meeting slots during the week to give enough room for socializing and generating new ideas.  





 



Ciao

Hannes



 



_______________________________________________

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-FD08739E-DB0E-4079-BFFE-C1B03C5CE238--


From nobody Tue Feb 25 12:17:11 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA011A0207 for ; Tue, 25 Feb 2014 12:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.146
X-Spam-Level: 
X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omMTMpyLWWTf for ; Tue, 25 Feb 2014 12:17:02 -0800 (PST)
Received: from nm32-vm4.bullet.mail.bf1.yahoo.com (nm32-vm4.bullet.mail.bf1.yahoo.com [72.30.239.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5341A01EA for ; Tue, 25 Feb 2014 12:17:02 -0800 (PST)
Received: from [98.139.215.143] by nm32.bullet.mail.bf1.yahoo.com with NNFMP;  25 Feb 2014 20:17:01 -0000
Received: from [98.139.212.220] by tm14.bullet.mail.bf1.yahoo.com with NNFMP;  25 Feb 2014 20:17:01 -0000
Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 25 Feb 2014 20:17:01 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 152667.86299.bm@omp1029.mail.bf1.yahoo.com
Received: (qmail 75800 invoked by uid 60001); 25 Feb 2014 20:17:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1393359421; bh=DMhiFoltytFaqM/JbTHN4ZdFZaxNJ786LEx73RPx+no=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HOLrPePyJqAB2In3QIsr/3l/xVFQirpBpeltWwpJq4Eiaf1x0INwZ4yNFxdf/ATay6irP+ZfCkQx1PP2gaQr8CbCHOhzvny3vUYBymthNv/eQw0/Gkvo3Pf54ooDBSkdWYATi06xC5j1edrCbbjmE9rtMdlavWOXMc2RcV3NN4E=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=au0CpzxpJ2oRoDoQH483cOLIE7nUqWhJmcOsRNYT73N7UDcS54tqYEdLcFnLsrCPbxcc2qSDAXWOnX6z5bvBKHdDo2CSeKparmdbWRlyOGj8W6z0E8qjEwd/Xz6XK7Ptsz7TMFyDRuZ8fi0v3uRDrMvdSB6U+E7TcOQAlPi7MXg=;
X-YMail-OSG: z7RWAqoVM1k2aDWXbbSGhxov0dbml4FVF_RHK1Vc14murJe _2QAczsZG9WclySN2qjkaM08pOdEcrvXmPm44QL0ibpuWD79g4iz_Vj63X4d RikSXoJzNfd9zkN3W6QOO8cfs4bqSzPLYqiE2wQt9NAzkinr3Rr3kSlMGRkO FakoIgBkhceFq3Q4FeLp_6eoEV4EFE3cBQMFWvvtptvd.lVe4PFaNBdHj3Z9 Mmacj4xINe54QrUoyqrXmT8AfkF1a8mbDVP.pqVuuZb1EJi6ajH7StG9Evc7 RHUrt2D8zXPClfGPbEN8LZvz7cfC7CMVqcDhOfFVEpArPU8vXu4t_z07MArD 02x7C7p7iqSeNXAofRhD2nG9_ij81U4jK5vHVJG4n3t0Nd0dGviAcpnPPM5Y whKfxjIq_ZuS237eZzQNlCzw2okyqBQY2YWWrK.YyYVBQXNti8rab_HQIO0P DS2JCQRvu9icl.jTtIJH4zFt41ApPYDvCs1oILh0tJlBL3hNmtH.N_98_32D PmbREXWaIy9NNYtRGjHHIl.8gNdq65VA6FcZUxaea05sLPXjTSXxwwjvag2a tMLNv6lQHkmUOsnzyY4kSWsfB
Received: from [66.228.162.52] by web142805.mail.bf1.yahoo.com via HTTP; Tue, 25 Feb 2014 12:17:00 PST
X-Rocket-MIMEInfo: 002.001, SSdsbCBnZXQgdGhlcmUgYXMgc29vbiBhcyBJIGNhbiBzdWJqZWN0IHRvIGltbWlncmF0aW9uIGFuZCB0aGUgdHViZS4gwqBOb3QgZXZlbiBnb2luZyB0byB0cnkgdG8gZGlhbCBpbiBlbnJvdXRlLgoKCgpPbiBUdWVzZGF5LCBGZWJydWFyeSAyNSwgMjAxNCAxMjoxNCBQTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT4gd3JvdGU6CiAKWWVzLsKgCgpUaGluZ3MgY2hhbmdlIHRoYXQncyBsaWZlLsKgCgoKClNlbnQgZnJvbSBteSBpUGhvbmUKCk9uIEZlYiAyNSwgMjAxNCwgYXQgODoxNiBQTSwgQnIBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.177.636
References:   <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>
Message-ID: <1393359420.51832.YahooMailNeo@web142805.mail.bf1.yahoo.com>
Date: Tue, 25 Feb 2014 12:17:00 -0800 (PST)
From: Bill Mills 
To: John Bradley , Brian Campbell 
In-Reply-To: <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1583497461-611120652-1393359420=:51832"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/OJuPjZbES7Wf_hbXVUGIz1sjvCw
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 20:17:07 -0000

--1583497461-611120652-1393359420=:51832
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I'll get there as soon as I can subject to immigration and the tube. =A0Not=
 even going to try to dial in enroute.=0A=0A=0A=0AOn Tuesday, February 25, =
2014 12:14 PM, John Bradley  wrote:=0A =0AYes.=A0=0A=0AT=
hings change that's life.=A0=0A=0A=0A=0ASent from my iPhone=0A=0AOn Feb 25,=
 2014, at 8:16 PM, Brian Campbell  wrote:=0A=0A=
=0AWasn't this originally announced with a different start time and Connect=
 and OAuth happening in the opposite order?=0A>=0A>=0A>=0A>=0A>On Tue, Feb =
25, 2014 at 10:23 AM, Hannes Tschofenig  wrote:=
=0A>=0A>Hi all,=A0=0A>>=A0=0A>>Lucy organized a room for our informal discu=
ssion about OAuth (followed by the OpenID Connect meeting). We will start a=
t 10am and the room is reserved till 3pm. Palace C is the meeting room. At =
some point in time the OAuth meeting will turn into the OpenID Connect meet=
ing. For those who are interested I will give a privacy tutorial at 3pm in =
the Blenheim room.=A0=0A>>=A0=0A>>Mike, Nat, John, and others might have mo=
re information about the agenda for the OpenID Connect meeting. For the OAu=
th meeting Derek and I were planning to use the time to prepare the securit=
y discussions for the official OAuth WG meeting. I am sure we will arrange =
further meeting slots during the week to give enough room for socializing a=
nd generating new ideas. =A0=0A>>=A0=0A>>Ciao=0A>>Hannes=0A>>=A0=0A>>______=
_________________________________________=0A>>OAuth mailing list=0A>>OAuth@=
ietf.org=0A>>https://www.ietf.org/mailman/listinfo/oauth=0A>>=0A>>=0A>=0A__=
_____________________________________________=0A>OAuth mailing list=0A>OAut=
h@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A___________=
____________________________________=0AOAuth mailing list=0AOAuth@ietf.org=
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
--1583497461-611120652-1393359420=:51832
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


I'll get there as soon as I can subject to immigra=
tion and the tube.  Not even going to try to dial in enroute.
 
 
 
 
 
  On =
Tuesday, February 25, 2014 12:14 PM, John Bradley <ve7jtb@ve7jtb.com>=
 wrote:
  
  
Yes. 

Things change that'=
s life. 



Sent from my iPhone

On Feb
 25, 2014, at 8:16 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

<=
blockquote type=3D"cite">
Wasn't this originally annou=
nced with a different start time and Connect and OAuth happening in the opp=
osite order?


On Tue, Feb 25, 2014 at 10:23 AM, Hannes=
 Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
=0A=0A
Hi all, 
=0A=0A
 
=0A=0ALucy organized a room for our informal discussion about OAuth (followed =
by the OpenID Connect meeting). We will start at 10am and the room is reser=
ved till 3pm. Palace C is the meeting room. At some point in time the OAuth=
 meeting will turn into the OpenID Connect meeting. For those who are inter=
ested I will give a privacy tutorial at 3pm in the Blenheim room. =0A=0A=0A=0A
 
=0A=0A
Mike, Nat, John, and others might=
 have more information about the agenda for the OpenID Connect meeting. For=
 the OAuth meeting Derek and I were planning to use the time to prepare the=
 security discussions for the official OAuth WG meeting. I am sure we will =
arrange further meeting slots during the week to give enough room for socia=
lizing and generating new ideas.  
=0A=0A=0A=0A
 
=
=0A=0A
Ciao=

=0AHannes
=0A=0A
 
=0A=0A<=
br>_______________________________________________
=0AOAuth mailing list=

=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
=0A

=0A
___=
____________________________________________
OAuth mailing =
list
OAuth@ietf.org<=
br>https://www.ietf.org/mailman/listinfo/oauth

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


  
 
  
 
=

--1583497461-611120652-1393359420=:51832--


From nobody Tue Feb 25 14:57:13 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CBE1A07D7 for ; Tue, 25 Feb 2014 14:57:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.913
X-Spam-Level: 
X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC8c33RPyCNa for ; Tue, 25 Feb 2014 14:57:04 -0800 (PST)
Received: from na6sys009bog013.obsmtp.com (na6sys009bog013.obsmtp.com [74.125.150.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA281A07D5 for ; Tue, 25 Feb 2014 14:56:57 -0800 (PST)
Received: from mail-ie0-f174.google.com ([209.85.223.174]) (using TLSv1) by na6sys009bob013.postini.com ([74.125.148.12]) with SMTP ID DSNKUw0fpzpDolwGiEOCtmiF6P6K1AMSJLwn@postini.com; Tue, 25 Feb 2014 14:56:56 PST
Received: by mail-ie0-f174.google.com with SMTP id rp18so11868iec.33 for ; Tue, 25 Feb 2014 14:56:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QZ3kYCQcKWuSylOMVHkdlyvIME8BH4ae4UgtDAysX98=; b=Eoe/Y6bVOb78TNJGrIrXavF1L2F9GeSuGhweMRkw3RHcTeFI0mN/qLmW5g6bRNG4kF ygX1APW9UcNAKvtgIU5cPVFiC7R11OgpJflnrTKnnUUKVDJJzZK9cVdM6z53aCf+q4Di JtO7ktXub75uXN6TpO2ctuauBNmiiTzDWP7XO4EzdUexxt4TEwJVoVpUQoajshp+anm2 IsrBUE5L8V0y4OOgrFsjdeB5rjZX9a7RD7XyF5p2y0pJt2w/9ODcxFr0XPSmH3p+kT/k eXn2rOJLNNd9ebPgQaVSdSCvKugOwpAn1fe/iDY6yX13iZ37KnZELkRQ6xB5VC5Iiz0h ip8w==
X-Gm-Message-State: ALoCoQmUByMZa5eHJvTavSgEEjldIrm+nij+VDpXjpiiLdbNuGXHQ6DuoYQ7nkgif364vKy2qnYEQLKqK7JAqKqDiREc1wo6himYvmOR5M+SktsfOw319nPhANtdUlcAMswKsWAwRKdJ2vl9+pV1IrPR3j6wSnZLrQ==
X-Received: by 10.50.57.1 with SMTP id e1mr22844707igq.42.1393368970829; Tue, 25 Feb 2014 14:56:10 -0800 (PST)
X-Received: by 10.50.57.1 with SMTP id e1mr22844698igq.42.1393368970733; Tue, 25 Feb 2014 14:56:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.65.4 with HTTP; Tue, 25 Feb 2014 14:55:40 -0800 (PST)
In-Reply-To: <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>
References:   <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>
From: Brian Campbell 
Date: Tue, 25 Feb 2014 15:55:40 -0700
Message-ID: 
To: John Bradley 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/yr-G8buriLA5Dyy2O1nMxroysYA
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 22:57:06 -0000

Yes, I'm familiar with life and I'm aware that things do change. And I
have no doubt that scheduling this stuff is more than a little
difficult. But with these Sunday meetings and the vast majority of us
traveling internationally, it'd be really helpful if the timing can be
nailed down as early as is reasonable and changes can be avoided.



On Tue, Feb 25, 2014 at 12:58 PM, John Bradley  wrote:
> Yes.
>
> Things change that's life.
>
>
>
> Sent from my iPhone
>
> On Feb 25, 2014, at 8:16 PM, Brian Campbell 
> wrote:
>
> Wasn't this originally announced with a different start time and Connect and
> OAuth happening in the opposite order?
>
>
> On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig
>  wrote:
>>
>> Hi all,
>>
>> Lucy organized a room for our informal discussion about OAuth (followed by
>> the OpenID Connect meeting). We will start at 10am and the room is reserved
>> till 3pm. Palace C is the meeting room. At some point in time the OAuth
>> meeting will turn into the OpenID Connect meeting. For those who are
>> interested I will give a privacy tutorial at 3pm in the Blenheim room.
>>
>> Mike, Nat, John, and others might have more information about the agenda
>> for the OpenID Connect meeting. For the OAuth meeting Derek and I were
>> planning to use the time to prepare the security discussions for the
>> official OAuth WG meeting. I am sure we will arrange further meeting slots
>> during the week to give enough room for socializing and generating new
>> ideas.
>>
>> Ciao
>> Hannes
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Tue Feb 25 16:56:57 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D911A07D6 for ; Tue, 25 Feb 2014 16:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-U8imTdMd4K for ; Tue, 25 Feb 2014 16:56:46 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACCA1A0347 for ; Tue, 25 Feb 2014 16:56:45 -0800 (PST)
Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB589.namprd03.prod.outlook.com (10.255.124.35) with Microsoft SMTP Server (TLS) id 15.0.888.9; Wed, 26 Feb 2014 00:56:37 +0000
Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0883.010; Wed, 26 Feb 2014 00:56:37 +0000
From: Anthony Nadalin 
To: John Bradley , Brian Campbell 
Thread-Topic: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
Thread-Index: AQHPMk5G/kKk08k6uUKFqVGTbJlGe5rGV4sAgAALvACAAFMnIA==
Date: Wed, 26 Feb 2014 00:56:37 +0000
Message-ID: <05c2f348ccc449a5a33ed1387870f2a6@BLUPR03MB309.namprd03.prod.outlook.com>
References:   <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>
In-Reply-To: <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [12.149.152.131]
x-forefront-prvs: 0134AD334F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(53754006)(52024003)(199002)(189002)(24454002)(377454003)(83072002)(76786001)(76576001)(56776001)(46102001)(85852003)(4396001)(79102001)(76796001)(47736001)(59766001)(63696002)(77982001)(81342001)(49866001)(54356001)(81542001)(53806001)(93136001)(65816001)(80022001)(51856001)(66066001)(92566001)(54316002)(69226001)(76482001)(33646001)(94946001)(31966008)(87266001)(2656002)(86612001)(74502001)(94316002)(86362001)(95416001)(74366001)(74316001)(15975445006)(16236675002)(74876001)(87936001)(74662001)(81816001)(47446002)(74706001)(83322001)(15202345003)(85306002)(80976001)(47976001)(56816005)(19580395003)(50986001)(90146001)(19580405001)(95666003)(19300405004)(93516002)(81686001)(42262001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB589; H:BLUPR03MB309.namprd03.prod.outlook.com; CLIP:12.149.152.131; FPR:B098F537.9CD457D5.71E7759F.48E2D74D.20297; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_05c2f348ccc449a5a33ed1387870f2a6BLUPR03MB309namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2M14yoejWRuqQ_1daC4X2dg12EQ
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 00:56:50 -0000

--_000_05c2f348ccc449a5a33ed1387870f2a6BLUPR03MB309namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

TWF5IHRoaW5ncyBzaG91bGQgY2hhbmdlIGJhY2sgYXMgYW5ub3VuY2VkPyBUaGluZ3MgaW4gbGlm
ZSBjaG5hZ2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBP
biBCZWhhbGYgT2YgSm9obiBCcmFkbGV5DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyNSwgMjAx
NCAxMTo1OCBBTQ0KVG86IEJyaWFuIENhbXBiZWxsDQpDYzogb2F1dGgNClN1YmplY3Q6IFJlOiBb
T0FVVEgtV0ddIE9BdXRoICsgT3BlbiBJRCBDb25uZWN0IE1lZXRpbmc6IFN1bmRheSwgTWFyY2gg
Mg0KDQpZZXMuDQoNClRoaW5ncyBjaGFuZ2UgdGhhdCdzIGxpZmUuDQoNCg0KDQpTZW50IGZyb20g
bXkgaVBob25lDQoNCk9uIEZlYiAyNSwgMjAxNCwgYXQgODoxNiBQTSwgQnJpYW4gQ2FtcGJlbGwg
PGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5
LmNvbT4+IHdyb3RlOg0KV2Fzbid0IHRoaXMgb3JpZ2luYWxseSBhbm5vdW5jZWQgd2l0aCBhIGRp
ZmZlcmVudCBzdGFydCB0aW1lIGFuZCBDb25uZWN0IGFuZCBPQXV0aCBoYXBwZW5pbmcgaW4gdGhl
IG9wcG9zaXRlIG9yZGVyPw0KDQpPbiBUdWUsIEZlYiAyNSwgMjAxNCBhdCAxMDoyMyBBTSwgSGFu
bmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOkhhbm5lcy5U
c2Nob2ZlbmlnQGdteC5uZXQ+PiB3cm90ZToNCkhpIGFsbCwNCg0KTHVjeSBvcmdhbml6ZWQgYSBy
b29tIGZvciBvdXIgaW5mb3JtYWwgZGlzY3Vzc2lvbiBhYm91dCBPQXV0aCAoZm9sbG93ZWQgYnkg
dGhlIE9wZW5JRCBDb25uZWN0IG1lZXRpbmcpLiBXZSB3aWxsIHN0YXJ0IGF0IDEwYW0gYW5kIHRo
ZSByb29tIGlzIHJlc2VydmVkIHRpbGwgM3BtLiBQYWxhY2UgQyBpcyB0aGUgbWVldGluZyByb29t
LiBBdCBzb21lIHBvaW50IGluIHRpbWUgdGhlIE9BdXRoIG1lZXRpbmcgd2lsbCB0dXJuIGludG8g
dGhlIE9wZW5JRCBDb25uZWN0IG1lZXRpbmcuIEZvciB0aG9zZSB3aG8gYXJlIGludGVyZXN0ZWQg
SSB3aWxsIGdpdmUgYSBwcml2YWN5IHR1dG9yaWFsIGF0IDNwbSBpbiB0aGUgQmxlbmhlaW0gcm9v
bS4NCg0KTWlrZSwgTmF0LCBKb2huLCBhbmQgb3RoZXJzIG1pZ2h0IGhhdmUgbW9yZSBpbmZvcm1h
dGlvbiBhYm91dCB0aGUgYWdlbmRhIGZvciB0aGUgT3BlbklEIENvbm5lY3QgbWVldGluZy4gRm9y
IHRoZSBPQXV0aCBtZWV0aW5nIERlcmVrIGFuZCBJIHdlcmUgcGxhbm5pbmcgdG8gdXNlIHRoZSB0
aW1lIHRvIHByZXBhcmUgdGhlIHNlY3VyaXR5IGRpc2N1c3Npb25zIGZvciB0aGUgb2ZmaWNpYWwg
T0F1dGggV0cgbWVldGluZy4gSSBhbSBzdXJlIHdlIHdpbGwgYXJyYW5nZSBmdXJ0aGVyIG1lZXRp
bmcgc2xvdHMgZHVyaW5nIHRoZSB3ZWVrIHRvIGdpdmUgZW5vdWdoIHJvb20gZm9yIHNvY2lhbGl6
aW5nIGFuZCBnZW5lcmF0aW5nIG5ldyBpZGVhcy4NCg0KQ2lhbw0KSGFubmVzDQoNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg
bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm
Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoDQo=

--_000_05c2f348ccc449a5a33ed1387870f2a6BLUPR03MB309namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg
NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg
bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu
LmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg
ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N
Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh
c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWF5IHRoaW5ncyBzaG91bGQgY2hhbmdlIGJhY2sg
YXMgYW5ub3VuY2VkPyBUaGluZ3MgaW4gbGlmZSBjaG5hZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s
aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJyPg0KPGI+U2Vu
dDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDI1LCAyMDE0IDExOjU4IEFNPGJyPg0KPGI+VG86PC9i
PiBCcmlhbiBDYW1wYmVsbDxicj4NCjxiPkNjOjwvYj4gb2F1dGg8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IFtPQVVUSC1XR10gT0F1dGggJiM0MzsgT3BlbiBJRCBDb25uZWN0IE1lZXRpbmc6IFN1
bmRheSwgTWFyY2ggMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5ZZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRoaW5ncyBjaGFuZ2UgdGhhdCdzIGxpZmUuJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi
cj4NClNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24g
RmViIDI1LCAyMDE0LCBhdCA4OjE2IFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv
bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Fzbid0IHRoaXMgb3JpZ2luYWxseSBhbm5vdW5jZWQgd2l0
aCBhIGRpZmZlcmVudCBzdGFydCB0aW1lIGFuZCBDb25uZWN0IGFuZCBPQXV0aCBoYXBwZW5pbmcg
aW4gdGhlIG9wcG9zaXRlIG9yZGVyPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAyNSwg
MjAxNCBhdCAxMDoyMyBBTSwgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpI
YW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+SGFubmVzLlRzY2hvZmVu
aWdAZ214Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij5IaSBhbGwsJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy
ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5MdWN5IG9yZ2FuaXplZCBhIHJvb20g
Zm9yIG91ciBpbmZvcm1hbCBkaXNjdXNzaW9uIGFib3V0IE9BdXRoIChmb2xsb3dlZCBieSB0aGUg
T3BlbklEIENvbm5lY3QgbWVldGluZykuIFdlIHdpbGwgc3RhcnQgYXQgMTBhbSBhbmQgdGhlIHJv
b20gaXMgcmVzZXJ2ZWQgdGlsbCAzcG0uIFBhbGFjZSBDIGlzDQogdGhlIG1lZXRpbmcgcm9vbS4g
QXQgc29tZSBwb2ludCBpbiB0aW1lIHRoZSBPQXV0aCBtZWV0aW5nIHdpbGwgdHVybiBpbnRvIHRo
ZSBPcGVuSUQgQ29ubmVjdCBtZWV0aW5nLiBGb3IgdGhvc2Ugd2hvIGFyZSBpbnRlcmVzdGVkIEkg
d2lsbCBnaXZlIGEgcHJpdmFjeSB0dXRvcmlhbCBhdCAzcG0gaW4gdGhlIEJsZW5oZWltIHJvb20u
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtW
ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5NaWtlLCBOYXQsIEpvaG4sIGFuZCBvdGhlcnMgbWlnaHQgaGF2ZSBt
b3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBhZ2VuZGEgZm9yIHRoZSBPcGVuSUQgQ29ubmVjdCBt
ZWV0aW5nLiBGb3IgdGhlIE9BdXRoIG1lZXRpbmcgRGVyZWsgYW5kIEkgd2VyZSBwbGFubmluZyB0
byB1c2UgdGhlIHRpbWUgdG8NCiBwcmVwYXJlIHRoZSBzZWN1cml0eSBkaXNjdXNzaW9ucyBmb3Ig
dGhlIG9mZmljaWFsIE9BdXRoIFdHIG1lZXRpbmcuIEkgYW0gc3VyZSB3ZSB3aWxsIGFycmFuZ2Ug
ZnVydGhlciBtZWV0aW5nIHNsb3RzIGR1cmluZyB0aGUgd2VlayB0byBnaXZlIGVub3VnaCByb29t
IGZvciBzb2NpYWxpemluZyBhbmQgZ2VuZXJhdGluZyBuZXcgaWRlYXMuICZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+Q2lhbzxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9l
bnpiIj5IYW5uZXM8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp
bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRm
Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn
PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_05c2f348ccc449a5a33ed1387870f2a6BLUPR03MB309namprd03pro_--


From nobody Tue Feb 25 16:57:41 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64FB1A0347 for ; Tue, 25 Feb 2014 16:57:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxNYLoAj0xFJ for ; Tue, 25 Feb 2014 16:57:32 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB001A0825 for ; Tue, 25 Feb 2014 16:57:24 -0800 (PST)
Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB590.namprd03.prod.outlook.com (10.255.124.36) with Microsoft SMTP Server (TLS) id 15.0.888.9; Wed, 26 Feb 2014 00:57:22 +0000
Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0883.010; Wed, 26 Feb 2014 00:57:22 +0000
From: Anthony Nadalin 
To: Brian Campbell , John Bradley 
Thread-Topic: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
Thread-Index: AQHPMk5G/kKk08k6uUKFqVGTbJlGe5rGV4sAgAALvACAADGFAIAAIecA
Date: Wed, 26 Feb 2014 00:57:21 +0000
Message-ID: <334fb1d7c15d4c92839b7799929c05ff@BLUPR03MB309.namprd03.prod.outlook.com>
References:   <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [12.149.152.131]
x-forefront-prvs: 0134AD334F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(53754006)(24454002)(377454003)(52024003)(51704005)(93136001)(81342001)(81542001)(63696002)(81816001)(79102001)(15975445006)(86362001)(93516002)(33646001)(59766001)(81686001)(80976001)(50986001)(47976001)(94316002)(76786001)(76796001)(47736001)(49866001)(76576001)(4396001)(19580405001)(54356001)(53806001)(51856001)(87266001)(46102001)(19580395003)(54316002)(56776001)(76482001)(69226001)(83322001)(47446002)(74502001)(31966008)(74662001)(74366001)(87936001)(65816001)(74316001)(83072002)(56816005)(90146001)(2656002)(74876001)(94946001)(86612001)(74706001)(95416001)(95666003)(92566001)(77982001)(66066001)(80022001)(85852003)(85306002)(42262001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB590; H:BLUPR03MB309.namprd03.prod.outlook.com; CLIP:12.149.152.131; FPR:BCB9F535.8CDA57D5.71677593.48F6DFCD.2030D; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0JcdQHW8El8YeM2DU8yUVm1clBY
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 00:57:37 -0000

Agree, the OAUTH meeting should change to afternoon

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, February 25, 2014 2:56 PM
To: John Bradley
Cc: oauth
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2

Yes, I'm familiar with life and I'm aware that things do change. And I have=
 no doubt that scheduling this stuff is more than a little difficult. But w=
ith these Sunday meetings and the vast majority of us traveling internation=
ally, it'd be really helpful if the timing can be nailed down as early as i=
s reasonable and changes can be avoided.



On Tue, Feb 25, 2014 at 12:58 PM, John Bradley  wrote:
> Yes.
>
> Things change that's life.
>
>
>
> Sent from my iPhone
>
> On Feb 25, 2014, at 8:16 PM, Brian Campbell=20
> 
> wrote:
>
> Wasn't this originally announced with a different start time and=20
> Connect and OAuth happening in the opposite order?
>
>
> On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig=20
>  wrote:
>>
>> Hi all,
>>
>> Lucy organized a room for our informal discussion about OAuth=20
>> (followed by the OpenID Connect meeting). We will start at 10am and=20
>> the room is reserved till 3pm. Palace C is the meeting room. At some=20
>> point in time the OAuth meeting will turn into the OpenID Connect=20
>> meeting. For those who are interested I will give a privacy tutorial at =
3pm in the Blenheim room.
>>
>> Mike, Nat, John, and others might have more information about the=20
>> agenda for the OpenID Connect meeting. For the OAuth meeting Derek=20
>> and I were planning to use the time to prepare the security=20
>> discussions for the official OAuth WG meeting. I am sure we will=20
>> arrange further meeting slots during the week to give enough room for=20
>> socializing and generating new ideas.
>>
>> Ciao
>> Hannes
>>
>>
>> _______________________________________________
>> 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 nobody Tue Feb 25 23:59:14 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7221A0061 for ; Tue, 25 Feb 2014 23:59:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai316UR-cepc for ; Tue, 25 Feb 2014 23:59:03 -0800 (PST)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id C40F41A005A for ; Tue, 25 Feb 2014 23:59:02 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id cc10so5530495wib.10 for ; Tue, 25 Feb 2014 23:59:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FZDCQgplIgpRnKXSs/dKHKdygcBXqBg/P+9qO5zQnWc=; b=hatce6gh+EXsfpj6o7P7NvQ2po3u1Za7KjHatQ8ZH8Qf5Jl8G/WHcwQGa+U5mcqOVD FEI9AzVzaMI2tDOCpe10q8oIc8GF6Trd14AjcIL3Mf+no2xiszOlNgRUijGPhGKz4LIX m+QPAbZaWjWsKUcugl8MsTaejdUlbJuj386GFg42qYU7LqIdq0JfHZyqiuZWiwZcTjb5 z6Z47ntA95pNuTc8ql6U/Sc8p/uXEJiNgc5+q+lW0b4Q38Ypr8JVhSDXNsM7GSINWR/5 wNTzZkH95YBxJK93jAeOuiRXFYfKVED2nRDz4huFf/Qd4Uxd7HLbuid1nHMU/sQBbaDC /fPw==
X-Gm-Message-State: ALoCoQnGvCxKsg9nujfYNdss1dkBgAXI//wApdFkxIMJJDBxGfrMn7AkHDf7vNrI4rAj9mIB7n5x
X-Received: by 10.180.210.171 with SMTP id mv11mr6696064wic.44.1393401540934;  Tue, 25 Feb 2014 23:59:00 -0800 (PST)
Received: from [192.168.50.167] (80.224.32.125.static.user.ono.com. [80.224.32.125]) by mx.google.com with ESMTPSA id jw4sm252203wjc.20.2014.02.25.23.58.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 23:58:58 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_D8324EF0-BD1D-4ADB-BBF0-A4F7002B765B"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley 
In-Reply-To: <334fb1d7c15d4c92839b7799929c05ff@BLUPR03MB309.namprd03.prod.outlook.com>
Date: Wed, 26 Feb 2014 08:58:35 +0100
Message-Id: <7DFFB4D1-3086-4C33-A0B7-7B6A5A1841C5@ve7jtb.com>
References:   <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>  <334fb1d7c15d4c92839b7799929c05ff@BLUPR03MB309.namprd03.prod.outlook.com>
To: Anthony Nadalin 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/NTg0TYuR-FnAUwi_1hnRb700tjY
Cc: Lucy Lynch , oauth 
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 07:59:07 -0000

--Apple-Mail=_D8324EF0-BD1D-4ADB-BBF0-A4F7002B765B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I asked for the room from 12 to 5.   The chair had the time changed so =
we reserved the room from 10 to 3pm.

We would need to talk to Lucy to see if we could have the time extended =
past 3 for additional OAuth related meetings.

I don't know if the room is booked for something else after 3 but we =
could likely find out.

John B.

On Feb 26, 2014, at 1:57 AM, Anthony Nadalin  =
wrote:

> Agree, the OAUTH meeting should change to afternoon
>=20
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian =
Campbell
> Sent: Tuesday, February 25, 2014 2:56 PM
> To: John Bradley
> Cc: oauth
> Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March =
2
>=20
> Yes, I'm familiar with life and I'm aware that things do change. And I =
have no doubt that scheduling this stuff is more than a little =
difficult. But with these Sunday meetings and the vast majority of us =
traveling internationally, it'd be really helpful if the timing can be =
nailed down as early as is reasonable and changes can be avoided.
>=20
>=20
>=20
> On Tue, Feb 25, 2014 at 12:58 PM, John Bradley  =
wrote:
>> Yes.
>>=20
>> Things change that's life.
>>=20
>>=20
>>=20
>> Sent from my iPhone
>>=20
>> On Feb 25, 2014, at 8:16 PM, Brian Campbell=20
>> 
>> wrote:
>>=20
>> Wasn't this originally announced with a different start time and=20
>> Connect and OAuth happening in the opposite order?
>>=20
>>=20
>> On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig=20
>>  wrote:
>>>=20
>>> Hi all,
>>>=20
>>> Lucy organized a room for our informal discussion about OAuth=20
>>> (followed by the OpenID Connect meeting). We will start at 10am and=20=

>>> the room is reserved till 3pm. Palace C is the meeting room. At some=20=

>>> point in time the OAuth meeting will turn into the OpenID Connect=20
>>> meeting. For those who are interested I will give a privacy tutorial =
at 3pm in the Blenheim room.
>>>=20
>>> Mike, Nat, John, and others might have more information about the=20
>>> agenda for the OpenID Connect meeting. For the OAuth meeting Derek=20=

>>> and I were planning to use the time to prepare the security=20
>>> discussions for the official OAuth WG meeting. I am sure we will=20
>>> arrange further meeting slots during the week to give enough room =
for=20
>>> socializing and generating new ideas.
>>>=20
>>> Ciao
>>> Hannes
>>>=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=_D8324EF0-BD1D-4ADB-BBF0-A4F7002B765B
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjI2MDc1ODM2WjAjBgkqhkiG9w0BCQQxFgQU3HuVKVi6
6CBTQNLzVZM6SIBJNMswgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAWDsGEmLxavFHRF6LtFHPmPT6MSXls4y3hhr+BkM2
VN3Sjy2kzXlCzDTCLwCwCiwK+ZiG2DXRRoyeaObN3pWvsqqxnq1f6vUm5rxkmolQj6pknMDexQD2
pmrtJ5Q/p36CniNHrW/07tU3B0BzKCY1SkiKlXNQD032+CowQ7r/ILgOuh/UXU6Bx9au9U2qmeiL
PQ4y6uwnAe3qc3BweE1vQFsUrhRc7H9TPi0DuKOny68M/H1/QT1r2tSEZeWsv1FR8iUeJD5qmPrm
FzxNxEVBKMsNyRoPU9b8PCpHQT6Pbopy36vHKCQICylpiWifAFOvcuDOaETEo2CbA2MPqW1IBwAA
AAAAAA==

--Apple-Mail=_D8324EF0-BD1D-4ADB-BBF0-A4F7002B765B--


From nobody Wed Feb 26 04:05:05 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6871A029A for ; Wed, 26 Feb 2014 04:04:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.913
X-Spam-Level: 
X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXtdf4r3Cc7n for ; Wed, 26 Feb 2014 04:04:56 -0800 (PST)
Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by ietfa.amsl.com (Postfix) with ESMTP id D54121A029B for ; Wed, 26 Feb 2014 04:04:55 -0800 (PST)
Received: from mail-ig0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKUw3YYazRgqTMDcfUsa+JoKZHn8Xf6TiX@postini.com; Wed, 26 Feb 2014 04:04:55 PST
Received: by mail-ig0-f180.google.com with SMTP id uq10so1229827igb.1 for ; Wed, 26 Feb 2014 04:04:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ft+8Ks7SUR9sSCTPWGPMNa5bhh7wSPKbAp7N4hJD/nk=; b=JWHl3kXPhzxRElzuIn0GCux6Lnt7uNair18O4zEdpCXJsfl56FuKLQSMG+1oW0gxFp nNyjY27s67GnKrrX2yOyPin2pebMA29ZOdeWrMBQn7BwQpxQLbl/FPzDRrbn0NYeHYCM yPYqk8TygjKTHbQoVYAf5TbuNVnjCmlHSSKijaVu9VOG/a5sZo7TSHtnlV8e6XFoy3cV fJVGeNag5lgrqRqCNHb8BGqCyMIdfZjH4XO6ZcbSwc+lIp7dbC7ALcZtCDipsO/cYlkM Yvoer6iXPUYq8nzxWHdnwomYsjTa2HXICprsQxuQBlVebhtinaRVFeU75at5TvuUp8nL CeVg==
X-Gm-Message-State: ALoCoQmQoegS36kkDn8pXlqslrygP/e+PoeZ2sbr7zk/9iOrjJXGMpkHSoDcfurSU7AixyIlYYgwCEXgsAD0+RhKbxWEfI4+/0f3rGs0pgwcVbEYB/tCR9A5rhzfCxJG/xd2uKPliqf/ZCYIW6RG2IuxE8xYXSE5TQ==
X-Received: by 10.50.97.98 with SMTP id dz2mr25795715igb.34.1393416284953; Wed, 26 Feb 2014 04:04:44 -0800 (PST)
X-Received: by 10.50.97.98 with SMTP id dz2mr25795699igb.34.1393416284828; Wed, 26 Feb 2014 04:04:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.65.4 with HTTP; Wed, 26 Feb 2014 04:04:14 -0800 (PST)
In-Reply-To: 
References: 
From: Brian Campbell 
Date: Wed, 26 Feb 2014 05:04:14 -0700
Message-ID: 
To: Hannes Tschofenig 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LpNY5J7rEOieEn-jA97BiXR1WFE
Cc: oauth 
Subject: Re: [OAUTH-WG] Draft Agenda
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 12:04:59 -0000

Any idea, on the two Assertion Documents, if there is or will be any
feedback from the IESG and, if so, what form it might take? There's a
chance #2 takes considerably less than 15 minutes, if there's no
feedback. And hopefully 15 mins will be sufficient, if there is some
feedback.

On Mon, Feb 24, 2014 at 11:47 AM, Hannes Tschofenig
 wrote:
> Hi all,
>
> we put a draft agenda online:
> http://www.ietf.org/proceedings/89/agenda/agenda-89-oauth
>
> Let us know whether this sounds reasonable for you.
>
> Ciao
> Hannes & Derek
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


From nobody Wed Feb 26 05:34:47 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950F81A0349 for ; Wed, 26 Feb 2014 05:34:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2VRHV3Hns8m for ; Wed, 26 Feb 2014 05:34:37 -0800 (PST)
Received: from exprod5og112.obsmtp.com (exprod5og112.obsmtp.com [64.18.0.24]) by ietfa.amsl.com (Postfix) with ESMTP id A78EA1A0321 for ; Wed, 26 Feb 2014 05:33:39 -0800 (PST)
Received: from alpmlip12.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob112.postini.com ([64.18.4.12]) with SMTP ID DSNKUw3tMnN8hX8MhLS0uqJ9Za62e5kCuliX@postini.com; Wed, 26 Feb 2014 05:33:41 PST
Received: from unknown (HELO ALPMBHT02.e2k.ad.ge.com) ([3.159.19.195]) by alpmlip12.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 26 Feb 2014 09:02:14 -0500
Received: from CINURCNA09.e2k.ad.ge.com (3.159.212.126) by ALPMBHT02.e2k.ad.ge.com (3.159.19.195) with Microsoft SMTP Server (TLS) id 14.3.174.2; Wed, 26 Feb 2014 08:33:37 -0500
Received: from CINURCNA16.e2k.ad.ge.com ([169.254.4.64]) by CINURCNA09.e2k.ad.ge.com ([169.254.3.241]) with mapi id 14.03.0174.002; Wed, 26 Feb 2014 08:33:36 -0500
From: "Vargas, William (GE Corporate, consultant)" 
To: "OAuth@ietf.org" 
Thread-Topic: Please remove me from mailing list - Thank you
Thread-Index: Ac8y91es8WMujmY1Q9OhIWRotWUURw==
Date: Wed, 26 Feb 2014 13:33:36 +0000
Message-ID: <654B5BD9D8564943B6D14348C94A2C8A1B329B01@CINURCNA16.e2k.ad.ge.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [3.159.212.188]
Content-Type: multipart/alternative; boundary="_000_654B5BD9D8564943B6D14348C94A2C8A1B329B01CINURCNA16e2kad_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DCjlcbMczTHlgc9DquxlRa6Tt4E
Subject: [OAUTH-WG] Please remove me from mailing list - Thank you
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 13:34:44 -0000

--_000_654B5BD9D8564943B6D14348C94A2C8A1B329B01CINURCNA16e2kad_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please remove me from mailing list - Thank you

--_000_654B5BD9D8564943B6D14348C94A2C8A1B329B01CINURCNA16e2kad_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Please remove me from mailing list - Thank you<=
/o:p>






--_000_654B5BD9D8564943B6D14348C94A2C8A1B329B01CINURCNA16e2kad_--


From nobody Wed Feb 26 09:15:32 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA6C1A06EE for ; Wed, 26 Feb 2014 09:15:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMTf06M2GzyM for ; Wed, 26 Feb 2014 09:15:26 -0800 (PST)
Received: from hans.rg.net (hans.rg.net [IPv6:2001:418:1::42]) by ietfa.amsl.com (Postfix) with ESMTP id 164FA1A0705 for ; Wed, 26 Feb 2014 09:15:13 -0800 (PST)
Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) (authenticated bits=0) by hans.rg.net (8.14.7/8.14.7) with ESMTP id s1QHFBX1075869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Feb 2014 17:15:11 GMT (envelope-from lynch@isoc.org)
Date: Wed, 26 Feb 2014 09:15:11 -0800 (PST)
From: Lucy Lynch 
X-X-Sender: llynch@hiroshima.bogus.com
To: John Bradley 
In-Reply-To: <7DFFB4D1-3086-4C33-A0B7-7B6A5A1841C5@ve7jtb.com>
Message-ID: 
References:   <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>  <334fb1d7c15d4c92839b7799929c05ff@BLUPR03MB309.namprd03.prod.outlook.com> <7DFFB4D1-3086-4C33-A0B7-7B6A5A1841C5@ve7jtb.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Content-ID: 
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YER2c-SN9RWpqYdgLXfIu9OXM10
Cc: Lucy Lynch , oauth 
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: lynch@isoc.org
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 17:15:29 -0000

On Wed, 26 Feb 2014, John Bradley wrote:

> I asked for the room from 12 to 5.  The chair had the time changed so we 
> reserved the room from 10 to 3pm.
>
> We would need to talk to Lucy to see if we could have the time extended 
> past 3 for additional OAuth related meetings.
>
> I don't know if the room is booked for something else after 3 but we 
> could likely find out.

I can check - it would help if everyone agreed on times and topics.

> John B.
>
> On Feb 26, 2014, at 1:57 AM, Anthony Nadalin  wrote:
>
>> Agree, the OAUTH meeting should change to afternoon
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
>> Sent: Tuesday, February 25, 2014 2:56 PM
>> To: John Bradley
>> Cc: oauth
>> Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
>>
>> Yes, I'm familiar with life and I'm aware that things do change. And I have no doubt that scheduling this stuff is more than a little difficult. But with these Sunday meetings and the vast majority of us traveling internationally, it'd be really helpful if the timing can be nailed down as early as is reasonable and changes can be avoided.
>>
>>
>>
>> On Tue, Feb 25, 2014 at 12:58 PM, John Bradley  wrote:
>>> Yes.
>>>
>>> Things change that's life.
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Feb 25, 2014, at 8:16 PM, Brian Campbell
>>> 
>>> wrote:
>>>
>>> Wasn't this originally announced with a different start time and
>>> Connect and OAuth happening in the opposite order?
>>>
>>>
>>> On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig
>>>  wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Lucy organized a room for our informal discussion about OAuth
>>>> (followed by the OpenID Connect meeting). We will start at 10am and
>>>> the room is reserved till 3pm. Palace C is the meeting room. At some
>>>> point in time the OAuth meeting will turn into the OpenID Connect
>>>> meeting. For those who are interested I will give a privacy tutorial at 3pm in the Blenheim room.
>>>>
>>>> Mike, Nat, John, and others might have more information about the
>>>> agenda for the OpenID Connect meeting. For the OAuth meeting Derek
>>>> and I were planning to use the time to prepare the security
>>>> discussions for the official OAuth WG meeting. I am sure we will
>>>> arrange further meeting slots during the week to give enough room for
>>>> socializing and generating new ideas.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 nobody Wed Feb 26 11:43:18 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC011A0844 for ; Wed, 26 Feb 2014 11:43:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH1pkFQ4i8PS for ; Wed, 26 Feb 2014 11:43:14 -0800 (PST)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7341A0806 for ; Wed, 26 Feb 2014 11:43:14 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id lf12so1465205vcb.3 for ; Wed, 26 Feb 2014 11:43:13 -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:message-id:subject :from:to:cc:content-type; bh=mmoWN37pXMzxzryaSKAj6fmXujf+iJsh8AzM+xgEZs4=; b=kYmjoQSQ4PiYUzTvLJQtD0AmKdIXMbrlk1edpD1iWHQUlEgo7dxIXS5ioI6lTcRPeZ Zit5U1DKWSHjwm0oBgTJgyZK3Kd6ORd9/6OOUVU/5/iqyETZJVZca1IaHHOvXVPS5IG3 a79HpThX6TqWDjGx60x/PjQDTL1Uf/v0J16HuRWR2IxRCC/A4WAhWcHUzytuT54S8y6o EFVx99TTSiCjvXHRN+Ad57HmK4eDOfgfpnX936J6gcpG5PT6yWIe8G+b23gk8sZXsY72 mobx1z1eHPL8LJ0jgYz5IeQ8mtq1xUCTWUeJje3pmzYRkVEP3oOpKwgfFi2jlBRAbf1e 4AUw==
MIME-Version: 1.0
X-Received: by 10.53.9.107 with SMTP id dr11mr5924083vdd.1.1393443793127; Wed, 26 Feb 2014 11:43:13 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.58.19.104 with HTTP; Wed, 26 Feb 2014 11:43:13 -0800 (PST)
In-Reply-To: 
References:  
Date: Wed, 26 Feb 2014 11:43:13 -0800
X-Google-Sender-Auth: 10egCwA6m1iEH0tGGpQJUrHNgE0
Message-ID: 
From: Barry Leiba 
To: Brian Campbell 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0QmqA5Zf3mMyntcFU0dd33IEbpc
Cc: oauth 
Subject: Re: [OAUTH-WG] Draft Agenda
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 19:43:16 -0000

> Any idea, on the two Assertion Documents, if there is or will be any
> feedback from the IESG and, if so, what form it might take?

I'm sorry that I haven't been able to get to reviewing this yet --
I've had a bunch of pre-IETF travel, in addition to preparing for the
meeting.  I aim to have a look on the flights to London, so I hope to
get you feedback this Thursday.

Barry

> There's a
> chance #2 takes considerably less than 15 minutes, if there's no
> feedback. And hopefully 15 mins will be sufficient, if there is some
> feedback.
>
> On Mon, Feb 24, 2014 at 11:47 AM, Hannes Tschofenig
>  wrote:
>> Hi all,
>>
>> we put a draft agenda online:
>> http://www.ietf.org/proceedings/89/agenda/agenda-89-oauth
>>
>> Let us know whether this sounds reasonable for you.
>>
>> Ciao
>> Hannes & Derek
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Wed Feb 26 20:01:53 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E89C1A03BE for ; Wed, 26 Feb 2014 20:01:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Level: 
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kzde1_MQwqOg for ; Wed, 26 Feb 2014 20:01:50 -0800 (PST)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2961A01D3 for ; Wed, 26 Feb 2014 20:01:49 -0800 (PST)
Received: by mail-ve0-f172.google.com with SMTP id jx11so3293353veb.3 for ; Wed, 26 Feb 2014 20:01:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:cc:content-type;  bh=0KSWjq3xWAZzcAgx1QJh404Bgr/Vhz62FNw7w/02JOc=; b=GXGtTsscFLJL51VWBrML2+bn7biEBOIggMFVp6rC93dbUdT64m0UhgZwfQSYalPtI5 HqMxkx3IMxMOFKE2DW96RFGtDpi/TC1gxlvdXYCIdyvCuN+2gZa4QyJBnewUEWPZirkp rkkfaSVPX5jy+1cM9Fs+ah+WwhKbgLr84PiQbTjZoX9RGjV0ndRAhd2QVXNJjtKRVk9N MNDi4IkwYxb0/Zb5kJ/4tsjlpCtMRSWlivqU/fy/gZ90quNDGWS4KmAkDfdz4XeLHJyc +WfPDxl+I28RUJVzQC/3fvKZMJD+qLzBbsS6UpqHKNG6+UzPfr6vNl5Npm0IrX1O/vON hMNg==
MIME-Version: 1.0
X-Received: by 10.58.186.132 with SMTP id fk4mr8651903vec.9.1393473708483; Wed, 26 Feb 2014 20:01:48 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.58.19.104 with HTTP; Wed, 26 Feb 2014 20:01:48 -0800 (PST)
Date: Wed, 26 Feb 2014 20:01:48 -0800
X-Google-Sender-Auth: d3wkRmHYjgwavoku_OuJULZmar4
Message-ID: 
From: Barry Leiba 
To: Brian Campbell 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Nc75EyLRwKisDY-AR6UYk2MGi_E
Cc: oauth 
Subject: [OAUTH-WG] Reaction to the current assertion pair {framework, SAML}
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Feb 2014 04:01:51 -0000

>> Any idea, on the two Assertion Documents, if there is or will be any
>> feedback from the IESG and, if so, what form it might take?
>
> I'm sorry that I haven't been able to get to reviewing this yet --
> I've had a bunch of pre-IETF travel, in addition to preparing for the
> meeting.  I aim to have a look on the flights to London, so I hope to
> get you feedback this Thursday.

It's not Thursday yet, at least not in San Diego, but I've had time in
the UA Club before flying out.  I haven't reviewed them in detail, but
I looked through them with respect to the DISCUSS issues I'd raised
before.

You'll be happy to hear that on those issues, I think we understand
each other and the current documents seem fine -- they define things
in a way that I think people can implement interoperably without
calling someone on the phone first.

Thanks for sticking with this, understanding what I was on about, and
sorting it out.

Barry


From nobody Thu Feb 27 04:55:02 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A8A1A0256 for ; Thu, 27 Feb 2014 04:55:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.513
X-Spam-Level: 
X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grtJEX1l8a4H for ; Thu, 27 Feb 2014 04:54:59 -0800 (PST)
Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 937E61A0249 for ; Thu, 27 Feb 2014 04:54:59 -0800 (PST)
Received: from mail-ig0-f174.google.com ([209.85.213.174]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKUw81oqzDSfC6i88R8Ip3eBrwfNhIO6Ua@postini.com; Thu, 27 Feb 2014 04:54:58 PST
Received: by mail-ig0-f174.google.com with SMTP id h18so3296669igc.1 for ; Thu, 27 Feb 2014 04:54:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/tKehSBduEUf7xQ0NZJ5Q2iOvAfFYJR4W0g7ELyYSuM=; b=BcmzEY0f5l+xdkj5y4mTplVx+l5aYcLYFml69AzPmVO2puy1L+BWZfG3zdjnQf796a Dz6EP1MQJkyClAaPJIcvZpAqa/T0N3dGglf1ICO5kaWZSgJEU9K0lRw+uSPj5mdbFS2N n9DQpelRVI27omSbiSgTZjyqK4eFakLVFIHeJJnQzPH2W1ETgpFWkOKUBr6ICTUHIps9 FZQxw1LG1oo5hPNkL2WW9tmgTbttfinH3CII5SbXl3zWRfuvk/Ca0v2FhWTUy5nnirWz N1BRNuhI8l4Qfx1wA/SbnAL2IZfeCS+zpwbgPicwb9JJoSCllEnsya6ydQpJrdR55ep0 /4gw==
X-Gm-Message-State: ALoCoQkqEXru/v+2jA6oumxlAY/ndfY6BVMrLx21uSS++gbNlW8GnYfaqQWxAeSTSdjfe53k7A4atgiir5dpmq7FklVLbI0BndBIOd6nwyBGqljHMaKCnzLaDjA2XvZaQd4EjOKtBQwYsOAVvs24LtngfT9+IDLUYg==
X-Received: by 10.50.47.110 with SMTP id c14mr6369312ign.4.1393505697917; Thu, 27 Feb 2014 04:54:57 -0800 (PST)
X-Received: by 10.50.47.110 with SMTP id c14mr6369298ign.4.1393505697796; Thu, 27 Feb 2014 04:54:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.65.4 with HTTP; Thu, 27 Feb 2014 04:54:27 -0800 (PST)
In-Reply-To: 
References: 
From: Brian Campbell 
Date: Thu, 27 Feb 2014 05:54:27 -0700
Message-ID: 
To: Barry Leiba 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3Qe0FegDlazf9nsnnnWHq1GiO3M
Cc: oauth 
Subject: Re: [OAUTH-WG] Reaction to the current assertion pair {framework, SAML}
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Feb 2014 12:55:01 -0000

Thanks Barry! I am very happy to hear that.

On Wed, Feb 26, 2014 at 9:01 PM, Barry Leiba  wrote:
>>> Any idea, on the two Assertion Documents, if there is or will be any
>>> feedback from the IESG and, if so, what form it might take?
>>
>> I'm sorry that I haven't been able to get to reviewing this yet --
>> I've had a bunch of pre-IETF travel, in addition to preparing for the
>> meeting.  I aim to have a look on the flights to London, so I hope to
>> get you feedback this Thursday.
>
> It's not Thursday yet, at least not in San Diego, but I've had time in
> the UA Club before flying out.  I haven't reviewed them in detail, but
> I looked through them with respect to the DISCUSS issues I'd raised
> before.
>
> You'll be happy to hear that on those issues, I think we understand
> each other and the current documents seem fine -- they define things
> in a way that I think people can implement interoperably without
> calling someone on the phone first.
>
> Thanks for sticking with this, understanding what I was on about, and
> sorting it out.
>
> Barry


From nobody Thu Feb 27 11:29:47 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA9C1A0640 for ; Thu, 27 Feb 2014 11:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzV2XTaMCRNm for ; Thu, 27 Feb 2014 11:29:43 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5831A0126 for ; Thu, 27 Feb 2014 11:29:43 -0800 (PST)
Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB591.namprd03.prod.outlook.com (10.255.124.37) with Microsoft SMTP Server (TLS) id 15.0.888.9; Thu, 27 Feb 2014 19:29:34 +0000
Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0883.010; Thu, 27 Feb 2014 19:29:34 +0000
From: Anthony Nadalin 
To: "lynch@isoc.org" , John Bradley 
Thread-Topic: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
Thread-Index: AQHPMk5G/kKk08k6uUKFqVGTbJlGe5rGV4sAgAALvACAADGFAIAAIecAgAB1yYCAAJuDgIABtopg
Date: Thu, 27 Feb 2014 19:29:33 +0000
Message-ID: <1c685189bc8d4edb8b959a7a556f05b6@BLUPR03MB309.namprd03.prod.outlook.com>
References:   <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>  <334fb1d7c15d4c92839b7799929c05ff@BLUPR03MB309.namprd03.prod.outlook.com> <7DFFB4D1-3086-4C33-A0B7-7B6A5A1841C5@ve7jtb.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [167.220.24.242]
x-forefront-prvs: 013568035E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(24454002)(51704005)(377454003)(53754006)(52024003)(189002)(199002)(94316002)(77982001)(94946001)(59766001)(76576001)(80976001)(66066001)(76796001)(86362001)(93516002)(76786001)(81686001)(50986001)(49866001)(47976001)(47736001)(86612001)(80022001)(79102001)(19580395003)(83322001)(95416001)(65816001)(63696002)(19580405001)(95666003)(81542001)(90146001)(56816005)(4396001)(15975445006)(81342001)(87266001)(74316001)(74366001)(33646001)(76482001)(56776001)(54316002)(54356001)(53806001)(69226001)(81816001)(2656002)(87936001)(74876001)(46102001)(83072002)(74706001)(85852003)(85306002)(92566001)(93136001)(31966008)(47446002)(74662001)(74502001)(42262001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB591; H:BLUPR03MB309.namprd03.prod.outlook.com; CLIP:167.220.24.242; FPR:ACB4F1B5.8FDA57D5.F1E7715B.48C6DFCD.203FB; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ggiZQQDim2eM4Y8HzoKdjB_9bmw
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Feb 2014 19:29:46 -0000

We agreed upon a time and then John decided to change it as some of the fol=
ks can't make it to the venue until after 1PM as they are flying in on Sund=
ay

-----Original Message-----
From: Lucy Lynch [mailto:lynch@isoc.org]=20
Sent: Wednesday, February 26, 2014 9:15 AM
To: John Bradley
Cc: Anthony Nadalin; Brian Campbell; oauth; Lucy Lynch
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2

On Wed, 26 Feb 2014, John Bradley wrote:

> I asked for the room from 12 to 5.  The chair had the time changed so=20
> we reserved the room from 10 to 3pm.
>
> We would need to talk to Lucy to see if we could have the time=20
> extended past 3 for additional OAuth related meetings.
>
> I don't know if the room is booked for something else after 3 but we=20
> could likely find out.

I can check - it would help if everyone agreed on times and topics.

> John B.
>
> On Feb 26, 2014, at 1:57 AM, Anthony Nadalin  wrot=
e:
>
>> Agree, the OAUTH meeting should change to afternoon
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian=20
>> Campbell
>> Sent: Tuesday, February 25, 2014 2:56 PM
>> To: John Bradley
>> Cc: oauth
>> Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday,=20
>> March 2
>>
>> Yes, I'm familiar with life and I'm aware that things do change. And I h=
ave no doubt that scheduling this stuff is more than a little difficult. Bu=
t with these Sunday meetings and the vast majority of us traveling internat=
ionally, it'd be really helpful if the timing can be nailed down as early a=
s is reasonable and changes can be avoided.
>>
>>
>>
>> On Tue, Feb 25, 2014 at 12:58 PM, John Bradley  wrote=
:
>>> Yes.
>>>
>>> Things change that's life.
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Feb 25, 2014, at 8:16 PM, Brian Campbell=20
>>> 
>>> wrote:
>>>
>>> Wasn't this originally announced with a different start time and=20
>>> Connect and OAuth happening in the opposite order?
>>>
>>>
>>> On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig=20
>>>  wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Lucy organized a room for our informal discussion about OAuth=20
>>>> (followed by the OpenID Connect meeting). We will start at 10am and=20
>>>> the room is reserved till 3pm. Palace C is the meeting room. At=20
>>>> some point in time the OAuth meeting will turn into the OpenID=20
>>>> Connect meeting. For those who are interested I will give a privacy tu=
torial at 3pm in the Blenheim room.
>>>>
>>>> Mike, Nat, John, and others might have more information about the=20
>>>> agenda for the OpenID Connect meeting. For the OAuth meeting Derek=20
>>>> and I were planning to use the time to prepare the security=20
>>>> discussions for the official OAuth WG meeting. I am sure we will=20
>>>> arrange further meeting slots during the week to give enough room=20
>>>> for socializing and generating new ideas.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 nobody Thu Feb 27 11:48:13 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3801A065C for ; Thu, 27 Feb 2014 11:48:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yHL9tOsKzvX for ; Thu, 27 Feb 2014 11:48:06 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65FE41A065D for ; Thu, 27 Feb 2014 11:48:06 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id u56so3344594wes.17 for ; Thu, 27 Feb 2014 11:48:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=VD6FG+2Fxqlqfyzgw9hCOqGG8kW7ijSGc/+31lo5OXI=; b=buSsHF0FFxqczuOTvk3wNJpwpyzDgIl7416BXHNig37YhuIy9apzT6RWQ25sklBZkV wZWsqxwVdvf7NLrL3yVxHWQ37zeamO6lXzvTTzuIxpvPhvUsvW8ec+zy3+t6HBY1s/K1 ++rvoQZyVynvifWywRf5bXQPF+ZAkW3whNBedF7gDIYAiKEDeR7dx2niFK/ZNR2bHQ5K qw+IL4Q/NoCdYjCyELjZT718zQCoCrD7Bc8nFxuTHGBWZMCCYy7iaiiI4mDaPBonMbr6 1eg4R2boonaA6cAFVvcVToAH0rmNN+ZSARNEphpPWhNDKmjHcZ4mbgYTwFwqMeeoqSih MgKw==
X-Gm-Message-State: ALoCoQn982KFJkRKw+W8/ndOvdSM6QAMcdmzIEIqsAUTAM+DYOCUfG4tDq0uaGwpK2ciss2mdEz5
X-Received: by 10.194.82.105 with SMTP id h9mr9313665wjy.52.1393530483979; Thu, 27 Feb 2014 11:48:03 -0800 (PST)
Received: from [192.168.50.167] (80.224.32.125.static.user.ono.com. [80.224.32.125]) by mx.google.com with ESMTPSA id f3sm18082824wiv.2.2014.02.27.11.48.00 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Feb 2014 11:48:01 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_7564E9EB-852C-4591-AFC3-5C89B59C36FB"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 27 Feb 2014 20:48:01 +0100
Message-Id: 
References:   <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>  <334fb1d7c15d4c92839b7799929c05ff@BLUPR03MB309.namprd03.prod.outlook.com> <7DFFB4D1-3086-4C33-A0B7-7B6A5A1841C5@ve7jtb.com> 
To: Lucy Lynch 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Nff6CRlAfBg59-FZP7W5UQH8IEc
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Feb 2014 19:48:09 -0000

--Apple-Mail=_7564E9EB-852C-4591-AFC3-5C89B59C36FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The Connect WG has a time 1pm - 3pm agenda and attendance confirmation =
page.   https://openid-ietf-89.eventbrite.com

Durring the Proof of possession call Jan 28 there was consensus to have =
a F2F to discuss the drafts prior to the WG meeting.=20
Some people were not arriving until the afternoon so on the call we =
decided to ask the IETF to extend the room for the Connect meeting to =
5pm so that we could meet from 3-5 pm.

I subsequently made the noon to 5pm room request on the 28th.

At some point after that the OAuth WG chair contacted Lucy asking for =
the meeting to be from 10 - 3pm due to a conflict he had in the =
afternoon.

I am not a chair or any other furniture of the OAuth WG.   If people are =
unavailable in the morning and want to discuss OAuth things after the =
Connect meeting as originally planned and the room is available I will =
be there.=20

Pleas direct further questions regarding OAuth meeting times to the =
appropriate furniture.

Deepest Regards
John B.

On Feb 26, 2014, at 6:15 PM, Lucy Lynch  wrote:

> On Wed, 26 Feb 2014, John Bradley wrote:
>=20
>> I asked for the room from 12 to 5.  The chair had the time changed so =
we reserved the room from 10 to 3pm.
>>=20
>> We would need to talk to Lucy to see if we could have the time =
extended past 3 for additional OAuth related meetings.
>>=20
>> I don't know if the room is booked for something else after 3 but we =
could likely find out.
>=20
> I can check - it would help if everyone agreed on times and topics.
>=20
>> John B.
>>=20
>> On Feb 26, 2014, at 1:57 AM, Anthony Nadalin  =
wrote:
>>=20
>>> Agree, the OAUTH meeting should change to afternoon
>>>=20
>>> -----Original Message-----
>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian =
Campbell
>>> Sent: Tuesday, February 25, 2014 2:56 PM
>>> To: John Bradley
>>> Cc: oauth
>>> Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, =
March 2
>>>=20
>>> Yes, I'm familiar with life and I'm aware that things do change. And =
I have no doubt that scheduling this stuff is more than a little =
difficult. But with these Sunday meetings and the vast majority of us =
traveling internationally, it'd be really helpful if the timing can be =
nailed down as early as is reasonable and changes can be avoided.
>>>=20
>>>=20
>>>=20
>>> On Tue, Feb 25, 2014 at 12:58 PM, John Bradley  =
wrote:
>>>> Yes.
>>>>=20
>>>> Things change that's life.
>>>>=20
>>>>=20
>>>>=20
>>>> Sent from my iPhone
>>>>=20
>>>> On Feb 25, 2014, at 8:16 PM, Brian Campbell
>>>> 
>>>> wrote:
>>>>=20
>>>> Wasn't this originally announced with a different start time and
>>>> Connect and OAuth happening in the opposite order?
>>>>=20
>>>>=20
>>>> On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig
>>>>  wrote:
>>>>>=20
>>>>> Hi all,
>>>>>=20
>>>>> Lucy organized a room for our informal discussion about OAuth
>>>>> (followed by the OpenID Connect meeting). We will start at 10am =
and
>>>>> the room is reserved till 3pm. Palace C is the meeting room. At =
some
>>>>> point in time the OAuth meeting will turn into the OpenID Connect
>>>>> meeting. For those who are interested I will give a privacy =
tutorial at 3pm in the Blenheim room.
>>>>>=20
>>>>> Mike, Nat, John, and others might have more information about the
>>>>> agenda for the OpenID Connect meeting. For the OAuth meeting Derek
>>>>> and I were planning to use the time to prepare the security
>>>>> discussions for the official OAuth WG meeting. I am sure we will
>>>>> arrange further meeting slots during the week to give enough room =
for
>>>>> socializing and generating new ideas.
>>>>>=20
>>>>> Ciao
>>>>> Hannes
>>>>>=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
>>=20


--Apple-Mail=_7564E9EB-852C-4591-AFC3-5C89B59C36FB
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjI3MTk0ODAyWjAjBgkqhkiG9w0BCQQxFgQU9bG7ipL/
9nACaeoa2yWtcjaUKXwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAUYDeNK74IUw4DFChQ02MCRHrIHLDoGVbHxOzT7l0
oJQEReKL4JVFMWHoFQdnJy4H0iXrrfGQIziFxArHXWNLzMC3HqSAvYXBsr8SSI4Kkdr/Hz4DIk0J
vZOU2cfQ7l72SxtC035BUbRfiZEA9ZZIPA4QdUgHAKJq0tVvkgrNZENF6MjuyvZuPtqjfPfjwhpA
WfObxgzQ/+I+9rkZRrNWyGnZjOVOVmkLRoD3ULXvNi41/sycNi3CPusA8dhjfLQ2bIN5hF+mALYa
9YAork5bkZLHMvb8c9Y+H2IL1cJpyUmSd0LoJ3J0isa1gDJ/PMCmQYiMpnAChqpomthdrAUXZgAA
AAAAAA==

--Apple-Mail=_7564E9EB-852C-4591-AFC3-5C89B59C36FB--


From nobody Fri Feb 28 06:22:05 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB64D1A0763 for ; Fri, 28 Feb 2014 06:22:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.513
X-Spam-Level: 
X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9Z2v_uysBHf for ; Fri, 28 Feb 2014 06:22:01 -0800 (PST)
Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id 863971A0574 for ; Fri, 28 Feb 2014 06:22:01 -0800 (PST)
Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKUxCbh/6x3ZL5OHWiEQcbYK6D11QUc4sh@postini.com; Fri, 28 Feb 2014 06:22:00 PST
Received: by mail-ie0-f179.google.com with SMTP id to1so3440164ieb.38 for ; Fri, 28 Feb 2014 06:21:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=lDcM9iHKRwJX30T94daWuMqUy2KhJQywKz+n4aS543U=; b=bDkPprUiHctiZ0kf26lLwZBU/K7jQdX65R2MnBaCAW9lgpzaJjdrSzaqM7SwyeY679 cCWIVP+mA9wvCZIzguzbRgcWr/LyOrxsfVtbiW5KYSU9nWik/Z4VSwxVajxh1iK8WuqL JUhOmwZl667sVpSgBTF5hKLYp2V5/TKTXBzOfzWTunWTE9GoH6ykHw+6ea5dWJocHRVX RbuAHeqOsfDmkzWlsG8db9iMoRLdiY5lPkzR3/tAq2UXHp4A4lgtaW96uWgnG7GTBNba TP1YRWX9w41iAEa3smmLl6KS1FqHgphcxfaMcdueQl794ruN1wYfjaQxyuumpBLPGnM8 MAvw==
X-Gm-Message-State: ALoCoQkHMj1Q7jfqT7ygAmqaJ18y3LJIKs8FrEdF7qUgDMXMcicrSTJXkdA+sPBZCqid4RJN3MUGju6TRnMO4lOLIWluAQ4jXASh2zFnxzPDzgHyYXHntK1KQheMWnP11h3pXc5f3mIi0uXHnnSqYoaodVsZl6HyWA==
X-Received: by 10.50.137.100 with SMTP id qh4mr4493415igb.4.1393597319558; Fri, 28 Feb 2014 06:21:59 -0800 (PST)
X-Received: by 10.50.137.100 with SMTP id qh4mr4493399igb.4.1393597319395; Fri, 28 Feb 2014 06:21:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.65.4 with HTTP; Fri, 28 Feb 2014 06:21:29 -0800 (PST)
In-Reply-To: 
References:   <3818574F-C5EF-42E7-A692-8FBDFC3E75DA@ve7jtb.com>  <334fb1d7c15d4c92839b7799929c05ff@BLUPR03MB309.namprd03.prod.outlook.com> <7DFFB4D1-3086-4C33-A0B7-7B6A5A1841C5@ve7jtb.com>  
From: Brian Campbell 
Date: Fri, 28 Feb 2014 07:21:29 -0700
Message-ID: 
To: John Bradley 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nIzoCrcZL9FqClg3jgqHOO19pc0
Cc: Lucy Lynch , oauth 
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2014 14:22:04 -0000

Likewise I am not any furniture of the OAuth WG. But I am happy to say
that, thanks to Lucy for arranging the details, the room is now
available from 10 - 5 on Sunday with the following rough schedule.

10:00 - noon    OAuth session w/Chairs in attendance
noon - 3           OpenID Connect
3 -5                  Room available for additional OAuth side meeting(s)

There will coffee and soft drinks in the room as well as a box lunch
for 25 folks around noon.

FWIW John, I've always thought of you as more of the coffee table of
the OAuth WG.

On Thu, Feb 27, 2014 at 12:48 PM, John Bradley  wrote:
> The Connect WG has a time 1pm - 3pm agenda and attendance confirmation pa=
ge.   https://openid-ietf-89.eventbrite.com
>
> Durring the Proof of possession call Jan 28 there was consensus to have a=
 F2F to discuss the drafts prior to the WG meeting.
> Some people were not arriving until the afternoon so on the call we decid=
ed to ask the IETF to extend the room for the Connect meeting to 5pm so tha=
t we could meet from 3-5 pm.
>
> I subsequently made the noon to 5pm room request on the 28th.
>
> At some point after that the OAuth WG chair contacted Lucy asking for the=
 meeting to be from 10 - 3pm due to a conflict he had in the afternoon.
>
> I am not a chair or any other furniture of the OAuth WG.   If people are =
unavailable in the morning and want to discuss OAuth things after the Conne=
ct meeting as originally planned and the room is available I will be there.
>
> Pleas direct further questions regarding OAuth meeting times to the appro=
priate furniture.
>
> Deepest Regards
> John B.
>
> On Feb 26, 2014, at 6:15 PM, Lucy Lynch  wrote:
>
>> On Wed, 26 Feb 2014, John Bradley wrote:
>>
>>> I asked for the room from 12 to 5.  The chair had the time changed so w=
e reserved the room from 10 to 3pm.
>>>
>>> We would need to talk to Lucy to see if we could have the time extended=
 past 3 for additional OAuth related meetings.
>>>
>>> I don't know if the room is booked for something else after 3 but we co=
uld likely find out.
>>
>> I can check - it would help if everyone agreed on times and topics.
>>
>>> John B.
>>>
>>> On Feb 26, 2014, at 1:57 AM, Anthony Nadalin  wr=
ote:
>>>
>>>> Agree, the OAUTH meeting should change to afternoon
>>>>
>>>> -----Original Message-----
>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbel=
l
>>>> Sent: Tuesday, February 25, 2014 2:56 PM
>>>> To: John Bradley
>>>> Cc: oauth
>>>> Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March=
 2
>>>>
>>>> Yes, I'm familiar with life and I'm aware that things do change. And I=
 have no doubt that scheduling this stuff is more than a little difficult. =
But with these Sunday meetings and the vast majority of us traveling intern=
ationally, it'd be really helpful if the timing can be nailed down as early=
 as is reasonable and changes can be avoided.
>>>>
>>>>
>>>>
>>>> On Tue, Feb 25, 2014 at 12:58 PM, John Bradley  wro=
te:
>>>>> Yes.
>>>>>
>>>>> Things change that's life.
>>>>>
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Feb 25, 2014, at 8:16 PM, Brian Campbell
>>>>> 
>>>>> wrote:
>>>>>
>>>>> Wasn't this originally announced with a different start time and
>>>>> Connect and OAuth happening in the opposite order?
>>>>>
>>>>>
>>>>> On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig
>>>>>  wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Lucy organized a room for our informal discussion about OAuth
>>>>>> (followed by the OpenID Connect meeting). We will start at 10am and
>>>>>> the room is reserved till 3pm. Palace C is the meeting room. At some
>>>>>> point in time the OAuth meeting will turn into the OpenID Connect
>>>>>> meeting. For those who are interested I will give a privacy tutorial=
 at 3pm in the Blenheim room.
>>>>>>
>>>>>> Mike, Nat, John, and others might have more information about the
>>>>>> agenda for the OpenID Connect meeting. For the OAuth meeting Derek
>>>>>> and I were planning to use the time to prepare the security
>>>>>> discussions for the official OAuth WG meeting. I am sure we will
>>>>>> arrange further meeting slots during the week to give enough room fo=
r
>>>>>> socializing and generating new ideas.
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>>
>