From zachary.zeltsan@alcatel-lucent.com Thu Apr 1 08:13:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D80D3A69D0 for ; Thu, 1 Apr 2010 08:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x890VooE+hEK for ; Thu, 1 Apr 2010 08:13:39 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id C800A3A6901 for ; Thu, 1 Apr 2010 08:13:39 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o31FE8gZ006163; Thu, 1 Apr 2010 10:14:09 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o31FE6S2009463; Thu, 1 Apr 2010 10:14:08 -0500 (CDT) Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 1 Apr 2010 10:14:06 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Eran Hammer-Lahav'" , OAuth WG Date: Thu, 1 Apr 2010 10:14:05 -0500 Thread-Topic: Draft progress update Thread-Index: AcrROctwFgBMPFnTVEKtDwmr4+8hcAAbGpPg Message-ID: <5710F82C0E73B04FA559560098BF95B124F7A92BE0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B124F7A92BE0USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:13:45 -0000 --_000_5710F82C0E73B04FA559560098BF95B124F7A92BE0USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eran, The progress is good indeed. I believe that the following comment on the draft applies also to some prev= ious versions of OAuth specifications. In my opinion, the description of step A of the Web Callback Flow implies t= hat a client is an HTTP server: (A) The web client initiates the flow by redirecting the end user's user-agent to the authorization endpoint ... (If it is the HTTP redirection, then the client has to be an HTTP server). If an OAuth client has to be an HTTP server in order to participate in OAut= h flow, then the draft's definition of client appears to be incomplete: client An HTTP client capable of making authenticated requests for protected resources using the OAuth protocol Should not the definition reflect the fact that client has to be also an HT= TP server (which appears to be the case at least for the Web Callback Flow)= ? Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Wednesday, March 31, 2010 9:22 PM To: OAuth WG Subject: [OAUTH-WG] Draft progress update I'm making good progress working off David's draft and bringing text from WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So fa= r it is largely in line with David's proposal and the majority of changes are purely editorial. The only significant change I have made (which is of course open to debate) is renaming all the authorization flows parameters. I dropped the oauth_ prefix (no real need since these are purely OAuth endpoints, not protected resources), and made most of the parameter names shorter. I am not done so they are not consistent yet. You can follow my progress (changes every few hours) at: http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oaut= h .txt Please feel free to comment on anything you like or dislike. I will publish the whole thing as an I-D once it is feature complete for the WG to discuss before we promote this to a WG draft. I hope to be done with the initial draft by middle of next week (I'll be flying most of Fri-Sat so no progress over the weekend). EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_5710F82C0E73B04FA559560098BF95B124F7A92BE0USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eran,

 

The progress is good indeed.

 

I believe that the following comment on the draft applies also to s= ome previous versions of OAuth specifications.

 

In my opinion, the description of step A of the Web Callback Flow implies that a client

is an HTTP server:

(=
A)  The web client initiates the flow by redirecting the end user's

        user-agent to the authorization endpoint ...

 

(If it is the HTTP redirection, then the client has to be an HTTP server).

 

If an OAuth client has to be an HTTP server in order to participate= in OAuth flow, then the draft’s definition of client appears to be incom= plete:

<=
o:p> 
client<=
/o:p>
  =
       An HTTP client capable of making authe=
nticated requests for

         protected resource= s using the OAuth protocol

 

Should not the definition reflect the fact that client has to be al= so an HTTP server (which appears to be the case at least for the Web Callback Flo= w)?

 

Zachary

 

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav
Sent: Wednesday, March 31, 2010 9:22 PM
To: OAuth WG
Subject: [OAUTH-WG] Draft progress update

 

I'm making good progress working off David's draft and bringing tex= t from

WRAP into it, as well as from OAuth 1.0a, and my token auth proposa= l. So far

it is largely in line with David's proposal and the majority of cha= nges are

purely editorial.

 

The only significant change I have made (which is of course open to debate)

is renaming all the authorization flows parameters. I dropped the oauth_

prefix (no real need since these are purely OAuth endpoints, not protected

resources), and made most of the parameter names shorter. I am not = done so

they are not consistent yet.

 

You can follow my progress (changes every few hours) at:=

 

http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-i= etf-oauth

.txt

 

Please feel free to comment on anything you like or dislike. I will publish

the whole thing as an I-D once it is feature complete for the WG to discuss

before we promote this to a WG draft.

 

I hope to be done with the initial draft by middle of next week (I'= ll be

flying most of Fri-Sat so no progress over the weekend).=

 

EHL

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

--_000_5710F82C0E73B04FA559560098BF95B124F7A92BE0USNAVSXCHMBSA_-- From eran@hueniverse.com Thu Apr 1 08:33:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3C43A6A81 for ; Thu, 1 Apr 2010 08:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq2c2oiyw7ua for ; Thu, 1 Apr 2010 08:33:23 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 411F13A6B3A for ; Thu, 1 Apr 2010 08:33:01 -0700 (PDT) Received: (qmail 24091 invoked from network); 1 Apr 2010 15:33:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Apr 2010 15:33:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Apr 2010 08:32:34 -0700 From: Eran Hammer-Lahav To: Zachary Zeltsan , OAuth WG Date: Thu, 1 Apr 2010 08:32:31 -0700 Thread-Topic: Draft progress update Thread-Index: AcrROctwFgBMPFnTVEKtDwmr4+8hcAAbGpPgAAKVUbw= Message-ID: In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F7A92BE0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7DA0A9F31AF0eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:33:29 -0000 --_000_C7DA0A9F31AF0eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a correct observation but I am not sure if it would be useful to ch= ange the definition. The current definition isn't wrong, just (sometimes) i= ncomplete. An OAuth client is an HTTP client speaking OAuth, but for the pu= rpose of obtaining a token using the callback flow, it also has to have HTT= P server capabilities. I don't think that voids the current definition. I'll tweak the wording specific to the callback flow. EHL On 4/1/10 8:14 AM, "Zachary Zeltsan" w= rote: Eran, The progress is good indeed. I believe that the following comment on the draft applies also to some prev= ious versions of OAuth specifications. In my opinion, the description of step A of the Web Callback Flow implies t= hat a client is an HTTP server: (A) The web client initiates the flow by redirecting the end user's user-agent to the authorization endpoint ... (If it is the HTTP redirection, then the client has to be an HTTP server). If an OAuth client has to be an HTTP server in order to participate in OAut= h flow, then the draft's definition of client appears to be incomplete: client An HTTP client capable of making authenticated requests for protected resources using the OAuth protocol Should not the definition reflect the fact that client has to be also an HT= TP server (which appears to be the case at least for the Web Callback Flow)= ? Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Wednesday, March 31, 2010 9:22 PM To: OAuth WG Subject: [OAUTH-WG] Draft progress update I'm making good progress working off David's draft and bringing text from WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So fa= r it is largely in line with David's proposal and the majority of changes are purely editorial. The only significant change I have made (which is of course open to debate) is renaming all the authorization flows parameters. I dropped the oauth_ prefix (no real need since these are purely OAuth endpoints, not protected resources), and made most of the parameter names shorter. I am not done so they are not consistent yet. You can follow my progress (changes every few hours) at: http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oaut= h .txt Please feel free to comment on anything you like or dislike. I will publish the whole thing as an I-D once it is feature complete for the WG to discuss before we promote this to a WG draft. I hope to be done with the initial draft by middle of next week (I'll be flying most of Fri-Sat so no progress over the weekend). EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C7DA0A9F31AF0eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Draft progress update This is a correct observation but I am not sure if it would be useful= to change the definition. The current definition isn’t wrong, just (= sometimes) incomplete. An OAuth client is an HTTP client speaking OAuth, bu= t for the purpose of obtaining a token using the callback flow, it also has= to have HTTP server capabilities. I don’t think that voids the curre= nt definition.

I’ll tweak the wording specific to the callback flow.

EHL


On 4/1/10 8:14 AM, "Zachary Zeltsan" <zachary.zeltsan@alcatel-lucent.com> wrote:
Eran,
 
The progress is good indeed.
 
I believe that the following comment on the draft applies also to some prev= ious versions of OAuth specifications.
 
In my opinion, the description of step A of the Web Callback Flow implies t= hat a client
is an HTTP server:
(A)  The web client initiates the flow by redirecting the end user's         user-agent to the authoriza= tion endpoint ...
 
(If it is the HTTP redirection, then the client has to be an HTTP server).<= BR>  
If an OAuth client has to be an HTTP server in order to participate in OAut= h flow, then the draft’s definition of client appears to be incomplet= e:
 
client
         An HTTP client capabl= e of making authenticated requests for
         protected resources u= sing the OAuth protocol
 
Should not the definition reflect the fact that client has to be also an HT= TP server (which appears to be the case at least for the Web Callback Flow)= ?
 
Zachary
 
-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On B= ehalf Of Eran Hammer-Lahav
Sent: Wednesday, March 31, 2010 9:22 PM
To: OAuth WG
Subject: [OAUTH-WG] Draft progress update
 
I'm making good progress working off David's draft and bringing text from WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So fa= r
it is largely in line with David's proposal and the majority of changes are=
purely editorial.
 
The only significant change I have made (which is of course open to debate)=
is renaming all the authorization flows parameters. I dropped the oauth_ prefix (no real need since these are purely OAuth endpoints, not protected<= BR> resources), and made most of the parameter names shorter. I am not done so<= BR> they are not consistent yet.
 
You can follow my progress (changes every few hours) at:
 
http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/d= raft-ietf-oauth
.txt
 
Please feel free to comment on anything you like or dislike. I will publish=
the whole thing as an I-D once it is feature complete for the WG to discuss=
before we promote this to a WG draft.
 
I hope to be done with the initial draft by middle of next week (I'll be flying most of Fri-Sat so no progress over the weekend).
 
EHL
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C7DA0A9F31AF0eranhueniversecom_-- From mscurtescu@google.com Thu Apr 1 09:45:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6833E3A6AE0 for ; Thu, 1 Apr 2010 09:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.197 X-Spam-Level: X-Spam-Status: No, score=-104.197 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsvyWwxq5IvL for ; Thu, 1 Apr 2010 09:45:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2186F3A698A for ; Thu, 1 Apr 2010 09:45:42 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o31GkDKv018629 for ; Thu, 1 Apr 2010 09:46:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270140374; bh=QtWguia+X7ki013q6rFeQVEuHVQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=g4MBlzuwmJ4ly1/44y3rKFZCCKdPUypTKxTzLD/OWOF6IjpRa1wfkWKhdgkZESyH8 74rPMKlB69gxr950vgAKg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=yTjWh1YwMksxirqebPwj9fd9YIY6Ns9LRsWKo9fpYA8WW5rXwQCa/sfmxxMow6u6l w5JaG2MJ4NWc39TWqiaow== Received: from pzk37 (pzk37.prod.google.com [10.243.19.165]) by kpbe14.cbf.corp.google.com with ESMTP id o31GkCi9011934 for ; Thu, 1 Apr 2010 09:46:12 -0700 Received: by pzk37 with SMTP id 37so1370204pzk.7 for ; Thu, 01 Apr 2010 09:46:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Thu, 1 Apr 2010 09:45:52 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Thu, 1 Apr 2010 09:45:52 -0700 Received: by 10.140.255.10 with SMTP id c10mr683741rvi.289.1270140372119; Thu, 01 Apr 2010 09:46:12 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 16:45:44 -0000 Hi Eran, On Wed, Mar 31, 2010 at 9:17 PM, Eran Hammer-Lahav wrote: > Hey Marius, > > On 3/31/10 8:37 PM, "Marius Scurtescu" wrote: > >> On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav >> wrote: >>> The only significant change I have made (which is of course open to debate) >>> is renaming all the authorization flows parameters. I dropped the oauth_ >>> prefix (no real need since these are purely OAuth endpoints, not protected >>> resources), and made most of the parameter names shorter. I am not done so >>> they are not consistent yet. >> >> Having a common prefix for all parameters is quite important IMO. It >> allows parties >> to define and pass additional, non-standard, parameters. > > Non-standard parameter hurt interoperability. The question is whether the > right approach is to add a prefix to the protocol parameters or to the > extension parameters (such as x_), or none. I agree that non-standard parameters are far from ideal, but they are used in practice for various reasons. > What prevents a custom parameter to collide with a standard extension not > supported by the server or someone else's custom parameter? If we are > serious about parameter collision (which I doubt given past sentiments on > registries etc.), we should require all parameters to register unless they > have some special custom prefix. That's a different issue IMO. In general if you use non-standard stuff you are on your own. We should try to protect the standard part and I think a prefix helps. > In other word, adding the oauth_ prefix to the core parameters doesn't > really accomplish much, other than making requests longer. In the past, > people wanted to define extension parameters starting with oauth_ and we > didn't really reach consensus on whether to allow it or not. Then we played > with xoauth_ for a while, then went back and just allowed oauth_ for > extensions. > > If we keep the oauth_ prefix, do we also require a registry for extensions? > Do we define another prefix? Do we create a registry for extension prefixes? > This gets bad really fast. I don't see how dropping the prefix solves any of these problems. I think it just makes matters worse. >> Also, quite >> often parameters >> are added to existing URLs, and a prefix helps prevent collisions. > > Extension parameters should never conflict with core parameter because we > know all the core parameters before we write custom ones... > > This is only for the OAuth-specific endpoint (authorization endpoint), not > the protected resource endpoint in which we will still use oauth_token (the > only parameter added to protected resource requests). Yes, this is only for OAuth endpoints, but all kinds of frameworks will be used to implement them I can imagne that many of them will use their own parameters. Also, many implementation will probably choose to pass state through the callback URL, as query parameters (even though there is a special OAuth parameter for that). > What do you think? What are the reasons we would drop the prefix? So far the only one I heard was shorter messages, but I am not convinced this is a real problem. Marius From mscurtescu@google.com Thu Apr 1 09:51:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661463A686D for ; Thu, 1 Apr 2010 09:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.918 X-Spam-Level: X-Spam-Status: No, score=-99.918 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvHFiFKrBjkk for ; Thu, 1 Apr 2010 09:50:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A86683A67B4 for ; Thu, 1 Apr 2010 09:50:58 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [10.3.21.7]) by smtp-out.google.com with ESMTP id o31GpSXR004461 for ; Thu, 1 Apr 2010 18:51:28 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270140688; bh=PUxTyVIM1Ih5uzJAoF2V7KyRTOQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=xR9NFAF33WEyIcjc7GLEJHOsfL/1Mx2D6RAW/oXIVbUTmfBMKhciz4yN9msr3akI+ TKjo6PdhJSM8gk3zR6JyQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=X7ad2lCqhK7jcJf0vU0dAeE5RCBD4NhnPpnGDMd483l/RAO4HhEoZxAXjFI+FoQbv ePZK8vyP++koCn3MvjxxA== Received: from pvg2 (pvg2.prod.google.com [10.241.210.130]) by hpaq7.eem.corp.google.com with ESMTP id o31GpQGg019426 for ; Thu, 1 Apr 2010 18:51:27 +0200 Received: by pvg2 with SMTP id 2so634145pvg.0 for ; Thu, 01 Apr 2010 09:51:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Thu, 1 Apr 2010 09:51:04 -0700 (PDT) In-Reply-To: <0817C7B6-9FCD-463C-8FAD-DD5129234D55@facebook.com> References: <0817C7B6-9FCD-463C-8FAD-DD5129234D55@facebook.com> From: Marius Scurtescu Date: Thu, 1 Apr 2010 09:51:04 -0700 Received: by 10.141.213.31 with SMTP id p31mr736427rvq.21.1270140684099; Thu, 01 Apr 2010 09:51:24 -0700 (PDT) Message-ID: To: Luke Shepard Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 16:51:00 -0000 Hi Luke, On Wed, Mar 31, 2010 at 10:28 PM, Luke Shepard wrote: > At first, I had the same first reaction as Marius, but after reading this > thread, I agree with Eran. Two observations: > 1/ OAuth endpoints are usually already namespaced as "oauth" - if there are > other endpoints that accept custom parameters, they can be defined > elsewhere. For example: > https://www.google.com/accounts/OAuthAuthorizeToken > https://api.login.yahoo.com/oauth/v2/request_auth > http://twitter.com/oauth/authorize The fact that the endpoint URL has "oauth" in it will not prevent any collisions. > 2/ We should fight to keep URLs short and leave out redundant information > where possible. We should leave out redundant information where possible. > Here are two sample URLs. The first is 12% shorter than the second. > http://facebook.com/oauth/authorize?mode=web_callback_access_request&client_id=123456789&callback=http://facebook.com/oauth/callback > http://facebook.com/oauth/authorize?oauth_mode=web_callback_access_request&oauth_client_id=123456789&oauth_callback=http://facebook.com/oauth/callback Yes, shorter in general is better. In this case it is just a bit shorter, it is exactly 18 chars shorter, regardless of the URL length. What is this buying us? End users don't have to type these URLs. Marius From justinsm@microsoft.com Thu Apr 1 11:08:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805C53A6AF9 for ; Thu, 1 Apr 2010 11:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHohGECl4hE2 for ; Thu, 1 Apr 2010 11:08:10 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 455523A6A3A for ; Thu, 1 Apr 2010 11:08:10 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 1 Apr 2010 11:08:42 -0700 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.239]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Thu, 1 Apr 2010 11:08:42 -0700 From: Justin Smith To: Eran Hammer-Lahav , OAuth WG Thread-Topic: Draft progress update Thread-Index: AcrROctwFgBMPFnTVEKtDwmr4+8hcAAhFhgg Date: Thu, 1 Apr 2010 18:06:16 +0000 Deferred-Delivery: Thu, 1 Apr 2010 18:07:00 +0000 Message-ID: <191F411E00E19F4E943ECDB6D65C6085168FCFE8@TK5EX14MBXC115.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:08:11 -0000 Eran, Good progress. A few comments below: Sec. 2.2. Flow Parameters: Comment 1: The recommendation to keep access tokens less than 255 chars see= ms bizarre. I'd like to remove it entirely. Previous threads have discussed= this. General comment on the flows: Comment 2: The scope parameter (from WRAP) is missing from all of the flows= . How does the client indicate which protected resource it intends to acces= s? In WRAP this was an optional parameter, but it seems important when a si= ngle AS controls access to many resources. Sec. 2.3. Client Credentials: "When requesting access from the authorizati= on server, the client identifies itself using its authorization-server-issu= ed client credentials." Comment 3: This isn't the case when the client is presenting a token issued= by another server. I suggest a change to something like the following: "Wh= en requesting access from the authorization server, the client identifies i= tself using client credentials known to the authorization server." =20 Sec. 2.4. User Delegation Flows: "Instead, the end user authenticates dire= ctly with the authorization server, and grants client access to its protect= ed resources." Comment 4: This is a minor nit, but the AS may not grant access to all of t= he PRs it controls access to. I suggest a change to something like the foll= owing: "... and grants client access to the requested protected resources." Sec. 2.6.2. SAML Assertion Flow: "Since requests to the authorization endp= oint result in the transmission of plain text credentials in the HTTP reque= st and response, ..." Comment 5: In the case of the SAML assertion flow (or an assertion of anoth= er format), it isn't necessarily the case that the assertion is plain text.= You might want to change it to: "...authorization endpoint may result in t= he...".=20 Comment 6: why is expiration optional in the response? It seems like it sho= uld be mandatory (as it is in the other flows). Sec. 2.6.1 Client Credentials Flow: Comment 7: Why require a refresh token? Assumedly the client has to keep th= e client_id and client_secret, so why not just present them to the AS again= for an access token? Brian/Marius/Dick brought this up earlier - you just = might not have gotten there yet. --justin -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Wednesday, March 31, 2010 6:22 PM To: OAuth WG Subject: [OAUTH-WG] Draft progress update I'm making good progress working off David's draft and bringing text from WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So fa= r it is largely in line with David's proposal and the majority of changes are purely editorial. The only significant change I have made (which is of course open to debate) is renaming all the authorization flows parameters. I dropped the oauth_ prefix (no real need since these are purely OAuth endpoints, not protected resources), and made most of the parameter names shorter. I am not done so they are not consistent yet. You can follow my progress (changes every few hours) at: http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oaut= h .txt Please feel free to comment on anything you like or dislike. I will publish the whole thing as an I-D once it is feature complete for the WG to discuss before we promote this to a WG draft. I hope to be done with the initial draft by middle of next week (I'll be flying most of Fri-Sat so no progress over the weekend). EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Thu Apr 1 11:21:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850993A6A6F for ; Thu, 1 Apr 2010 11:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.327 X-Spam-Level: X-Spam-Status: No, score=-104.327 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lEqpMJb0WD7 for ; Thu, 1 Apr 2010 11:21:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 20E253A696E for ; Thu, 1 Apr 2010 11:21:01 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o31ILV2H021784 for ; Thu, 1 Apr 2010 11:21:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270146091; bh=yAEMOMg2zZ1GItuKW0k6DeKuAtA=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=uqfci8QBvll9niVIaVciqu9pJpLHZVZPi6gxOqE/j9Lzwd03BjDyQrno+QweeElvN TdSaEpjpyKe4HZi99rDiA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:cc: content-type:x-system-of-record; b=cdjFGg307HGSPIGYj3bDfLiiZaaCJzZ58uf2zP3pHZW8rEujuCwR+a203CJlM3cJg 6WKWHZJaI8Ie/eQ/AphUw== Received: from pvc30 (pvc30.prod.google.com [10.241.209.158]) by kpbe14.cbf.corp.google.com with ESMTP id o31ILUiC006218 for ; Thu, 1 Apr 2010 11:21:30 -0700 Received: by pvc30 with SMTP id 30so557041pvc.20 for ; Thu, 01 Apr 2010 11:21:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Thu, 1 Apr 2010 11:21:08 -0700 (PDT) From: Marius Scurtescu Date: Thu, 1 Apr 2010 11:21:08 -0700 Received: by 10.141.12.8 with SMTP id p8mr852681rvi.160.1270146088179; Thu, 01 Apr 2010 11:21:28 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:21:05 -0000 Instead of "SAML Assertion Flow" maybe we should stick with the more generic "Assertion Flow". The assertion_format parameter allows you to define the assertion type. Maybe we can predefine some well know formats, for example: "saml1", "saml1.1" and "saml2"? Marius On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav wrote: > I'm making good progress working off David's draft and bringing text from > WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far > it is largely in line with David's proposal and the majority of changes are > purely editorial. > > The only significant change I have made (which is of course open to debate) > is renaming all the authorization flows parameters. I dropped the oauth_ > prefix (no real need since these are purely OAuth endpoints, not protected > resources), and made most of the parameter names shorter. I am not done so > they are not consistent yet. > > You can follow my progress (changes every few hours) at: > > http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth > .txt > > Please feel free to comment on anything you like or dislike. I will publish > the whole thing as an I-D once it is feature complete for the WG to discuss > before we promote this to a WG draft. > > I hope to be done with the initial draft by middle of next week (I'll be > flying most of Fri-Sat so no progress over the weekend). > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Thu Apr 1 11:22:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6503A696E for ; Thu, 1 Apr 2010 11:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aP+q8XJXONBA for ; Thu, 1 Apr 2010 11:22:30 -0700 (PDT) Received: from mail-iw0-f187.google.com (mail-iw0-f187.google.com [209.85.223.187]) by core3.amsl.com (Postfix) with ESMTP id 5AC543A6A22 for ; Thu, 1 Apr 2010 11:22:18 -0700 (PDT) Received: by iwn17 with SMTP id 17so942360iwn.19 for ; Thu, 01 Apr 2010 11:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=VNY8/+CSNCNjdUFg8IonKAEOEb/yN4jWdfjESxgfqJ4=; b=MfhkN0DZh0TwCMRGYWntFXOIJ4OLPqhkkPVRUrURM2BEgj0j7jLRzOHDqEITF3Qsk9 ZTULLBIKkDAz6zsKEnOPGvC8WFGvUJqKR8KMl+gMtAegXe090TKIut88vPIRujzmTsZ0 5WzcQOYjYPVfEktMMH37TzyKBiNRdHRrRr8TQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tjSp+DlAtO8LejZIYEN/el5VMaWkYpYubS2bobbO5kIRTmfk3Br+bwJKhsTCghDPeJ 8I5E2zctPrVcNca6wOeBSYgv3o5DtQUJoC9rbgVjNxwInHT2RnfZLcuHS8bK3yzdiPRG EBRyaxymFxYJ5yKO/50wfB3FsTEVw1ojXJoTM= MIME-Version: 1.0 Received: by 10.231.183.18 with HTTP; Thu, 1 Apr 2010 11:22:48 -0700 (PDT) In-Reply-To: References: <0817C7B6-9FCD-463C-8FAD-DD5129234D55@facebook.com> Date: Thu, 1 Apr 2010 11:22:48 -0700 Received: by 10.231.153.69 with SMTP id j5mr333458ibw.33.1270146168199; Thu, 01 Apr 2010 11:22:48 -0700 (PDT) Message-ID: From: David Recordon To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:22:31 -0000 On Thu, Apr 1, 2010 at 9:51 AM, Marius Scurtescu wrote: > Hi Luke, > On Wed, Mar 31, 2010 at 10:28 PM, Luke Shepard wrote: >> At first, I had the same first reaction as Marius, but after reading this >> thread, I agree with Eran. Two observations: >> 1/ OAuth endpoints are usually already namespaced as "oauth" - if there are >> other endpoints that accept custom parameters, they can be defined >> elsewhere. For example: >> https://www.google.com/accounts/OAuthAuthorizeToken >> https://api.login.yahoo.com/oauth/v2/request_auth >> http://twitter.com/oauth/authorize > > The fact that the endpoint URL has "oauth" in it will not prevent any > collisions. I think Luke's point is that OAuth deployment today is not being done by complex frameworks which add their own parameters, rather the majority of deployers make custom endpoints specifically for OAuth. I also don't see how the Authorization Server's web framework would add random parameters given that an unknown client is making the HTTP request to it. >> 2/ We should fight to keep URLs short and leave out redundant information >> where possible. We should leave out redundant information where possible. >> Here are two sample URLs. The first is 12% shorter than the second. >> http://facebook.com/oauth/authorize?mode=web_callback_access_request&client_id=123456789&callback=http://facebook.com/oauth/callback >> http://facebook.com/oauth/authorize?oauth_mode=web_callback_access_request&oauth_client_id=123456789&oauth_callback=http://facebook.com/oauth/callback > > Yes, shorter in general is better. In this case it is just a bit shorter, it is > exactly 18 chars shorter, regardless of the URL length. What is this buying > us? End users don't have to type these URLs. > > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mscurtescu@google.com Thu Apr 1 11:29:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F83F3A69C8 for ; Thu, 1 Apr 2010 11:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.414 X-Spam-Level: X-Spam-Status: No, score=-104.414 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6n6anZK5lnn for ; Thu, 1 Apr 2010 11:29:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 9192C3A6817 for ; Thu, 1 Apr 2010 11:29:09 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o31ITdfC003031 for ; Thu, 1 Apr 2010 11:29:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270146579; bh=iDDKMZT/L+c6echKHBaFhjTyVFQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=UF0QCK/vuwd5jpQr36Eyhifu8V5Bo5HgV4YWlOMA8U+hqRCbH6WTuDhN6UNz0KD2r fpVrWgM1hXh24LkkDRoRg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=KmcRLzyE1UHmWe02ZmDi98WamV/OaURls2f7tYPnIWWCx+jCEgdOO8o0c+z0cHf2/ KtKh2Pd1oJGJpodpUhkyQ== Received: from pzk15 (pzk15.prod.google.com [10.243.19.143]) by wpaz33.hot.corp.google.com with ESMTP id o31ITbZe021644 for ; Thu, 1 Apr 2010 11:29:38 -0700 Received: by pzk15 with SMTP id 15so511890pzk.26 for ; Thu, 01 Apr 2010 11:29:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Thu, 1 Apr 2010 11:29:17 -0700 (PDT) In-Reply-To: References: <0817C7B6-9FCD-463C-8FAD-DD5129234D55@facebook.com> From: Marius Scurtescu Date: Thu, 1 Apr 2010 11:29:17 -0700 Received: by 10.140.179.39 with SMTP id b39mr861394rvf.298.1270146577259; Thu, 01 Apr 2010 11:29:37 -0700 (PDT) Message-ID: To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:29:11 -0000 On Thu, Apr 1, 2010 at 11:22 AM, David Recordon wrote= : > On Thu, Apr 1, 2010 at 9:51 AM, Marius Scurtescu = wrote: >> Hi Luke, >> On Wed, Mar 31, 2010 at 10:28 PM, Luke Shepard w= rote: >>> At first, I had the same first reaction as Marius, but after reading th= is >>> thread, I agree with Eran. Two observations: >>> 1/ OAuth endpoints are usually already namespaced as "oauth" - if there= are >>> other endpoints that accept custom parameters, they can be defined >>> elsewhere. For example: >>> https://www.google.com/accounts/OAuthAuthorizeToken >>> https://api.login.yahoo.com/oauth/v2/request_auth >>> http://twitter.com/oauth/authorize >> >> The fact that the endpoint URL has "oauth" in it will not prevent any >> collisions. > > I think Luke's point is that OAuth deployment today is not being done > by complex frameworks which add their own parameters, rather the > majority of deployers make custom endpoints specifically for OAuth. =A0I > also don't see how the Authorization Server's web framework would add > random parameters given that an unknown client is making the HTTP > request to it. Not random, they can be query parameters that are part of the published URL, something like: http://example.com/auth?mode=3Doauth Also, not only the Authorization Server URLs can receive OAuth parameters in the query, the same applies to the client callback URL, and that one definitely can have random parameters. Marius From mscurtescu@google.com Thu Apr 1 11:37:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7953A6944 for ; Thu, 1 Apr 2010 11:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.382 X-Spam-Level: X-Spam-Status: No, score=-100.382 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuneExHtYSZz for ; Thu, 1 Apr 2010 11:37:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 62BF63A67D7 for ; Thu, 1 Apr 2010 11:37:31 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o31IbxXx028492 for ; Thu, 1 Apr 2010 20:37:59 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270147079; bh=+WnzKGShapfGUhkJJ3ghQ4OqXFo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Jn7nUAN61kpBYaaijMQUjNR20OcGtAJR0KVDreSSfBqVpabCloCAP+Sxyr6KBVCAE t+BZcQ6EqG40a2azuJ25g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=HmC4ugPEXrPF0vHb2hHQScRjIdme+IiolsfZVxsazkwoldeJn3Hv+vGHEm4Cw30sm k6X3vTGgAiPg66xXn5DDg== Received: from pzk1 (pzk1.prod.google.com [10.243.19.129]) by kpbe14.cbf.corp.google.com with ESMTP id o31IbvLx027844 for ; Thu, 1 Apr 2010 11:37:58 -0700 Received: by pzk1 with SMTP id 1so1154669pzk.18 for ; Thu, 01 Apr 2010 11:37:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Thu, 1 Apr 2010 11:37:37 -0700 (PDT) In-Reply-To: <191F411E00E19F4E943ECDB6D65C6085168FCFE8@TK5EX14MBXC115.redmond.corp.microsoft.com> References: <191F411E00E19F4E943ECDB6D65C6085168FCFE8@TK5EX14MBXC115.redmond.corp.microsoft.com> From: Marius Scurtescu Date: Thu, 1 Apr 2010 11:37:37 -0700 Received: by 10.140.252.3 with SMTP id z3mr98006rvh.3.1270147077140; Thu, 01 Apr 2010 11:37:57 -0700 (PDT) Message-ID: To: Justin Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:37:33 -0000 +1 on all comments, except for some question on 6... On Thu, Apr 1, 2010 at 11:06 AM, Justin Smith wrot= e: > Eran, > > Good progress. A few comments below: > > Sec. 2.2. =A0Flow Parameters: > Comment 1: The recommendation to keep access tokens less than 255 chars s= eems bizarre. I'd like to remove it entirely. Previous threads have discuss= ed this. > > General comment on the flows: > Comment 2: The scope parameter (from WRAP) is missing from all of the flo= ws. How does the client indicate which protected resource it intends to acc= ess? In WRAP this was an optional parameter, but it seems important when a = single AS controls access to many resources. > > Sec. 2.3. =A0Client Credentials: "When requesting access from the authori= zation server, the client identifies itself using its authorization-server-= issued client credentials." > Comment 3: This isn't the case when the client is presenting a token issu= ed by another server. I suggest a change to something like the following: "= When requesting access from the authorization server, the client identifies= itself using client credentials known to the authorization server." > > Sec. 2.4. =A0User Delegation Flows: "Instead, the end user authenticates = directly with the authorization server, and grants client access to its pro= tected resources." > Comment 4: This is a minor nit, but the AS may not grant access to all of= the PRs it controls access to. I suggest a change to something like the fo= llowing: "... and grants client access to the requested protected resources= ." > > Sec. 2.6.2. =A0SAML Assertion Flow: "Since requests to the authorization = endpoint result in the transmission of plain text credentials in the HTTP r= equest and response, ..." > Comment 5: In the case of the SAML assertion flow (or an assertion of ano= ther format), it isn't necessarily the case that the assertion is plain tex= t. You might want to change it to: "...authorization endpoint may result in= the...". > Comment 6: why is expiration optional in the response? It seems like it s= hould be mandatory (as it is in the other flows). SAML assertions contain the expiry inside, the OAuth "expires" parameter would be redundant, maybe this is way it is optional? But, do we want to make this parameter required in general? Why not leave it optional for all flows? What if an Authorization Server implements some other mechanism to expire them (number of uses for example) and a fixed expiry time does not make sense? > Sec. 2.6.1 Client Credentials Flow: > Comment 7: Why require a refresh token? Assumedly the client has to keep = the client_id and client_secret, so why not just present them to the AS aga= in for an access token? Brian/Marius/Dick brought this up earlier - you jus= t might not have gotten there yet. > > > --justin > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Eran Hammer-Lahav > Sent: Wednesday, March 31, 2010 6:22 PM > To: OAuth WG > Subject: [OAUTH-WG] Draft progress update > > I'm making good progress working off David's draft and bringing text from > WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So = far > it is largely in line with David's proposal and the majority of changes a= re > purely editorial. > > The only significant change I have made (which is of course open to debat= e) > is renaming all the authorization flows parameters. I dropped the oauth_ > prefix (no real need since these are purely OAuth endpoints, not protecte= d > resources), and made most of the parameter names shorter. I am not done s= o > they are not consistent yet. > > You can follow my progress (changes every few hours) at: > > http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oa= uth > .txt > > Please feel free to comment on anything you like or dislike. I will publi= sh > the whole thing as an I-D once it is feature complete for the WG to discu= ss > before we promote this to a WG draft. > > I hope to be done with the initial draft by middle of next week (I'll be > flying most of Fri-Sat so no progress over the weekend). > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Thu Apr 1 12:23:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A83C3A659C for ; Thu, 1 Apr 2010 12:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au8-m3lSktsS for ; Thu, 1 Apr 2010 12:23:07 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 184353A6862 for ; Thu, 1 Apr 2010 12:22:59 -0700 (PDT) Received: (qmail 12719 invoked from network); 1 Apr 2010 19:23:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Apr 2010 19:23:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Apr 2010 12:23:26 -0700 From: Eran Hammer-Lahav To: Justin Smith , OAuth WG Date: Thu, 1 Apr 2010 12:23:20 -0700 Thread-Topic: Draft progress update Thread-Index: AcrROctwFgBMPFnTVEKtDwmr4+8hcAAhFhggAASpdac= Message-ID: In-Reply-To: <191F411E00E19F4E943ECDB6D65C6085168FCFE8@TK5EX14MBXC115.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 19:23:11 -0000 Hi Justin, On 4/1/10 11:06 AM, "Justin Smith" wrote: > Sec. 2.2. Flow Parameters: > Comment 1: The recommendation to keep access tokens less than 255 chars s= eems > bizarre. I'd like to remove it entirely. Previous threads have discussed = this. It's marked as an open issue. I personally don't care much either way but can see the reasons behind those for and against a (short) hard limit. Experience has shown this is a problem as most libraries assume a certain size will work just fine and then blow up. Last time it was debated here it didn't end with a consensus call so feel free to ask the chairs for one or continue debating it. > General comment on the flows: > Comment 2: The scope parameter (from WRAP) is missing from all of the flo= ws. > How does the client indicate which protected resource it intends to acces= s? In > WRAP this was an optional parameter, but it seems important when a single= AS > controls access to many resources. I removed it (for now) because it was (way way) under specified. The only reason for a spec is interop. This parameter hurts interop because it force= s library to implement something they cannot understand, or understand based on one deployment. This debate has been going on for a long time and solving it by simply adding a placeholder for scope without *any* structure or definition is not how well designed protocols are written. I have always maintained that OAuth needs a basic facility to negotiate scope. It can be as simple as an opaque string identifying a set of resources (e.g. HTTP auth realms), a JSON string of key/value pairs, etc. But as present in WRAP and imported by David it is utterly useless (it is and under-specified SHOULD - I am not really sure what it is to be used for). Write a proposal and we can add it back. > Sec. 2.3. Client Credentials: "When requesting access from the authoriza= tion > server, the client identifies itself using its authorization-server-issue= d > client credentials." > Comment 3: This isn't the case when the client is presenting a token issu= ed by > another server. I suggest a change to something like the following: "When > requesting access from the authorization server, the client identifies it= self > using client credentials known to the authorization server." What token? The authorization endpoint isn't an OAuth-protected resource. =20 > Sec. 2.4. User Delegation Flows: "Instead, the end user authenticates > directly with the authorization server, and grants client access to its > protected resources." > Comment 4: This is a minor nit, but the AS may not grant access to all of= the > PRs it controls access to. I suggest a change to something like the follo= wing: > "... and grants client access to the requested protected resources." This isn't the old testament. No need to look for hidden meaning. The spec is about getting access to protected resources, generally dealing with *a* protected resource. How resources are segmented is beyond the scope. I thin= k it is more useful to talk about it using simpler assumptions - it doesn't prevent the more complex use cases. > Sec. 2.6.2. SAML Assertion Flow: "Since requests to the authorization > endpoint result in the transmission of plain text credentials in the HTTP > request and response, ..." > Comment 5: In the case of the SAML assertion flow (or an assertion of ano= ther > format), it isn't necessarily the case that the assertion is plain text. = You > might want to change it to: "...authorization endpoint may result in the.= ..". > Comment 6: why is expiration optional in the response? It seems like it s= hould > be mandatory (as it is in the other flows). I didn't really get to that part yet in my full rewrite - just imported it with small changes. The new spec has a simple authorization endpoint and it requires SSL/TLS (or other secure channels). The same applies to this flow. The assertion might not be plain text but the resulting token is. > Sec. 2.6.1 Client Credentials Flow: > Comment 7: Why require a refresh token? Assumedly the client has to keep = the > client_id and client_secret, so why not just present them to the AS again= for > an access token? Brian/Marius/Dick brought this up earlier - you just mig= ht > not have gotten there yet. Yep. On my list. Thanks! EHL >=20 > --justin >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Eran > Hammer-Lahav > Sent: Wednesday, March 31, 2010 6:22 PM > To: OAuth WG > Subject: [OAUTH-WG] Draft progress update >=20 > I'm making good progress working off David's draft and bringing text from > WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So = far > it is largely in line with David's proposal and the majority of changes a= re > purely editorial. >=20 > The only significant change I have made (which is of course open to debat= e) > is renaming all the authorization flows parameters. I dropped the oauth_ > prefix (no real need since these are purely OAuth endpoints, not protecte= d > resources), and made most of the parameter names shorter. I am not done s= o > they are not consistent yet. >=20 > You can follow my progress (changes every few hours) at: >=20 > http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oa= uth > .txt >=20 > Please feel free to comment on anything you like or dislike. I will publi= sh > the whole thing as an I-D once it is feature complete for the WG to discu= ss > before we promote this to a WG draft. >=20 > I hope to be done with the initial draft by middle of next week (I'll be > flying most of Fri-Sat so no progress over the weekend). >=20 > EHL >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 From eran@hueniverse.com Thu Apr 1 12:24:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7233A67B1 for ; Thu, 1 Apr 2010 12:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.905 X-Spam-Level: X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZSFU0eNjmFs for ; Thu, 1 Apr 2010 12:24:51 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 98C5D3A6359 for ; Thu, 1 Apr 2010 12:24:49 -0700 (PDT) Received: (qmail 27908 invoked from network); 1 Apr 2010 19:25:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Apr 2010 19:25:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Apr 2010 12:24:44 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Thu, 1 Apr 2010 12:24:39 -0700 Thread-Topic: SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrRyChEJ2Q3qJDIQPiIRztmGRHjggACNB4Z Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7DA410731B11eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 19:24:56 -0000 --_000_C7DA410731B11eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A generic assertion flow is too under-specified to be included. If a SAML2 = assertion flow isn't enough or useful, we should define what is and fully s= pecify it. The current text is still incomplete as it doesn't address how t= he assertion should be encoded in the request. EHL On 4/1/10 11:21 AM, "Marius Scurtescu" wrote: Instead of "SAML Assertion Flow" maybe we should stick with the more generic "Assertion Flow". The assertion_format parameter allows you to define the assertion type. Maybe we can predefine some well know formats, for example: "saml1", "saml1.1" and "saml2"? Marius On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav wr= ote: > I'm making good progress working off David's draft and bringing text from > WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So = far > it is largely in line with David's proposal and the majority of changes a= re > purely editorial. > > The only significant change I have made (which is of course open to debat= e) > is renaming all the authorization flows parameters. I dropped the oauth_ > prefix (no real need since these are purely OAuth endpoints, not protecte= d > resources), and made most of the parameter names shorter. I am not done s= o > they are not consistent yet. > > You can follow my progress (changes every few hours) at: > > http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oa= uth > .txt > > Please feel free to comment on anything you like or dislike. I will publi= sh > the whole thing as an I-D once it is feature complete for the WG to discu= ss > before we promote this to a WG draft. > > I hope to be done with the initial draft by middle of next week (I'll be > flying most of Fri-Sat so no progress over the weekend). > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --_000_C7DA410731B11eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: SAML Assertion Flow (was: Draft progress update) A generic assertion flow is too under-specified to be included. If a = SAML2 assertion flow isn’t enough or useful, we should define what is= and fully specify it. The current text is still incomplete as it doesnR= 17;t address how the assertion should be encoded in the request.

EHL


On 4/1/10 11:21 AM, "Marius Scurtescu" <mscurtescu@google.com> wrote:

Instead of "SAML Assertion Flow" = maybe we should stick with the more
generic "Assertion Flow".

The assertion_format parameter allows you to define the assertion
type. Maybe we can predefine
some well know formats, for example: "saml1", "saml1.1"= and "saml2"?

Marius



On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I'm making good progress working off David's draft and bringing text f= rom
> WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. = So far
> it is largely in line with David's proposal and the majority of change= s are
> purely editorial.
>
> The only significant change I have made (which is of course open to de= bate)
> is renaming all the authorization flows parameters. I dropped the oaut= h_
> prefix (no real need since these are purely OAuth endpoints, not prote= cted
> resources), and made most of the parameter names shorter. I am not don= e so
> they are not consistent yet.
>
> You can follow my progress (changes every few hours) at:
>
> http://github.com/theRazorBlade/draft-ietf-oauth/raw/mas= ter/draft-ietf-oauth
> .txt
>
> Please feel free to comment on anything you like or dislike. I will pu= blish
> the whole thing as an I-D once it is feature complete for the WG to di= scuss
> before we promote this to a WG draft.
>
> I hope to be done with the initial draft by middle of next week (I'll = be
> flying most of Fri-Sat so no progress over the weekend).
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
>

--_000_C7DA410731B11eranhueniversecom_-- From eran@hueniverse.com Thu Apr 1 12:29:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D813A696A for ; Thu, 1 Apr 2010 12:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu8xPzmRH2FN for ; Thu, 1 Apr 2010 12:29:11 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D0C5E3A6359 for ; Thu, 1 Apr 2010 12:29:08 -0700 (PDT) Received: (qmail 17128 invoked from network); 1 Apr 2010 19:29:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Apr 2010 19:29:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Apr 2010 12:29:29 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Thu, 1 Apr 2010 12:29:25 -0700 Thread-Topic: [OAUTH-WG] Draft progress update Thread-Index: AcrRyVALLd6mN3j2Qa6Nup2AxPPsogACFMoi Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 19:29:12 -0000 On 4/1/10 11:29 AM, "Marius Scurtescu" wrote: > Also, not only the Authorization Server URLs can receive OAuth > parameters in the query, > the same applies to the client callback URL, and that one definitely > can have random > parameters. We are discussing just the authorization endpoint, but if you look at the current draft, it proposes we limit client customization of the callbacks t= o the state parameter (i.e. No query allowed). This is a new. My take is that either we use the state parameter or we use custom query parameters (with prefix) but not both. I like the state parameter better (stronger interop and easier to pre-register URIs). EHL >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Thu Apr 1 12:32:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C903A6B2A for ; Thu, 1 Apr 2010 12:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZvi5YUZ9GAq for ; Thu, 1 Apr 2010 12:32:18 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 922143A6AA5 for ; Thu, 1 Apr 2010 12:32:11 -0700 (PDT) Received: (qmail 18918 invoked from network); 1 Apr 2010 19:32:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Apr 2010 19:32:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Apr 2010 12:31:55 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , Justin Smith Date: Thu, 1 Apr 2010 12:31:41 -0700 Thread-Topic: [OAUTH-WG] Draft progress update Thread-Index: AcrRynXs2tLDIPEwTem1eLpXD0pyRgAB35YQ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 19:32:19 -0000 On 4/1/10 11:37 AM, "Marius Scurtescu" wrote: > SAML assertions contain the expiry inside, the OAuth "expires" > parameter would be redundant, maybe this is way it is optional? The token expiration doesn't have to be the same as the assertion. > But, do we want to make this parameter required in general? Why not > leave it optional for all flows? What if an Authorization Server > implements some other mechanism to expire them (number of uses for > example) and a fixed expiry time does not make sense? The expiration parameter should be optional everywhere. If it is not, its because I didn't get to it (or messed up). EHL From mscurtescu@google.com Thu Apr 1 12:59:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545DC3A6A7C for ; Thu, 1 Apr 2010 12:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.537 X-Spam-Level: X-Spam-Status: No, score=-100.537 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBdYX7SNdkaF for ; Thu, 1 Apr 2010 12:59:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 4C17D3A6A4C for ; Thu, 1 Apr 2010 12:59:18 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id o31Jxl75002813 for ; Thu, 1 Apr 2010 21:59:47 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270151988; bh=vCgjcY9tfSvZRLMo0b/jj5w6o/g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=En2ePVQgHgIK1POkSekA9UekKNlZbdjK84LmURxjbvTsPVOloJz8t2iKd6eCl2JkD HfwjtWFNKL6fuf8YUZ6hA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=E4wcTVPTahrry/DDLzFFN/bv4JTelP/ABA13xges4R27y3/RVtC6ucIltOW7mSguZ 5BEYx5QoIqJSf64ZknjuQ== Received: from pwi2 (pwi2.prod.google.com [10.241.219.2]) by kpbe13.cbf.corp.google.com with ESMTP id o31JxLTq030259 for ; Thu, 1 Apr 2010 14:59:46 -0500 Received: by pwi2 with SMTP id 2so1731096pwi.0 for ; Thu, 01 Apr 2010 12:59:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Thu, 1 Apr 2010 12:59:11 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Thu, 1 Apr 2010 12:59:11 -0700 Received: by 10.141.14.3 with SMTP id r3mr1033390rvi.28.1270151982272; Thu, 01 Apr 2010 12:59:42 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 19:59:19 -0000 On Thu, Apr 1, 2010 at 12:24 PM, Eran Hammer-Lahav wrote: > A generic assertion flow is too under-specified to be included. Can you please give some more details, why is that? For any assertion flow to work the client and the authorization server must trust each other, leaving the assertion format details up to them seems reasonable to me. Marius From mscurtescu@google.com Thu Apr 1 13:02:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6E83A68C8 for ; Thu, 1 Apr 2010 13:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.476 X-Spam-Level: X-Spam-Status: No, score=-104.476 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i60uU6BGDH3k for ; Thu, 1 Apr 2010 13:02:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 251703A6823 for ; Thu, 1 Apr 2010 13:02:49 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o31K3HHl017081 for ; Thu, 1 Apr 2010 13:03:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270152197; bh=WRSeVQy6NBr1dlJrjFScHU4SCIw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=nob4kVNrrM7HcJuB7sqFvkOC+U6W5SH5vWrHyE34kfumW6TryPi+PKPnqjCT13rpo dFi95A4Micv9aDkggKrYw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=PhS69jDDGtypsBD+27u+cp5pSQOYguVuUFcLpL7HL+dIlVms9yS3ef8ewUlg2BT3h Ly2dP8OWIn6k+H3MDFzeQ== Received: from pzk9 (pzk9.prod.google.com [10.243.19.137]) by wpaz13.hot.corp.google.com with ESMTP id o31K3G5T002709 for ; Thu, 1 Apr 2010 13:03:16 -0700 Received: by pzk9 with SMTP id 9so1488611pzk.21 for ; Thu, 01 Apr 2010 13:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Thu, 1 Apr 2010 13:02:56 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Thu, 1 Apr 2010 13:02:56 -0700 Received: by 10.141.53.4 with SMTP id f4mr1025724rvk.89.1270152196093; Thu, 01 Apr 2010 13:03:16 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 20:02:50 -0000 On Thu, Apr 1, 2010 at 12:31 PM, Eran Hammer-Lahav wrote: > > On 4/1/10 11:37 AM, "Marius Scurtescu" wrote: > >> SAML assertions contain the expiry inside, the OAuth "expires" >> parameter would be redundant, maybe this is way it is optional? > > The token expiration doesn't have to be the same as the assertion. Yep, sorry, I got mixed up. >> But, do we want to make this parameter required in general? Why not >> leave it optional for all flows? What if an Authorization Server >> implements some other mechanism to expire them (number of uses for >> example) and a fixed expiry time does not make sense? > > The expiration parameter should be optional everywhere. If it is not, its > because I didn't get to it (or messed up). Sounds great. Marius From mscurtescu@google.com Thu Apr 1 13:21:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365953A68FA for ; Thu, 1 Apr 2010 13:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.593 X-Spam-Level: X-Spam-Status: No, score=-103.593 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NAJSF16-kLl for ; Thu, 1 Apr 2010 13:21:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A381F3A685D for ; Thu, 1 Apr 2010 13:21:26 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [10.3.21.12]) by smtp-out.google.com with ESMTP id o31KLs8P003563 for ; Thu, 1 Apr 2010 13:21:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270153315; bh=Ox0q6OvXr96HIPcuTA64b9mLH1Q=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=v/82w3Uxkd8n3sHzAu781pOUhmPAeJazyWf9L33A9EvKYW9XYfFsh0Jtkr14MjxT+ yxmHRP8vS+u/ySm5O4Llg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=e9CN+fUhvPgq+s5XIVctVfDKZR8CgJfeCnR/9HwxN9lUVBM1bJKROXbXHOCgbAAXY dzY7brZaRZuS4W/U9r4tQ== Received: from pvg4 (pvg4.prod.google.com [10.241.210.132]) by hpaq12.eem.corp.google.com with ESMTP id o31KLqx0011609 for ; Thu, 1 Apr 2010 22:21:53 +0200 Received: by pvg4 with SMTP id 4so620319pvg.9 for ; Thu, 01 Apr 2010 13:21:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Thu, 1 Apr 2010 13:21:32 -0700 (PDT) In-Reply-To: References: <191F411E00E19F4E943ECDB6D65C6085168FCFE8@TK5EX14MBXC115.redmond.corp.microsoft.com> From: Marius Scurtescu Date: Thu, 1 Apr 2010 13:21:32 -0700 Received: by 10.141.23.16 with SMTP id a16mr1036298rvj.239.1270153312422; Thu, 01 Apr 2010 13:21:52 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 20:21:30 -0000 On Thu, Apr 1, 2010 at 12:23 PM, Eran Hammer-Lahav wr= ote: > On 4/1/10 11:06 AM, "Justin Smith" wrote: >> General comment on the flows: >> Comment 2: The scope parameter (from WRAP) is missing from all of the fl= ows. >> How does the client indicate which protected resource it intends to acce= ss? In >> WRAP this was an optional parameter, but it seems important when a singl= e AS >> controls access to many resources. > > I removed it (for now) because it was (way way) under specified. The only > reason for a spec is interop. This parameter hurts interop because it for= ces > library to implement something they cannot understand, or understand base= d > on one deployment. > > This debate has been going on for a long time and solving it by simply > adding a placeholder for scope without *any* structure or definition is n= ot > how well designed protocols are written. > > I have always maintained that OAuth needs a basic facility to negotiate > scope. It can be as simple as an opaque string identifying a set of > resources (e.g. HTTP auth realms), a JSON string of key/value pairs, etc. > But as present in WRAP and imported by David it is utterly useless (it is > and under-specified SHOULD - I am not really sure what it is to be used > for). > > Write a proposal and we can add it back. Except for trivial cases, the client needs to have custom code to access an= d process the protected resources. Scopes have meaning only for these resources and while obtaining an access token I think the scope can be treated as an opaque string. There is another issue with removing the scope parameter. In most cases a scope parameter will be needed in practice, if the spec does not specify one then an additional non-standard parameter must be used. But you also dropped the additional parameters. I don't see why an opaque scope parameter would create any problems for a library implementation. Working on such an implementation right now and opaque scopes are perfectly fine. >> Sec. 2.3. =A0Client Credentials: "When requesting access from the author= ization >> server, the client identifies itself using its authorization-server-issu= ed >> client credentials." >> Comment 3: This isn't the case when the client is presenting a token iss= ued by >> another server. I suggest a change to something like the following: "Whe= n >> requesting access from the authorization server, the client identifies i= tself >> using client credentials known to the authorization server." > > What token? The authorization endpoint isn't an OAuth-protected resource. > >> Sec. 2.4. =A0User Delegation Flows: "Instead, the end user authenticates >> directly with the authorization server, and grants client access to its >> protected resources." >> Comment 4: This is a minor nit, but the AS may not grant access to all o= f the >> PRs it controls access to. I suggest a change to something like the foll= owing: >> "... and grants client access to the requested protected resources." > > This isn't the old testament. No need to look for hidden meaning. The spe= c > is about getting access to protected resources, generally dealing with *a= * > protected resource. How resources are segmented is beyond the scope. I th= ink > it is more useful to talk about it using simpler assumptions - it doesn't > prevent the more complex use cases. I think this ties in with the scope parameter. When requesting authorizatio= n, if a client can also pass a scope parameter, then access is granted only to the resources that accept that scope and not to all resources controlled by this Authorization Server. Marius From cmortimore@salesforce.com Thu Apr 1 13:33:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD203A6847 for ; Thu, 1 Apr 2010 13:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.743 X-Spam-Level: X-Spam-Status: No, score=-4.743 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXP-Y5+l8cmF for ; Thu, 1 Apr 2010 13:33:43 -0700 (PDT) Received: from exprod8og119.obsmtp.com (exprod8og119.obsmtp.com [64.18.3.38]) by core3.amsl.com (Postfix) with SMTP id D30243A68E5 for ; Thu, 1 Apr 2010 13:33:42 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob119.postini.com ([64.18.7.12]) with SMTP ID DSNKS7UDR7Y1rMJ4jXhLwzqnQe62lM7Rc17N@postini.com; Thu, 01 Apr 2010 13:34:16 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Thu, 1 Apr 2010 13:34:14 -0700 From: Chuck Mortimore To: Eran Hammer-Lahav , Marius Scurtescu Date: Thu, 1 Apr 2010 13:34:14 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrRyChEJ2Q3qJDIQPiIRztmGRHjggACNB4ZAAJuH5U= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7DA51562FBFcmortimoresalesforcecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 20:33:49 -0000 --_000_C7DA51562FBFcmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As you've pointed out, the current text is in somewhat of a grey area. It= 's either over specified ( remove any reference to SAML ) or underspecified= ( be very explicit about exactly what is expected ) I'd advocate that the core spec is left under-specified. If we're prescri= ptive on the exact version and format of SAML, than the result will be othe= r use-cases will simply force non-standard extensions. It seems we do nee= d to document exactly what what specific values of assertion_format require= s, but the core spec should be open to multiple formats. This would allow for flexibility with SAML, which has multiple versions, fo= rmats, and confirmation methods, but also allow for this message exchange p= atterns with completely different assertion types. It will somewhat futur= e proof the core spec. Note that I'd be happy to work on the documentation of a specific format an= d contribute that to the group. -cmort On 4/1/10 12:24 PM, "Eran Hammer-Lahav" wrote: A generic assertion flow is too under-specified to be included. If a SAML2 = assertion flow isn't enough or useful, we should define what is and fully s= pecify it. The current text is still incomplete as it doesn't address how t= he assertion should be encoded in the request. EHL On 4/1/10 11:21 AM, "Marius Scurtescu" wrote: Instead of "SAML Assertion Flow" maybe we should stick with the more generic "Assertion Flow". The assertion_format parameter allows you to define the assertion type. Maybe we can predefine some well know formats, for example: "saml1", "saml1.1" and "saml2"? Marius On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav wr= ote: > I'm making good progress working off David's draft and bringing text from > WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So = far > it is largely in line with David's proposal and the majority of changes a= re > purely editorial. > > The only significant change I have made (which is of course open to debat= e) > is renaming all the authorization flows parameters. I dropped the oauth_ > prefix (no real need since these are purely OAuth endpoints, not protecte= d > resources), and made most of the parameter names shorter. I am not done s= o > they are not consistent yet. > > You can follow my progress (changes every few hours) at: > > http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oa= uth > .txt > > Please feel free to comment on anything you like or dislike. I will publi= sh > the whole thing as an I-D once it is feature complete for the WG to discu= ss > before we promote this to a WG draft. > > I hope to be done with the initial draft by middle of next week (I'll be > flying most of Fri-Sat so no progress over the weekend). > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --_000_C7DA51562FBFcmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-size:11pt'>As you’ve= pointed out, the current text is in somewhat of a grey area.   I= t’s either over specified ( remove any reference to SAML ) or undersp= ecified ( be very explicit about exactly what is expected ) <BR> <BR> I’d advocate that the core spec is left under-specified.   = If we’re prescriptive on the exact version and format of SAML, than t= he result will be other use-cases will simply force non-standard extensions= .   It seems we do need to document exactly what what specific va= lues of assertion_format requires, but the core spec should be open to mult= iple formats.   <BR> <BR> This would allow for flexibility with SAML, which has multiple versions, fo= rmats, and confirmation methods, but also allow for this message exchange p= atterns with completely different assertion types.   It will some= what future proof the core spec.<BR> <BR> Note that I’d be happy to work on the documentation of a specific for= mat and contribute that to the group.   <BR> <BR> -cmort <BR> <BR> <BR> On 4/1/10 12:24 PM, "Eran Hammer-Lahav" <<a href=3D"eran@hueni= verse.com">eran@hueniverse.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Verd= ana, Helvetica, Arial">A generic assertion flow is too under-specified to b= e included. If a SAML2 assertion flow isn’t enough or useful, we shou= ld define what is and fully specify it. The current text is still incomplet= e as it doesn’t address how the assertion should be encoded in the re= quest.<BR> <BR> EHL<BR> <BR> <BR> On 4/1/10 11:21 AM, "Marius Scurtescu" <<a href=3D"mscurtescu@= google.com">mscurtescu@google.com</a>> wrote:<BR> <BR> </FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Verd= ana, Helvetica, Arial">Instead of "SAML Assertion Flow" maybe we = should stick with the more<BR> generic "Assertion Flow".<BR> <BR> The assertion_format parameter allows you to define the assertion<BR> type. Maybe we can predefine<BR> some well know formats, for example: "saml1", "saml1.1"= and "saml2"?<BR> <BR> Marius<BR> <BR> <BR> <BR> On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <<a href=3D"eran@huen= iverse.com">eran@hueniverse.com</a>> wrote:<BR> > I'm making good progress working off David's draft and bringing text f= rom<BR> > WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. = So far<BR> > it is largely in line with David's proposal and the majority of change= s are<BR> > purely editorial.<BR> ><BR> > The only significant change I have made (which is of course open to de= bate)<BR> > is renaming all the authorization flows parameters. I dropped the oaut= h_<BR> > prefix (no real need since these are purely OAuth endpoints, not prote= cted<BR> > resources), and made most of the parameter names shorter. I am not don= e so<BR> > they are not consistent yet.<BR> ><BR> > You can follow my progress (changes every few hours) at:<BR> ><BR> > <a href=3D"http://github.com/theRazorBlade/draft-ietf-oauth/raw/master= /draft-ietf-oauth">http://github.com/theRazorBlade/draft-ietf-oauth/raw/mas= ter/draft-ietf-oauth</a><BR> > .txt<BR> ><BR> > Please feel free to comment on anything you like or dislike. I will pu= blish<BR> > the whole thing as an I-D once it is feature complete for the WG to di= scuss<BR> > before we promote this to a WG draft.<BR> ><BR> > I hope to be done with the initial draft by middle of next week (I'll = be<BR> > flying most of Fri-Sat so no progress over the weekend).<BR> ><BR> > EHL<BR> ><BR> > _______________________________________________<BR> > OAuth mailing list<BR> > <a href=3D"OAuth@ietf.org">OAuth@ietf.org</a><BR> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ie= tf.org/mailman/listinfo/oauth</a><BR> ><BR> <BR> </FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Luc= ida Grande"><BR> </FONT></SPAN></BLOCKQUOTE> </BODY> </HTML> --_000_C7DA51562FBFcmortimoresalesforcecom_-- From eran@hueniverse.com Thu Apr 1 15:16:15 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E253A68AA for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 15:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.985 X-Spam-Level: X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXn3YtENa+7S for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 15:16:13 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8BDD03A6825 for <oauth@ietf.org>; Thu, 1 Apr 2010 15:16:13 -0700 (PDT) Received: (qmail 19950 invoked from network); 1 Apr 2010 22:16:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Apr 2010 22:16:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Apr 2010 15:16:45 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Chuck Mortimore <cmortimore@salesforce.com> Date: Thu, 1 Apr 2010 15:16:28 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrR6QNxYjMaO5tiTVWOlWjNct/17Q== Message-ID: <B6D3A5E0-36B2-4458-9CE6-F5F394E69B87@hueniverse.com> References: <C7DA5156.2FBF%cmortimore@salesforce.com> In-Reply-To: <C7DA5156.2FBF%cmortimore@salesforce.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B6D3A5E036B244589CE6F5F394E69B87hueniversecom_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Apr 2010 22:16:15 -0000 --_000_B6D3A5E036B244589CE6F5F394E69B87hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBpcyB0aGUgdmFsdWUgb2YgYW4gdW5kZXIgc3BlY2lmaWVkIGZsb3c/IEVzcGVjaWFsbHkg b25lIGFzIHNob3J0IGFuZCBzaW1wbGUgYXMgdGhpcyBvbmU/DQoNCk15IHBvaW50IGlzIHRoYXQg aWYgdGhlIGZsb3cgcmVxdWlyZXMgZnVydGhlciBwcm9maWxpbmcgdG8gYmUgdXNlZnVsLCB0aGUg d2hvbGUgdGhpbmcgZG9lcyBiZWxvbmcgaW4gdGhlIGNvcmUgc3BlYy4gSXQgaXMgc2hvcnQgZW5v dWdoIHRvIGJlIGN1dCBhbmQgcGFzdGUgaW50byBhbm90aGVyIHNwZWMgcmVwZWF0ZWRseSBmb3Ig ZWFjaCB3ZWxsIHNwZWNpZmllZCBhc3NlcnRpb24gZmxvdy4NCg0KRUhMDQoNCk9uIEFwciAxLCAy MDEwLCBhdCAxNjozNCwgIkNodWNrIE1vcnRpbW9yZSIgPGNtb3J0aW1vcmVAc2FsZXNmb3JjZS5j b208bWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20+PiB3cm90ZToNCg0KQXMgeW914oCZ dmUgcG9pbnRlZCBvdXQsIHRoZSBjdXJyZW50IHRleHQgaXMgaW4gc29tZXdoYXQgb2YgYSBncmV5 IGFyZWEuICAgSXTigJlzIGVpdGhlciBvdmVyIHNwZWNpZmllZCAoIHJlbW92ZSBhbnkgcmVmZXJl bmNlIHRvIFNBTUwgKSBvciB1bmRlcnNwZWNpZmllZCAoIGJlIHZlcnkgZXhwbGljaXQgYWJvdXQg ZXhhY3RseSB3aGF0IGlzIGV4cGVjdGVkICkNCg0KSeKAmWQgYWR2b2NhdGUgdGhhdCB0aGUgY29y ZSBzcGVjIGlzIGxlZnQgdW5kZXItc3BlY2lmaWVkLiAgIElmIHdl4oCZcmUgcHJlc2NyaXB0aXZl IG9uIHRoZSBleGFjdCB2ZXJzaW9uIGFuZCBmb3JtYXQgb2YgU0FNTCwgdGhhbiB0aGUgcmVzdWx0 IHdpbGwgYmUgb3RoZXIgdXNlLWNhc2VzIHdpbGwgc2ltcGx5IGZvcmNlIG5vbi1zdGFuZGFyZCBl eHRlbnNpb25zLiAgIEl0IHNlZW1zIHdlIGRvIG5lZWQgdG8gZG9jdW1lbnQgZXhhY3RseSB3aGF0 IHdoYXQgc3BlY2lmaWMgdmFsdWVzIG9mIGFzc2VydGlvbl9mb3JtYXQgcmVxdWlyZXMsIGJ1dCB0 aGUgY29yZSBzcGVjIHNob3VsZCBiZSBvcGVuIHRvIG11bHRpcGxlIGZvcm1hdHMuDQoNClRoaXMg d291bGQgYWxsb3cgZm9yIGZsZXhpYmlsaXR5IHdpdGggU0FNTCwgd2hpY2ggaGFzIG11bHRpcGxl IHZlcnNpb25zLCBmb3JtYXRzLCBhbmQgY29uZmlybWF0aW9uIG1ldGhvZHMsIGJ1dCBhbHNvIGFs bG93IGZvciB0aGlzIG1lc3NhZ2UgZXhjaGFuZ2UgcGF0dGVybnMgd2l0aCBjb21wbGV0ZWx5IGRp ZmZlcmVudCBhc3NlcnRpb24gdHlwZXMuICAgSXQgd2lsbCBzb21ld2hhdCBmdXR1cmUgcHJvb2Yg dGhlIGNvcmUgc3BlYy4NCg0KTm90ZSB0aGF0IEnigJlkIGJlIGhhcHB5IHRvIHdvcmsgb24gdGhl IGRvY3VtZW50YXRpb24gb2YgYSBzcGVjaWZpYyBmb3JtYXQgYW5kIGNvbnRyaWJ1dGUgdGhhdCB0 byB0aGUgZ3JvdXAuDQoNCi1jbW9ydA0KDQoNCk9uIDQvMS8xMCAxMjoyNCBQTSwgIkVyYW4gSGFt bWVyLUxhaGF2IiA8PGVyYW5AaHVlbml2ZXJzZS5jb20+ZXJhbkBodWVuaXZlcnNlLmNvbTxtYWls dG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+IHdyb3RlOg0KDQpBIGdlbmVyaWMgYXNzZXJ0aW9uIGZs b3cgaXMgdG9vIHVuZGVyLXNwZWNpZmllZCB0byBiZSBpbmNsdWRlZC4gSWYgYSBTQU1MMiBhc3Nl cnRpb24gZmxvdyBpc27igJl0IGVub3VnaCBvciB1c2VmdWwsIHdlIHNob3VsZCBkZWZpbmUgd2hh dCBpcyBhbmQgZnVsbHkgc3BlY2lmeSBpdC4gVGhlIGN1cnJlbnQgdGV4dCBpcyBzdGlsbCBpbmNv bXBsZXRlIGFzIGl0IGRvZXNu4oCZdCBhZGRyZXNzIGhvdyB0aGUgYXNzZXJ0aW9uIHNob3VsZCBi ZSBlbmNvZGVkIGluIHRoZSByZXF1ZXN0Lg0KDQpFSEwNCg0KDQpPbiA0LzEvMTAgMTE6MjEgQU0s ICJNYXJpdXMgU2N1cnRlc2N1IiA8PG1zY3VydGVzY3VAZ29vZ2xlLmNvbT5tc2N1cnRlc2N1QGdv b2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpJbnN0ZWFk IG9mICJTQU1MIEFzc2VydGlvbiBGbG93IiBtYXliZSB3ZSBzaG91bGQgc3RpY2sgd2l0aCB0aGUg bW9yZQ0KZ2VuZXJpYyAiQXNzZXJ0aW9uIEZsb3ciLg0KDQpUaGUgYXNzZXJ0aW9uX2Zvcm1hdCBw YXJhbWV0ZXIgYWxsb3dzIHlvdSB0byBkZWZpbmUgdGhlIGFzc2VydGlvbg0KdHlwZS4gTWF5YmUg d2UgY2FuIHByZWRlZmluZQ0Kc29tZSB3ZWxsIGtub3cgZm9ybWF0cywgZm9yIGV4YW1wbGU6ICJz YW1sMSIsICJzYW1sMS4xIiBhbmQgInNhbWwyIj8NCg0KTWFyaXVzDQoNCg0KDQpPbiBXZWQsIE1h ciAzMSwgMjAxMCBhdCA2OjIyIFBNLCBFcmFuIEhhbW1lci1MYWhhdiA8PGVyYW5AaHVlbml2ZXJz ZS5jb20+ZXJhbkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+IHdy b3RlOg0KPiBJJ20gbWFraW5nIGdvb2QgcHJvZ3Jlc3Mgd29ya2luZyBvZmYgRGF2aWQncyBkcmFm dCBhbmQgYnJpbmdpbmcgdGV4dCBmcm9tDQo+IFdSQVAgaW50byBpdCwgYXMgd2VsbCBhcyBmcm9t IE9BdXRoIDEuMGEsIGFuZCBteSB0b2tlbiBhdXRoIHByb3Bvc2FsLiBTbyBmYXINCj4gaXQgaXMg bGFyZ2VseSBpbiBsaW5lIHdpdGggRGF2aWQncyBwcm9wb3NhbCBhbmQgdGhlIG1ham9yaXR5IG9m IGNoYW5nZXMgYXJlDQo+IHB1cmVseSBlZGl0b3JpYWwuDQo+DQo+IFRoZSBvbmx5IHNpZ25pZmlj YW50IGNoYW5nZSBJIGhhdmUgbWFkZSAod2hpY2ggaXMgb2YgY291cnNlIG9wZW4gdG8gZGViYXRl KQ0KPiBpcyByZW5hbWluZyBhbGwgdGhlIGF1dGhvcml6YXRpb24gZmxvd3MgcGFyYW1ldGVycy4g SSBkcm9wcGVkIHRoZSBvYXV0aF8NCj4gcHJlZml4IChubyByZWFsIG5lZWQgc2luY2UgdGhlc2Ug YXJlIHB1cmVseSBPQXV0aCBlbmRwb2ludHMsIG5vdCBwcm90ZWN0ZWQNCj4gcmVzb3VyY2VzKSwg YW5kIG1hZGUgbW9zdCBvZiB0aGUgcGFyYW1ldGVyIG5hbWVzIHNob3J0ZXIuIEkgYW0gbm90IGRv bmUgc28NCj4gdGhleSBhcmUgbm90IGNvbnNpc3RlbnQgeWV0Lg0KPg0KPiBZb3UgY2FuIGZvbGxv dyBteSBwcm9ncmVzcyAoY2hhbmdlcyBldmVyeSBmZXcgaG91cnMpIGF0Og0KPg0KPiA8aHR0cDov L2dpdGh1Yi5jb20vdGhlUmF6b3JCbGFkZS9kcmFmdC1pZXRmLW9hdXRoL3Jhdy9tYXN0ZXIvZHJh ZnQtaWV0Zi1vYXV0aD4gaHR0cDovL2dpdGh1Yi5jb20vdGhlUmF6b3JCbGFkZS9kcmFmdC1pZXRm LW9hdXRoL3Jhdy9tYXN0ZXIvZHJhZnQtaWV0Zi1vYXV0aA0KPiAudHh0DQo+DQo+IFBsZWFzZSBm ZWVsIGZyZWUgdG8gY29tbWVudCBvbiBhbnl0aGluZyB5b3UgbGlrZSBvciBkaXNsaWtlLiBJIHdp bGwgcHVibGlzaA0KPiB0aGUgd2hvbGUgdGhpbmcgYXMgYW4gSS1EIG9uY2UgaXQgaXMgZmVhdHVy ZSBjb21wbGV0ZSBmb3IgdGhlIFdHIHRvIGRpc2N1c3MNCj4gYmVmb3JlIHdlIHByb21vdGUgdGhp cyB0byBhIFdHIGRyYWZ0Lg0KPg0KPiBJIGhvcGUgdG8gYmUgZG9uZSB3aXRoIHRoZSBpbml0aWFs IGRyYWZ0IGJ5IG1pZGRsZSBvZiBuZXh0IHdlZWsgKEknbGwgYmUNCj4gZmx5aW5nIG1vc3Qgb2Yg RnJpLVNhdCBzbyBubyBwcm9ncmVzcyBvdmVyIHRoZSB3ZWVrZW5kKS4NCj4NCj4gRUhMDQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRo IG1haWxpbmcgbGlzdA0KPiA8T0F1dGhAaWV0Zi5vcmc+IE9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCj4gPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCg0K DQo= --_000_B6D3A5E036B244589CE6F5F394E69B87hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5XaGF0IGlzIHRoZSB2YWx1ZSBvZiBh biB1bmRlciBzcGVjaWZpZWQgZmxvdz8gRXNwZWNpYWxseSBvbmUgYXMgc2hvcnQgYW5kIHNpbXBs ZSBhcyB0aGlzIG9uZT88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pk15IHBvaW50IGlzIHRoYXQg aWYgdGhlIGZsb3cgcmVxdWlyZXMgZnVydGhlciBwcm9maWxpbmcgdG8gYmUgdXNlZnVsLCB0aGUg d2hvbGUgdGhpbmcgZG9lcyBiZWxvbmcgaW4gdGhlIGNvcmUgc3BlYy4gSXQgaXMgc2hvcnQgZW5v dWdoIHRvIGJlIGN1dCBhbmQgcGFzdGUgaW50byBhbm90aGVyIHNwZWMgcmVwZWF0ZWRseSBmb3Ig ZWFjaCB3ZWxsIHNwZWNpZmllZCBhc3NlcnRpb24gZmxvdy4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PkVITCZuYnNwOzxicj48YnI+T24gQXByIDEsIDIwMTAsIGF0IDE2OjM0LCAiQ2h1 Y2sgTW9ydGltb3JlIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5j b20iPmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2 PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCjxmb250IGZhY2U9Ikx1 Y2lkYSBHcmFuZGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+QXMgeW914oCZdmUgcG9p bnRlZCBvdXQsIHRoZSBjdXJyZW50IHRleHQgaXMgaW4gc29tZXdoYXQgb2YgYSBncmV5IGFyZWEu ICZuYnNwOyZuYnNwO0l04oCZcyBlaXRoZXIgb3ZlciBzcGVjaWZpZWQgKCByZW1vdmUgYW55IHJl ZmVyZW5jZSB0byBTQU1MICkgb3IgdW5kZXJzcGVjaWZpZWQgKCBiZSB2ZXJ5IGV4cGxpY2l0IGFi b3V0IGV4YWN0bHkgd2hhdCBpcyBleHBlY3RlZCApIDxicj4NCjxicj4NCknigJlkIGFkdm9jYXRl IHRoYXQgdGhlIGNvcmUgc3BlYyBpcyBsZWZ0IHVuZGVyLXNwZWNpZmllZC4gJm5ic3A7Jm5ic3A7 SWYgd2XigJlyZSBwcmVzY3JpcHRpdmUgb24gdGhlIGV4YWN0IHZlcnNpb24gYW5kIGZvcm1hdCBv ZiBTQU1MLCB0aGFuIHRoZSByZXN1bHQgd2lsbCBiZSBvdGhlciB1c2UtY2FzZXMgd2lsbCBzaW1w bHkgZm9yY2Ugbm9uLXN0YW5kYXJkIGV4dGVuc2lvbnMuICZuYnNwOyZuYnNwO0l0IHNlZW1zIHdl IGRvIG5lZWQgdG8gZG9jdW1lbnQgZXhhY3RseSB3aGF0IHdoYXQgc3BlY2lmaWMgdmFsdWVzIG9m IGFzc2VydGlvbl9mb3JtYXQgcmVxdWlyZXMsIGJ1dCB0aGUgY29yZSBzcGVjIHNob3VsZCBiZSBv cGVuIHRvIG11bHRpcGxlIGZvcm1hdHMuICZuYnNwOyZuYnNwOzxicj4NCjxicj4NClRoaXMgd291 bGQgYWxsb3cgZm9yIGZsZXhpYmlsaXR5IHdpdGggU0FNTCwgd2hpY2ggaGFzIG11bHRpcGxlIHZl cnNpb25zLCBmb3JtYXRzLCBhbmQgY29uZmlybWF0aW9uIG1ldGhvZHMsIGJ1dCBhbHNvIGFsbG93 IGZvciB0aGlzIG1lc3NhZ2UgZXhjaGFuZ2UgcGF0dGVybnMgd2l0aCBjb21wbGV0ZWx5IGRpZmZl cmVudCBhc3NlcnRpb24gdHlwZXMuICZuYnNwOyZuYnNwO0l0IHdpbGwgc29tZXdoYXQgZnV0dXJl IHByb29mIHRoZSBjb3JlIHNwZWMuPGJyPg0KPGJyPg0KTm90ZSB0aGF0IEnigJlkIGJlIGhhcHB5 IHRvIHdvcmsgb24gdGhlIGRvY3VtZW50YXRpb24gb2YgYSBzcGVjaWZpYyBmb3JtYXQgYW5kIGNv bnRyaWJ1dGUgdGhhdCB0byB0aGUgZ3JvdXAuICZuYnNwOyZuYnNwOzxicj4NCjxicj4NCi1jbW9y dCA8YnI+DQo8YnI+DQo8YnI+DQpPbiA0LzEvMTAgMTI6MjQgUE0sICJFcmFuIEhhbW1lci1MYWhh diIgJmx0OzxhIGhyZWY9ImVyYW5AaHVlbml2ZXJzZS5jb20iPjxhIGhyZWY9Im1haWx0bzplcmFu QGh1ZW5pdmVyc2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPjwvYT4mZ3Q7IHdyb3RlOjxi cj4NCjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGJsb2NrcXVvdGU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMXB0Ij48Zm9udCBmYWNlPSJWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj5BIGdlbmVyaWMg YXNzZXJ0aW9uIGZsb3cgaXMgdG9vIHVuZGVyLXNwZWNpZmllZCB0byBiZSBpbmNsdWRlZC4gSWYg YSBTQU1MMiBhc3NlcnRpb24gZmxvdyBpc27igJl0IGVub3VnaCBvciB1c2VmdWwsIHdlIHNob3Vs ZCBkZWZpbmUgd2hhdCBpcyBhbmQgZnVsbHkgc3BlY2lmeSBpdC4gVGhlIGN1cnJlbnQgdGV4dCBp cyBzdGlsbCBpbmNvbXBsZXRlIGFzIGl0IGRvZXNu4oCZdCBhZGRyZXNzIGhvdyB0aGUgYXNzZXJ0 aW9uIHNob3VsZCBiZSBlbmNvZGVkIGluIHRoZSByZXF1ZXN0Ljxicj4NCjxicj4NCkVITDxicj4N Cjxicj4NCjxicj4NCk9uIDQvMS8xMCAxMToyMSBBTSwgIk1hcml1cyBTY3VydGVzY3UiICZsdDs8 YSBocmVmPSJtc2N1cnRlc2N1QGdvb2dsZS5jb20iPjxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1 QGdvb2dsZS5jb20iPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT48L2E+Jmd0OyB3cm90ZTo8YnI+ DQo8YnI+DQo8L2ZvbnQ+PC9zcGFuPjxibG9ja3F1b3RlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTFwdCI+PGZvbnQgZmFjZT0iVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+SW5zdGVhZCBvZiAi U0FNTCBBc3NlcnRpb24gRmxvdyIgbWF5YmUgd2Ugc2hvdWxkIHN0aWNrIHdpdGggdGhlIG1vcmU8 YnI+DQpnZW5lcmljICJBc3NlcnRpb24gRmxvdyIuPGJyPg0KPGJyPg0KVGhlIGFzc2VydGlvbl9m b3JtYXQgcGFyYW1ldGVyIGFsbG93cyB5b3UgdG8gZGVmaW5lIHRoZSBhc3NlcnRpb248YnI+DQp0 eXBlLiBNYXliZSB3ZSBjYW4gcHJlZGVmaW5lPGJyPg0Kc29tZSB3ZWxsIGtub3cgZm9ybWF0cywg Zm9yIGV4YW1wbGU6ICJzYW1sMSIsICJzYW1sMS4xIiBhbmQgInNhbWwyIj88YnI+DQo8YnI+DQpN YXJpdXM8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiBXZWQsIE1hciAzMSwgMjAxMCBhdCA2OjIy IFBNLCBFcmFuIEhhbW1lci1MYWhhdiAmbHQ7PGEgaHJlZj0iZXJhbkBodWVuaXZlcnNlLmNvbSI+ PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208 L2E+PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBJJ20gbWFraW5nIGdvb2QgcHJvZ3Jlc3Mgd29y a2luZyBvZmYgRGF2aWQncyBkcmFmdCBhbmQgYnJpbmdpbmcgdGV4dCBmcm9tPGJyPg0KJmd0OyBX UkFQIGludG8gaXQsIGFzIHdlbGwgYXMgZnJvbSBPQXV0aCAxLjBhLCBhbmQgbXkgdG9rZW4gYXV0 aCBwcm9wb3NhbC4gU28gZmFyPGJyPg0KJmd0OyBpdCBpcyBsYXJnZWx5IGluIGxpbmUgd2l0aCBE YXZpZCdzIHByb3Bvc2FsIGFuZCB0aGUgbWFqb3JpdHkgb2YgY2hhbmdlcyBhcmU8YnI+DQomZ3Q7 IHB1cmVseSBlZGl0b3JpYWwuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIG9ubHkgc2lnbmlmaWNh bnQgY2hhbmdlIEkgaGF2ZSBtYWRlICh3aGljaCBpcyBvZiBjb3Vyc2Ugb3BlbiB0byBkZWJhdGUp PGJyPg0KJmd0OyBpcyByZW5hbWluZyBhbGwgdGhlIGF1dGhvcml6YXRpb24gZmxvd3MgcGFyYW1l dGVycy4gSSBkcm9wcGVkIHRoZSBvYXV0aF88YnI+DQomZ3Q7IHByZWZpeCAobm8gcmVhbCBuZWVk IHNpbmNlIHRoZXNlIGFyZSBwdXJlbHkgT0F1dGggZW5kcG9pbnRzLCBub3QgcHJvdGVjdGVkPGJy Pg0KJmd0OyByZXNvdXJjZXMpLCBhbmQgbWFkZSBtb3N0IG9mIHRoZSBwYXJhbWV0ZXIgbmFtZXMg c2hvcnRlci4gSSBhbSBub3QgZG9uZSBzbzxicj4NCiZndDsgdGhleSBhcmUgbm90IGNvbnNpc3Rl bnQgeWV0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFlvdSBjYW4gZm9sbG93IG15IHByb2dyZXNzIChj aGFuZ2VzIGV2ZXJ5IGZldyBob3VycykgYXQ6PGJyPg0KJmd0Ozxicj4NCiZndDsgPGEgaHJlZj0i aHR0cDovL2dpdGh1Yi5jb20vdGhlUmF6b3JCbGFkZS9kcmFmdC1pZXRmLW9hdXRoL3Jhdy9tYXN0 ZXIvZHJhZnQtaWV0Zi1vYXV0aCI+PGEgaHJlZj0iaHR0cDovL2dpdGh1Yi5jb20vdGhlUmF6b3JC bGFkZS9kcmFmdC1pZXRmLW9hdXRoL3Jhdy9tYXN0ZXIvZHJhZnQtaWV0Zi1vYXV0aCI+aHR0cDov L2dpdGh1Yi5jb20vdGhlUmF6b3JCbGFkZS9kcmFmdC1pZXRmLW9hdXRoL3Jhdy9tYXN0ZXIvZHJh ZnQtaWV0Zi1vYXV0aDwvYT48L2E+PGJyPg0KJmd0OyAudHh0PGJyPg0KJmd0Ozxicj4NCiZndDsg UGxlYXNlIGZlZWwgZnJlZSB0byBjb21tZW50IG9uIGFueXRoaW5nIHlvdSBsaWtlIG9yIGRpc2xp a2UuIEkgd2lsbCBwdWJsaXNoPGJyPg0KJmd0OyB0aGUgd2hvbGUgdGhpbmcgYXMgYW4gSS1EIG9u Y2UgaXQgaXMgZmVhdHVyZSBjb21wbGV0ZSBmb3IgdGhlIFdHIHRvIGRpc2N1c3M8YnI+DQomZ3Q7 IGJlZm9yZSB3ZSBwcm9tb3RlIHRoaXMgdG8gYSBXRyBkcmFmdC48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJIGhvcGUgdG8gYmUgZG9uZSB3aXRoIHRoZSBpbml0aWFsIGRyYWZ0IGJ5IG1pZGRsZSBvZiBu ZXh0IHdlZWsgKEknbGwgYmU8YnI+DQomZ3Q7IGZseWluZyBtb3N0IG9mIEZyaS1TYXQgc28gbm8g cHJvZ3Jlc3Mgb3ZlciB0aGUgd2Vla2VuZCkuPGJyPg0KJmd0Ozxicj4NCiZndDsgRUhMPGJyPg0K Jmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0iT0F1 dGhAaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5v cmc8L2E+PC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCjwvZm9udD48L3NwYW4+PC9ibG9ja3F1b3Rl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGZvbnQgZmFjZT0iTHVjaWRhIEdyYW5kZSI+ PGJyPg0KPC9mb250Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+DQoNCg0KDQo8L2Rpdj48L2Jsb2NrcXVv dGU+PC9ib2R5PjwvaHRtbD4= --_000_B6D3A5E036B244589CE6F5F394E69B87hueniversecom_-- From justinsm@microsoft.com Thu Apr 1 15:26:11 2010 Return-Path: <justinsm@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491ED3A6800 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 15:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGBjwLGjQxbH for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 15:26:10 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id E3F483A6A58 for <oauth@ietf.org>; Thu, 1 Apr 2010 15:24:23 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 1 Apr 2010 15:24:56 -0700 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.239]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Thu, 1 Apr 2010 15:24:56 -0700 From: Justin Smith <justinsm@microsoft.com> To: Marius Scurtescu <mscurtescu@google.com>, Eran Hammer-Lahav <eran@hueniverse.com> Thread-Topic: [OAUTH-WG] Draft progress update Thread-Index: AQHK0dkN7zMKq4k9ckyGMENW6XyqGJIOFcXQ Date: Thu, 1 Apr 2010 22:22:35 +0000 Deferred-Delivery: Thu, 1 Apr 2010 22:23:00 +0000 Message-ID: <191F411E00E19F4E943ECDB6D65C60851690A880@TK5EX14MBXC115.redmond.corp.microsoft.com> References: <191F411E00E19F4E943ECDB6D65C6085168FCFE8@TK5EX14MBXC115.redmond.corp.microsoft.com> <C7DA40B8.31B0F%eran@hueniverse.com> <o2x74caaad21004011321w7414318ai6f52ea84dea0862e@mail.gmail.com> In-Reply-To: <o2x74caaad21004011321w7414318ai6f52ea84dea0862e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Apr 2010 22:26:11 -0000 > I don't see why an opaque scope parameter would create any problems > for a library implementation. Working on such an implementation right > now and opaque scopes are perfectly fine. I completely agree. In practice this hasn't caused a problem. We discussed = the idea of forcing an absolute URI here and whether it had to be the actua= l resource URI. That doesn't work when the AS uses the same access policy f= or multiple resources. Opaque seems like a fine proposal to me. >> Comment 3: This isn't the case when the client is presenting a token iss= ued by >> another server. I suggest a change to something like the following: "Whe= n >> requesting access from the authorization server, the client identifies i= tself >> using client credentials known to the authorization server." > > What token? The authorization endpoint isn't an OAuth-protected resource. In the case where you present a SAML (or other format) assertion, it is a k= ind of a protected resource - the resource is an access token. >> This isn't the old testament. No need to look for hidden meaning. The sp= ec >> is about getting access to protected resources, generally dealing with *= a* >> protected resource. How resources are segmented is beyond the scope. I t= hink >> it is more useful to talk about it using simpler assumptions - it doesn'= t >> prevent the more complex use cases. > I think this ties in with the scope parameter. When requesting authorizat= ion, > if a client can also pass a scope parameter, then access is granted only > to the resources that accept that scope and not to all resources controll= ed > by this Authorization Server. This is only a minor wording comment, but I think the idea is significant. = The assumption that there is a 1:1 mapping between an AS and a PR seems out= of place for the spec. It's easy to imagine that a single AS controls acce= ss to many resources (photos, friends, address books, etc.) - this is in fa= ct what happens today.=20 --justin From cmortimore@salesforce.com Thu Apr 1 15:37:51 2010 Return-Path: <cmortimore@salesforce.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE6A3A681B for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 15:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.888 X-Spam-Level: X-Spam-Status: No, score=-4.888 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKeaP0qOSXtw for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 15:37:44 -0700 (PDT) Received: from exprod8og113.obsmtp.com (exprod8og113.obsmtp.com [64.18.3.26]) by core3.amsl.com (Postfix) with SMTP id 62D7B3A689D for <oauth@ietf.org>; Thu, 1 Apr 2010 15:37:44 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob113.postini.com ([64.18.7.12]) with SMTP ID DSNKS7UgWAGrbS771co8280ywbtK+98zQcxI@postini.com; Thu, 01 Apr 2010 15:38:17 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Thu, 1 Apr 2010 15:38:16 -0700 From: Chuck Mortimore <cmortimore@salesforce.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Date: Thu, 1 Apr 2010 15:38:14 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrR6QNxYjMaO5tiTVWOlWjNct/17QAAwBhU Message-ID: <C7DA6E66.3002%cmortimore@salesforce.com> In-Reply-To: <B6D3A5E0-36B2-4458-9CE6-F5F394E69B87@hueniverse.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7DA6E663002cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Apr 2010 22:37:51 -0000 --_000_C7DA6E663002cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Flexibility. If we lock Oauth2 down to one specific specific Assertion, i= t becomes unusable for other assertion formats. Those assertion formats w= ill evolve anyways. Looked at somewhat differently, if there is only 1 a= ssertion format supported by the spec, then what is the point of the assert= ion_format attribute? So I'm clear, I'm 100% in favor of having a canonical assertion format for = SAML with OAuth2, I really only intend to initially support 1 format, and I= 'm happy to take a stab at defining it. I do think it's worthwhile for the spec to be open to other formats/asserti= ons to be profiled over this same message exchange pattern. One approach might be to change "2.6.2. SAML Assertion Flow" into "2.7. = Assertion Flow" and then have a base "Assertion Flow" followed by a "SAML= Assertion flow" that builds on the base by defining explicit values for a= ssertion_format and assertion. Essentially have a core protocol + 1 singl= e SAML profile of that protocol in the spec. -cmort On 4/1/10 3:16 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote: What is the value of an under specified flow? Especially one as short and s= imple as this one? My point is that if the flow requires further profiling to be useful, the w= hole thing does belong in the core spec. It is short enough to be cut and p= aste into another spec repeatedly for each well specified assertion flow. EHL On Apr 1, 2010, at 16:34, "Chuck Mortimore" <cmortimore@salesforce.com> wro= te: As you've pointed out, the current text is in somewhat of a grey area. It= 's either over specified ( remove any reference to SAML ) or underspecified= ( be very explicit about exactly what is expected ) I'd advocate that the core spec is left under-specified. If we're prescri= ptive on the exact version and format of SAML, than the result will be othe= r use-cases will simply force non-standard extensions. It seems we do nee= d to document exactly what what specific values of assertion_format require= s, but the core spec should be open to multiple formats. This would allow for flexibility with SAML, which has multiple versions, fo= rmats, and confirmation methods, but also allow for this message exchange p= atterns with completely different assertion types. It will somewhat futur= e proof the core spec. Note that I'd be happy to work on the documentation of a specific format an= d contribute that to the group. -cmort On 4/1/10 12:24 PM, "Eran Hammer-Lahav" <eran@hueniverse.com <mailto:eran@h= ueniverse.com> > wrote: A generic assertion flow is too under-specified to be included. If a SAML2 = assertion flow isn't enough or useful, we should define what is and fully s= pecify it. The current text is still incomplete as it doesn't address how t= he assertion should be encoded in the request. EHL On 4/1/10 11:21 AM, "Marius Scurtescu" <mscurtescu@google.com <mailto:mscur= tescu@google.com> > wrote: Instead of "SAML Assertion Flow" maybe we should stick with the more generic "Assertion Flow". The assertion_format parameter allows you to define the assertion type. Maybe we can predefine some well know formats, for example: "saml1", "saml1.1" and "saml2"? Marius On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <eran@hueniverse.com <ma= ilto:eran@hueniverse.com> > wrote: > I'm making good progress working off David's draft and bringing text from > WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So = far > it is largely in line with David's proposal and the majority of changes a= re > purely editorial. > > The only significant change I have made (which is of course open to debat= e) > is renaming all the authorization flows parameters. I dropped the oauth_ > prefix (no real need since these are purely OAuth endpoints, not protecte= d > resources), and made most of the parameter names shorter. I am not done s= o > they are not consistent yet. > > You can follow my progress (changes every few hours) at: > > http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oa= uth <http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf= -oauth> > .txt > > Please feel free to comment on anything you like or dislike. I will publi= sh > the whole thing as an I-D once it is feature complete for the WG to discu= ss > before we promote this to a WG draft. > > I hope to be done with the initial draft by middle of next week (I'll be > flying most of Fri-Sat so no progress over the weekend). > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman= /listinfo/oauth> > --_000_C7DA6E663002cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-size:11pt'>Flexibility. &n= bsp; If we lock Oauth2 down to one specific specific Assertion, it bec= omes unusable for other assertion formats.   Those assertion form= ats will evolve anyways.    Looked at somewhat differently, = if there is only 1 assertion format supported by the spec, then what is the= point of the assertion_format attribute?<BR> <BR> So I’m clear, I’m 100% in favor of having a canonical assertion= format for SAML with OAuth2, I really only intend to initially support 1 f= ormat, and I’m happy to take a stab at defining it.   <BR> <BR> I do think it’s worthwhile for the spec to be open to other formats/a= ssertions to be profiled over this same message exchange pattern.<BR> <BR> One approach might be to change “2.6.2.  SAML Assertion FlowR= 21;  into  “2.7.  Assertion Flow” and then have = a base “Assertion Flow” followed by a  “SAML Asserti= on flow”  that builds on the base by defining explicit values fo= r assertion_format and assertion.   Essentially have a core proto= col + 1 single SAML profile of that protocol in the spec. <BR> <BR> -cmort<BR> <BR> On 4/1/10 3:16 PM, "Eran Hammer-Lahav" <<a href=3D"eran@hueniv= erse.com">eran@hueniverse.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-= size:11pt'>What is the value of an under specified flow? Especially one as = short and simple as this one?<BR> <BR> My point is that if the flow requires further profiling to be useful, the w= hole thing does belong in the core spec. It is short enough to be cut and p= aste into another spec repeatedly for each well specified assertion flow. <= BR> <BR> EHL <BR> <BR> On Apr 1, 2010, at 16:34, "Chuck Mortimore" <<a href=3D"cmorti= more@salesforce.com">cmortimore@salesforce.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-= size:11pt'>As you’ve pointed out, the current text is in somewhat of = a grey area.   It’s either over specified ( remove any refe= rence to SAML ) or underspecified ( be very explicit about exactly what is = expected ) <BR> <BR> I’d advocate that the core spec is left under-specified.   = If we’re prescriptive on the exact version and format of SAML, than t= he result will be other use-cases will simply force non-standard extensions= .   It seems we do need to document exactly what what specific va= lues of assertion_format requires, but the core spec should be open to mult= iple formats.   <BR> <BR> This would allow for flexibility with SAML, which has multiple versions, fo= rmats, and confirmation methods, but also allow for this message exchange p= atterns with completely different assertion types.   It will some= what future proof the core spec.<BR> <BR> Note that I’d be happy to work on the documentation of a specific for= mat and contribute that to the group.   <BR> <BR> -cmort <BR> <BR> <BR> On 4/1/10 12:24 PM, "Eran Hammer-Lahav" <<a href=3D"eran@hueni= verse.com">eran@hueniverse.com</a> <<a href=3D"mailto:eran@hueniverse.co= m">mailto:eran@hueniverse.com</a>> > wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Verd= ana, Helvetica, Arial">A generic assertion flow is too under-specified to b= e included. If a SAML2 assertion flow isn’t enough or useful, we shou= ld define what is and fully specify it. The current text is still incomplet= e as it doesn’t address how the assertion should be encoded in the re= quest.<BR> <BR> EHL<BR> <BR> <BR> On 4/1/10 11:21 AM, "Marius Scurtescu" <<a href=3D"mscurtescu@= google.com">mscurtescu@google.com</a> <<a href=3D"mailto:mscurtescu@goog= le.com">mailto:mscurtescu@google.com</a>> > wrote:<BR> <BR> </FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Verd= ana, Helvetica, Arial">Instead of "SAML Assertion Flow" maybe we = should stick with the more<BR> generic "Assertion Flow".<BR> <BR> The assertion_format parameter allows you to define the assertion<BR> type. Maybe we can predefine<BR> some well know formats, for example: "saml1", "saml1.1"= and "saml2"?<BR> <BR> Marius<BR> <BR> <BR> <BR> On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <<a href=3D"eran@huen= iverse.com">eran@hueniverse.com</a> <<a href=3D"mailto:eran@hueniverse.c= om">mailto:eran@hueniverse.com</a>> > wrote:<BR> > I'm making good progress working off David's draft and bringing text f= rom<BR> > WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. = So far<BR> > it is largely in line with David's proposal and the majority of change= s are<BR> > purely editorial.<BR> ><BR> > The only significant change I have made (which is of course open to de= bate)<BR> > is renaming all the authorization flows parameters. I dropped the oaut= h_<BR> > prefix (no real need since these are purely OAuth endpoints, not prote= cted<BR> > resources), and made most of the parameter names shorter. I am not don= e so<BR> > they are not consistent yet.<BR> ><BR> > You can follow my progress (changes every few hours) at:<BR> ><BR> > <a href=3D"http://github.com/theRazorBlade/draft-ietf-oauth/raw/master= /draft-ietf-oauth">http://github.com/theRazorBlade/draft-ietf-oauth/raw/mas= ter/draft-ietf-oauth</a> <<a href=3D"http://github.com/theRazorBlade/dra= ft-ietf-oauth/raw/master/draft-ietf-oauth">http://github.com/theRazorBlade/= draft-ietf-oauth/raw/master/draft-ietf-oauth</a>> <BR> > .txt<BR> ><BR> > Please feel free to comment on anything you like or dislike. I will pu= blish<BR> > the whole thing as an I-D once it is feature complete for the WG to di= scuss<BR> > before we promote this to a WG draft.<BR> ><BR> > I hope to be done with the initial draft by middle of next week (I'll = be<BR> > flying most of Fri-Sat so no progress over the weekend).<BR> ><BR> > EHL<BR> ><BR> > _______________________________________________<BR> > OAuth mailing list<BR> > <a href=3D"OAuth@ietf.org">OAuth@ietf.org</a> <<a href=3D"mailto:OA= uth@ietf.org">mailto:OAuth@ietf.org</a>> <BR> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ie= tf.org/mailman/listinfo/oauth</a> <<a href=3D"https://www.ietf.org/mailm= an/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a>> <BR> ><BR> <BR> </FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Luc= ida Grande"><BR> </FONT></SPAN></BLOCKQUOTE></BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FON= T FACE=3D"Lucida Grande"><BR> </FONT></SPAN></BLOCKQUOTE> </BODY> </HTML> --_000_C7DA6E663002cmortimoresalesforcecom_-- From beaton@google.com Thu Apr 1 16:52:44 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC873A686B for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 16:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.22 X-Spam-Level: X-Spam-Status: No, score=-100.22 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGXuBqByj2JX for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 16:52:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 707EB3A67FD for <oauth@ietf.org>; Thu, 1 Apr 2010 16:52:42 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id o31NrDd2008650 for <oauth@ietf.org>; Fri, 2 Apr 2010 01:53:13 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270165994; bh=jFI9rYpfo+h2tBODluaRsdA6tvg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=i28MH3m5oM9vm9XbMjbpmmmI+JchW/R5cXQf/es8TP/g37tzArSBlSW3Pew1mwAIv 3lYXt91eaDx4O49UIKWwQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=LAeSfW5BgTMYFwVeBxG+IGGY084z2Bl2bqdz+p/GXSwgULy8TMhxDt+IQMbssgqeE TxbwucZCdRkqD9+Fvf9Bg== Received: from vws14 (vws14.prod.google.com [10.241.21.142]) by kpbe15.cbf.corp.google.com with ESMTP id o31NrB0W000514 for <oauth@ietf.org>; Thu, 1 Apr 2010 16:53:12 -0700 Received: by vws14 with SMTP id 14so840996vws.21 for <oauth@ietf.org>; Thu, 01 Apr 2010 16:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.2 with HTTP; Thu, 1 Apr 2010 16:53:11 -0700 (PDT) In-Reply-To: <C7DA6E66.3002%cmortimore@salesforce.com> References: <B6D3A5E0-36B2-4458-9CE6-F5F394E69B87@hueniverse.com> <C7DA6E66.3002%cmortimore@salesforce.com> Date: Thu, 1 Apr 2010 16:53:11 -0700 Received: by 10.220.121.136 with SMTP id h8mr808953vcr.193.1270165991633; Thu, 01 Apr 2010 16:53:11 -0700 (PDT) Message-ID: <g2xdaf5b9571004011653g86643e29u5176a552ee8eb70c@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: Chuck Mortimore <cmortimore@salesforce.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Apr 2010 23:52:44 -0000 On Thu, Apr 1, 2010 at 3:38 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote: > Flexibility. =A0=A0If we lock Oauth2 down to one specific specific Assert= ion, it > becomes unusable for other assertion formats. =A0=A0Those assertion forma= ts will > evolve anyways. Yep. The SAML Web SSO profiles are living proof that something can be underspecified (e.g. assertion details are vague), yet still widely implemented and very useful. From stpeter@stpeter.im Thu Apr 1 16:57:21 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706433A68AA for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 16:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFoYtsfYc3Jf for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 16:57:20 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 55FC23A689D for <oauth@ietf.org>; Thu, 1 Apr 2010 16:57:20 -0700 (PDT) Received: from squire.local (dsl-228-252.dynamic-dsl.frii.net [216.17.228.252]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8E3D240E15 for <oauth@ietf.org>; Thu, 1 Apr 2010 17:57:52 -0600 (MDT) Message-ID: <4BB532FF.5040307@stpeter.im> Date: Thu, 01 Apr 2010 17:57:51 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <0E4475A4-8014-419B-A20E-15DDF04300FD@xmlgrrl.com> <4BAA4CBC.905@mnt.se> In-Reply-To: <4BAA4CBC.905@mnt.se> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020306010503070201090607" Subject: Re: [OAUTH-WG] What are the OAuth design principles? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Apr 2010 23:57:21 -0000 This is a cryptographically signed message in MIME format. --------------ms020306010503070201090607 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/24/10 11:32 AM, Leif Johansson wrote: > On 03/23/2010 12:00 AM, Eve Maler wrote: >> Since the discussion in the "OAuth after-party" seemed to warrant >> bringing it up, I mentioned the UMA design principles/requirements >> document. You can find it here: >> >> http://kantarainitiative.org/confluence/display/uma/UMA+Requirements >> >> The discussion is around "Why can't Kerberos just be used for your use= >> cases?" The UMA principles might be able to inform how the OAuth WG >> makes its case for why Kerberos doesn't suffice. (If we discover it >> does, hey, our work here is done. :-) >=20 > There are two threads here >=20 > - why Kerberos _as such_ does or does not work for the use-cases > - what experiences from 3rd party schemes such as Kerberos or STS are > valuable for OAuth. >=20 > Being long-time Kerberos-fanboy I still say that one of those threads > are interesting and the other isn't. >=20 > I think its much more valuable to talk about how to distill experience > from Kerberos (etc) which are applicable to the design of OAuth. Agreed. Do you know if anyone has written up the design principles behind (or lessons learned) from Kerberos and STS? If not, we'll need to start prodding people into sharing their wisdom... Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020306010503070201090607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQwMTIzNTc1MVowIwYJKoZIhvcNAQkEMRYEFEwTD+2trIPUVohtfXwA acIkcoy2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAkEK/sxlVIAIQNFDkATIBMRLZBFcDd2bDrGU3Kjf7 IdQnadx7g0O7VAkFmxwr0b8mzUCqitgMC2BKAJM5odXracUoEodXM0+MX0JNiB0wuzw3a5lQ 72sS7PgtKrunfcj5Zm98IPObK2/zqho2DIDtX4WeKCb4lVO3iXkGDHFZDmdlrRpoWd6lVgEa UMF7EOzB17rI1yz0BvLCWEJTgJ2+RLJXnkbNsIhDYmROyV52GPFs0ArwD0HDrzgqsrblk/dF ENS8PAc+WHiVMX6oehjLUkKQUmGZdkjNn9VJbNidIkqhkRGdvzq/tFNQIMGGTdT9acUzyRBT 5fkJ3LZKhawW9QAAAAAAAA== --------------ms020306010503070201090607-- From eran@hueniverse.com Thu Apr 1 17:11:05 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9937C3A6867 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 17:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUypELyYbjYe for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 17:11:04 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8A9743A6954 for <oauth@ietf.org>; Thu, 1 Apr 2010 17:10:22 -0700 (PDT) Received: (qmail 6988 invoked from network); 2 Apr 2010 00:10:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 00:10:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Apr 2010 17:10:54 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Brian Eaton <beaton@google.com> Date: Thu, 1 Apr 2010 17:10:41 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrR+PUhGexX23NEQ1OZMOYYYPG7Rw== Message-ID: <044FD57B-F394-4706-A7D9-2D7E744E5956@hueniverse.com> References: <B6D3A5E0-36B2-4458-9CE6-F5F394E69B87@hueniverse.com> <C7DA6E66.3002%cmortimore@salesforce.com> <g2xdaf5b9571004011653g86643e29u5176a552ee8eb70c@mail.gmail.com> In-Reply-To: <g2xdaf5b9571004011653g86643e29u5176a552ee8eb70c@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 00:11:05 -0000 Are they profiling a half page spec? EHL On Apr 1, 2010, at 19:53, "Brian Eaton" <beaton@google.com> wrote: > On Thu, Apr 1, 2010 at 3:38 PM, Chuck Mortimore > <cmortimore@salesforce.com> wrote: >> Flexibility. If we lock Oauth2 down to one specific specific =20 >> Assertion, it >> becomes unusable for other assertion formats. Those assertion =20 >> formats will >> evolve anyways. > > Yep. The SAML Web SSO profiles are living proof that something can be > underspecified (e.g. assertion details are vague), yet still widely > implemented and very useful. From atom@yahoo-inc.com Thu Apr 1 17:14:51 2010 Return-Path: <atom@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66743A67B6 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 17:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.936 X-Spam-Level: X-Spam-Status: No, score=-14.936 tagged_above=-999 required=5 tests=[AWL=1.533, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2bZtGvmDwr4 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 17:14:45 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id BE1A23A687B for <oauth@ietf.org>; Thu, 1 Apr 2010 17:14:44 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o320F7eI049436; Thu, 1 Apr 2010 17:15:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: content-transfer-encoding:x-originalarrivaltime; b=VSXQD7HICN0dmKrkjotixkeuRcYu3lBB1SoJfKCh3DgKhGtmNejh65jW23joG3B+ Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 17:15:07 -0700 Received: from 172.21.148.134 ([172.21.148.134]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Apr 2010 00:14:43 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 01 Apr 2010 17:14:39 -0700 From: Allen Tom <atom@yahoo-inc.com> To: Marius Scurtescu <mscurtescu@google.com>, Justin Smith <justinsm@microsoft.com>, OAuth WG <oauth@ietf.org> Message-ID: <C7DA84FF.297F9%atom@yahoo-inc.com> Thread-Topic: [OAUTH-WG] Draft progress update Thread-Index: AcrR+XvypO+ZZLXL5kqDQvCse6krJQ== In-Reply-To: <i2s74caaad21004011137pb56ee578h6a6e158830534ba5@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 02 Apr 2010 00:15:07.0637 (UTC) FILETIME=[8D03AA50:01CAD1F9] Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 00:14:51 -0000 +1 on removing the recommendation to keep the tokens shorter than 255 chars= . While it's certainly a good idea to keep tokens reasonably compact, the sam= e way it's a great idea to keep URLs and Cookies short, the statement in the spec doesn't really do much. In practice, the tokens/urls/parameters need to be short enough such that the resulting URLs are less than 2KB (to support useragents and proxy servers that truncate long URLs) and that the HTTP Authorization header is less than the maximum allowed size (?? chars). I do acknowledge that it's ideal to specify a size limit on tokens - it makes life easier for implementers so that they'll be able to size their databases, and bandwidth/CPU constrained devices (aka mobile) will also benefit from having compact tokens. Allen On 4/1/10 11:37 AM, "Marius Scurtescu" <mscurtescu@google.com> wrote: > +1 on all comments, except for some question on 6... >=20 >=20 > On Thu, Apr 1, 2010 at 11:06 AM, Justin Smith <justinsm@microsoft.com> wr= ote: >> Eran, >>=20 >> Good progress. A few comments below: >>=20 >> Sec. 2.2. =A0Flow Parameters: >> Comment 1: The recommendation to keep access tokens less than 255 chars = seems >> bizarre. I'd like to remove it entirely. Previous threads have discussed >> this. > From beaton@google.com Thu Apr 1 17:16:07 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152C73A689D for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 17:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.327 X-Spam-Level: X-Spam-Status: No, score=-104.327 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFj35-BSTORb for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 17:16:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D5FB43A68E5 for <oauth@ietf.org>; Thu, 1 Apr 2010 17:15:59 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [10.3.21.2]) by smtp-out.google.com with ESMTP id o320GSLJ024330 for <oauth@ietf.org>; Thu, 1 Apr 2010 17:16:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270167388; bh=AtnXe8RIf1bIKH7FtJ3ALbobcyA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=dyQRwzilsqxqBClvDPoBlv1Sbi7pAX+cA0ao5zTnkYMYRl++yWRQDl+MNWTJ7HWiZ pwEJUYrzgrD/e6PT5Ls5A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=QqSOyJ7PMKSTrdpkzakngjsoCioa+iMDvcbNSVoBf37WNUi34qKfYFc1Zwwf8xPH8 60MZ6gOfEJmPzE9GHdFyA== Received: from vws9 (vws9.prod.google.com [10.241.21.137]) by hpaq2.eem.corp.google.com with ESMTP id o320GQp2013410 for <oauth@ietf.org>; Fri, 2 Apr 2010 02:16:27 +0200 Received: by vws9 with SMTP id 9so823512vws.17 for <oauth@ietf.org>; Thu, 01 Apr 2010 17:16:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.2 with HTTP; Thu, 1 Apr 2010 17:16:26 -0700 (PDT) In-Reply-To: <044FD57B-F394-4706-A7D9-2D7E744E5956@hueniverse.com> References: <B6D3A5E0-36B2-4458-9CE6-F5F394E69B87@hueniverse.com> <C7DA6E66.3002%cmortimore@salesforce.com> <g2xdaf5b9571004011653g86643e29u5176a552ee8eb70c@mail.gmail.com> <044FD57B-F394-4706-A7D9-2D7E744E5956@hueniverse.com> Date: Thu, 1 Apr 2010 17:16:26 -0700 Received: by 10.220.4.20 with SMTP id 20mr819424vcp.142.1270167386348; Thu, 01 Apr 2010 17:16:26 -0700 (PDT) Message-ID: <y2rdaf5b9571004011716t5c475c74p5d813a464f78592@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 00:16:07 -0000 On Thu, Apr 1, 2010 at 5:10 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > Are they profiling a half page spec? The spec is 66 pages long. But the widely used pieces are quite a bit shorter. =) From atom@yahoo-inc.com Thu Apr 1 17:49:52 2010 Return-Path: <atom@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43463A6991 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 17:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.154 X-Spam-Level: X-Spam-Status: No, score=-13.154 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8F0rTxS1jtb for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 17:49:48 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 172593A69A3 for <oauth@ietf.org>; Thu, 1 Apr 2010 17:49:22 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o320nVac063885 for <oauth@ietf.org>; Thu, 1 Apr 2010 17:49:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:mime-version:content-type:x-originalarrivaltime; b=BN7VN0Rtkyxlhw93ZvYXk3SPg244zc/WXJfUQX4ikNiQy126roLIaYHW7pUineF2 Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 17:49:31 -0700 Received: from 172.21.148.134 ([172.21.148.134]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Apr 2010 00:48:42 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 01 Apr 2010 17:48:36 -0700 From: Allen Tom <atom@yahoo-inc.com> To: OAuth WG <oauth@ietf.org> Message-ID: <C7DA8CF4.2980D%atom@yahoo-inc.com> Thread-Topic: User Interface specs? Thread-Index: AcrR/joXiTwdAhjxhEyE3qdhMST83A== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3352988918_6491715" X-OriginalArrivalTime: 02 Apr 2010 00:49:31.0653 (UTC) FILETIME=[5B438350:01CAD1FE] Subject: [OAUTH-WG] User Interface specs? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 00:49:53 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3352988918_6491715 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open a popup window to the user=B9s Identity Provider for user to complete the AuthZ/AuthN flow rather than taking the user away from the referring site via a full page redirect. In the case where a popup window is used, it=B9s a very good idea to require that that the browser=B9s address bar is displayed, and that an independent browser window is used, rather than an inline iframe. These requirements ar= e needed to help prevent the user from being phished in the case where the user has to enter their password, and to ensure that the user=B9s consent was not forged via a clickjacking attack. I believe that the Web Server Flow and the Web Client Flow will often take place within a popup window, so it would make sense to put into the core spec that popups should be independent browser windows with the address bar clearly displayed.=20 Another missing feature in the core spec is support for multiple languages. Given that many Service Providers have a global userbase, client applications will want to have a way to specify the language to be used on the auth screen. While the User Agent=B9s Accept-Language: HTTP header, as well as the user=B9s IP address could be used as language hints, in practice clients will want the ability to specify the language. Is there consensus to get Popup Window requirements and language support into the OAuth2 core spec? Allen --B_3352988918_6491715 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>User Interface specs? Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open a = popup window to the user’s Identity Provider for user to complete the = AuthZ/AuthN flow rather than taking the user away from the referring site vi= a a full page redirect.

In the case where a popup window is used, it’s a very good idea to re= quire that that the browser’s address bar is displayed, and that an in= dependent browser window is used, rather than an inline iframe. These requir= ements are needed to help prevent the user from being phished in the case wh= ere the user has to enter their password, and to ensure that the user’= s consent was not forged via a clickjacking attack.

I believe that the Web Server Flow and the Web Client Flow will often take = place within a popup window, so it would make sense to put into the core spe= c that popups should be independent browser windows with the address bar cle= arly displayed.

Another missing feature in the core spec is support for multiple languages.= Given that many Service Providers have a global userbase, client applicatio= ns will want to have a way to specify the language to be used on the auth sc= reen. While the User Agent’s Accept-Language: HTTP header, as well as = the user’s IP address could be used as language hints, in practice cli= ents will want the ability to specify the language.

Is there consensus to get Popup Window requirements and language support in= to the OAuth2 core spec?

Allen
 --B_3352988918_6491715-- From stpeter@stpeter.im Thu Apr 1 18:59:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41E53A6403 for ; Thu, 1 Apr 2010 18:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7+bnC1SYOIc for ; Thu, 1 Apr 2010 18:59:20 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A188D3A6940 for ; Thu, 1 Apr 2010 18:59:15 -0700 (PDT) Received: from squire.local (dsl-228-252.dynamic-dsl.frii.net [216.17.228.252]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2291F40E15 for ; Thu, 1 Apr 2010 19:59:48 -0600 (MDT) Message-ID: <4BB54F92.1060201@stpeter.im> Date: Thu, 01 Apr 2010 19:59:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <191F411E00E19F4E943ECDB6D65C6085168FCFE8@TK5EX14MBXC115.redmond.corp.microsoft.com> <191F411E00E19F4E943ECDB6D65C60851690A880@TK5EX14MBXC115.redmond.corp.microsoft.com> In-Reply-To: <191F411E00E19F4E943ECDB6D65C60851690A880@TK5EX14MBXC115.redmond.corp.microsoft.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050608080806090605060001" Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 01:59:21 -0000 This is a cryptographically signed message in MIME format. --------------ms050608080806090605060001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/1/10 4:22 PM, Justin Smith wrote: >> I don't see why an opaque scope parameter would create any >> problems for a library implementation. Working on such an >> implementation right now and opaque scopes are perfectly fine. >=20 > I completely agree. In practice this hasn't caused a problem. We > discussed the idea of forcing an absolute URI here and whether it had > to be the actual resource URI. That doesn't work when the AS uses the > same access policy for multiple resources. Opaque seems like a fine > proposal to me. >=20 >>> Comment 3: This isn't the case when the client is presenting a >>> token issued by another server. I suggest a change to something >>> like the following: "When requesting access from the >>> authorization server, the client identifies itself using client >>> credentials known to the authorization server." >>=20 >> What token? The authorization endpoint isn't an OAuth-protected >> resource. >=20 > In the case where you present a SAML (or other format) assertion, it > is a kind of a protected resource - the resource is an access token. >=20 >>> This isn't the old testament. No need to look for hidden meaning. >>> The spec is about getting access to protected resources, >>> generally dealing with *a* protected resource. How resources are >>> segmented is beyond the scope. I think it is more useful to talk >>> about it using simpler assumptions - it doesn't prevent the more >>> complex use cases. >=20 >> I think this ties in with the scope parameter. When requesting >> authorization, if a client can also pass a scope parameter, then >> access is granted only to the resources that accept that scope and >> not to all resources controlled by this Authorization Server. >=20 > This is only a minor wording comment, but I think the idea is > significant. The assumption that there is a 1:1 mapping between an AS > and a PR seems out of place for the spec. It's easy to imagine that a > single AS controls access to many resources (photos, friends, address > books, etc.) - this is in fact what happens today. If that's true, then how does the Authorization Server know what scope is appropriate at the Protected Resource? Does inclusion of the scope parameter require a 1:1 mapping between AS and PR, or at least communication between AS and PR? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050608080806090605060001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQwMjAxNTk0NlowIwYJKoZIhvcNAQkEMRYEFGUWZZ2L4HLfR8yP9DaP pKqMz8OkMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAbpnHKdw5Ev7LHbW1QU8hq2m7KSRi2zKKP2D8I4aD kWIyojH9RfamdtJftx17+V+1lXXANKBhbbH8XifTlB5BsEJAXsD0LvZ+YFElPjhxFjo4FUD8 sqNVhyB2Zk8Vq4X2MwaOMkRxdbGbtUno/URPv/t1cXcHVGNY+KGoyXruLmxww4FG6G8Oshdp TZflojEpTgXk6fDoj0AVOR6e78C8E4VNsFijSyj47as26cO7lYJtZIEkwDkJtctRSHFsXY0U 2FPS3FxqjZR4x8+KxOSke40rmypSVPAuQnSYtTI+y5wd1hzlrS6jbFG+CxjLbizXtTgbi1uL 1YsGDoec0hN7rgAAAAAAAA== --------------ms050608080806090605060001-- From atom@yahoo-inc.com Thu Apr 1 19:22:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A903A6960 for ; Thu, 1 Apr 2010 19:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.949 X-Spam-Level: X-Spam-Status: No, score=-14.949 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEvXu4qKjGTK for ; Thu, 1 Apr 2010 19:22:43 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 5AB003A6A4D for ; Thu, 1 Apr 2010 19:22:25 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o322MM6T000213; Thu, 1 Apr 2010 19:22:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: content-transfer-encoding:x-originalarrivaltime; b=lbJaSuFVB/xOPhw0a3OjTihdDNsJAFPQALoTPGe+s5VlKE29XufjbOtW2RuiB0Vd Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 19:22:22 -0700 Received: from 172.21.148.134 ([172.21.148.134]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Apr 2010 02:21:45 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 01 Apr 2010 19:21:43 -0700 From: Allen Tom To: Peter Saint-Andre , Message-ID: Thread-Topic: [OAUTH-WG] Draft progress update Thread-Index: AcrSCzw0tjRWAOCwKEW8K6aLS2aCVQ== In-Reply-To: <4BB54F92.1060201@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Apr 2010 02:22:22.0200 (UTC) FILETIME=[53918780:01CAD20B] Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 02:22:44 -0000 The way we do this at Yahoo is that the developer must indicate what scopes they want to access when registering for a client_identifier/secret. Although we've done it this way for several years, we've gotten plenty of feedback that client developers want the flexibility to specify the scopes at user authorization time. Allen On 4/1/10 6:59 PM, "Peter Saint-Andre" wrote: > > > If that's true, then how does the Authorization Server know what scope > is appropriate at the Protected Resource? Does inclusion of the scope > parameter require a 1:1 mapping between AS and PR, or at least > communication between AS and PR? > > Peter From atom@yahoo-inc.com Thu Apr 1 19:54:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905133A6A5A for ; Thu, 1 Apr 2010 19:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.148 X-Spam-Level: X-Spam-Status: No, score=-13.148 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UWrI+BdyzXd for ; Thu, 1 Apr 2010 19:54:21 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 1C44B3A67D2 for ; Thu, 1 Apr 2010 19:54:20 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o322skSS007840 for ; Thu, 1 Apr 2010 19:54:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:mime-version:content-type:return-path:x-originalarrivaltime; b=JqLExqLVYj9wI4xTkGhqk7CRpYq6bJYDEdmdR1FdFqy1evzcskHWBpwHHk+M/7s2 Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 19:54:46 -0700 Received: from 172.21.148.134 ([172.21.148.134]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Apr 2010 02:54:09 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 01 Apr 2010 19:54:05 -0700 From: Allen Tom To: OAuth WG Message-ID: Thread-Topic: Device Flow - Session Fixation? Thread-Index: AcrSD8G5fQBgLf/cfUu/CliP82l2dQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3352996447_6906641" X-OriginalArrivalTime: 02 Apr 2010 02:54:46.0168 (UTC) FILETIME=[DA438180:01CAD20F] Subject: [OAUTH-WG] Device Flow - Session Fixation? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 02:54:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3352996447_6906641 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Longtime fans of Oauth will remember the Session Fixation security issue we had last year. The Device Flow specified in the OAuth2 draft seems to have the same issue. To illustrate: Imagine that a Photos Hosting Service supports OAuth2, and supports the Device Flow for Internet enabled picture frames. These devices have screens= , but no browser, and no keyboard. An Attacker sets up his picture frame, and is instructed to use a browser o= n a separate device to authorize the picture frame. However, rather than entering oauth_verification_url on his own browser he instead socially engineers a victim to do it. (this is essentially the same thing as phishing) The Attacker IMs or emails the victim the link to the Auth url =AD depending on how the Auth Flow is implemented, the attacker might even be able to construct the auth url with the oauth_user_code appended as a query parameter. If the victim is persuaded to click the link and approve the aut= h request, the Attacker will then have access to the victim=B9s photos. Again, this is social engineering, and the victim has to be persuaded to click on an untrusted link and to click =B3approve=B2 on a strange auth screen. That being said, this sort of thing happens pretty often. In Oauth 1.0a and in WRAP, this attack is not possible. In both WRAP and in Oauth 1.0a, the victim=B9s browser is issued a verification code which someho= w must be passed back to the attacker in order for the attacker to access the victim=B9s private data. While the Web Server and Web Client flows both have the verification_code to prevent the session fixation attack, the Device Flow does not. Is this a problem? Allen --B_3352996447_6906641 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Device Flow - Session Fixation? Longtime fans of Oauth will remember the Session Fixation security issue w= e had last year.

The Device Flow specified in the OAuth2 draft seems to have the same issue.=

To illustrate:

Imagine that a Photos Hosting Service supports OAuth2, and supports the Dev= ice Flow for Internet enabled picture frames. These devices have screens, bu= t no browser, and no keyboard.

An Attacker sets up his picture frame, and is instructed to use a browser o= n a separate device to authorize the picture frame. However, rather than ent= ering oauth_verification_url on his own browser he instead socially engineer= s a victim to do it. (this is essentially the same thing as phishing)

The Attacker IMs  or emails the victim the link to the Auth url –= ; depending on how the Auth Flow is implemented, the attacker might even be = able to construct the auth url with the oauth_user_code appended as a query = parameter. If the victim is persuaded to click the link and approve the auth= request, the Attacker will then have access to the victim’s photos. <= BR>
Again, this is social engineering, and the victim has to be persuaded to cl= ick on an untrusted link and to click “approve” on a strange aut= h screen. That being said, this sort of thing happens pretty often.

In Oauth 1.0a and in WRAP, this attack is not possible. In both WRAP and in= Oauth 1.0a, the victim’s browser is issued a verification code which = somehow must be passed back to the attacker in order for the attacker to acc= ess the victim’s private data. While the Web Server and Web Client flo= ws both have the verification_code to prevent the session fixation attack, t= he Device Flow does not.

Is this a problem?

Allen
 --B_3352996447_6906641-- From esachs@google.com Thu Apr 1 20:05:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E893A67F5 for ; Thu, 1 Apr 2010 20:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.246 X-Spam-Level: X-Spam-Status: No, score=-98.246 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTpLgxvmbAHW for ; Thu, 1 Apr 2010 20:05:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 97B883A6A61 for ; Thu, 1 Apr 2010 20:04:37 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o32358lh020981 for ; Fri, 2 Apr 2010 05:05:09 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270177509; bh=iG0GoYaS4FrQAHJq0oVB+HMx1Ro=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=x6L0QKAjmYiBLkQamDK3TgwMnmpx4SYsPqfz9qwxv6VWpJY+n8uX/Ivb8GNAW6Mc4 +hVEzSNArafW2c/DkBiuQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=yQtrmjhtLjLLACEkSbPursby/CZdVX6BYioSIeJNrw9kCXDMucc6c7eIWLN8UAGnR ORLGJOJieifIoHEN9JW+A== Received: from vws18 (vws18.prod.google.com [10.241.21.146]) by kpbe16.cbf.corp.google.com with ESMTP id o32357qC025574 for ; Thu, 1 Apr 2010 20:05:07 -0700 Received: by vws18 with SMTP id 18so472276vws.4 for ; Thu, 01 Apr 2010 20:05:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.106.80 with HTTP; Thu, 1 Apr 2010 20:05:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Apr 2010 20:05:07 -0700 Received: by 10.220.128.136 with SMTP id k8mr883788vcs.178.1270177507103; Thu, 01 Apr 2010 20:05:07 -0700 (PDT) Message-ID: From: Eric Sachs To: Allen Tom Content-Type: multipart/alternative; boundary=e0cb4e8875891cd3620483383fd4 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Device Flow - Session Fixation? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 03:05:43 -0000 --e0cb4e8875891cd3620483383fd4 Content-Type: text/plain; charset=ISO-8859-1 Here is the note I sent a few weeks ago where we also noted the potential session fixation attack. However as we noted, we are still willing to start with this profile and later work on where the user has to enter a code into the device. ---------- Forwarded message ---------- From: Eric Sachs Date: Wed, Mar 17, 2010 at 5:45 PM Subject: Re: [OAUTH-WG] Device Profile To: Brent Goldman Cc: "OAuth WG (oauth@ietf.org)" Google has a similar requirement to move these types of devices to OAuth/WRAP and away from our older "ClientLogin" protocol where the user is prompted for their username/password. The proposed profile looks fine, but we are a few weeks from being able to do specific work on it, so we may have more feedback at that time. If the device can accept some user input, then there are some security advantages to requiring the user to get the code from their computer and then enter it into the device. In particular, it makes it easier to protect against a DOS attack targeted at the service-provider to request a large # of codes. That method also reduces the risk of a phishing/session-fixation type attack. However we agree that some profile is needed for devices with no user input. We also expect it will be easier to get these device vendors to use a common industry technique, so we are fine with prioritizing our support for this profile. Longer term the community could define a profile where the code is displayed on the computer. On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman wrote: > Over the past couple days, Luke Shepard, David Recordon, and I have been > brainstorming an OAuth profile for standardizing the flow that devices such > as game consoles and entertainment centers use to hook up with services such > as Netflix and iTunes. The basic flow is that a device can gain > authorization by directing the user to visit a URL on their computer and to > enter a verification code copied from the device's screen. > > A draft spec is attached to this email. Any thoughts or feedback? > > Note: this is one of the many profiles going into the OAuth 2.0 draft that > David is writing (http://daveman692.livejournal.com/349384.html). > > -Brent > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --e0cb4e8875891cd3620483383fd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Here is the note I sent a few weeks ago where we also noted the potent= ial session fixation attack. =A0However as we noted, we are still willing t= o start with this profile and later work on where the user has to enter a c= ode into the device.


---------- Forwarded message = ----------
From:=A0Eric Sachs=A0<esachs@google.com&= gt;
Date: Wed, Mar 17, 2010 at 5:45 PM
Subject: Re: [OAUTH-WG] Device Profil= e
To: Brent Goldman <brent@face= book.com>
Cc: "OAuth WG (o= auth@ietf.org)" <oauth@ietf.o= rg>


Google has a similar requirement to move these types of devices to = OAuth/WRAP and away from our older "ClientLogin" protocol where t= he user is prompted for their username/password. =A0The proposed profile lo= oks fine, but we are a few weeks from being able to do specific work on it,= so we may have more feedback at that time.

If the device can accept some user input, then there are som= e security advantages to requiring the user to get the code from their comp= uter and then enter it into the device. =A0In particular, it makes it easie= r to protect against a DOS attack targeted at the service-provider to reque= st a large # of codes. =A0That method also reduces the risk of a phishing/s= ession-fixation type attack. =A0However we agree that some profile is neede= d for devices with no user input. =A0We also expect it will be easier to ge= t these device vendors to use a common industry technique, so we are fine w= ith prioritizing our support for this profile. =A0Longer term=A0the communi= ty could define a profile where the code is displayed on the computer.

On Thu, Mar 11, 2010 = at 3:27 AM, Brent Goldman=A0<brent@facebook.com>=A0wrote:
Over the past couple days, Luke Shepard, = David Recordon, and I have been brainstorming an OAuth profile for standard= izing the flow that devices such as game consoles and entertainment centers= use to hook up with services such as Netflix and iTunes. The basic flow is= that a device can gain authorization by directing the user to visit a URL = on their computer and to enter a verification code copied from the device&#= 39;s screen.

A draft spec is attached to this email. Any thoughts or feedback?
Note: this is one of the many profiles going into the OAuth 2.0 draft tha= t David is writing (http://daveman692.livejournal.com/349384.html).
-Brent



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


--e0cb4e8875891cd3620483383fd4-- From stpeter@stpeter.im Thu Apr 1 20:12:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6423A6830 for ; Thu, 1 Apr 2010 20:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.215 X-Spam-Level: X-Spam-Status: No, score=-1.215 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CSv4wG7WZKe for ; Thu, 1 Apr 2010 20:12:46 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 223823A67F5 for ; Thu, 1 Apr 2010 20:12:46 -0700 (PDT) Received: from squire.local (dsl-228-252.dynamic-dsl.frii.net [216.17.228.252]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8A47140E15; Thu, 1 Apr 2010 21:13:18 -0600 (MDT) Message-ID: <4BB560CD.9000004@stpeter.im> Date: Thu, 01 Apr 2010 21:13:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Allen Tom References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030107070302080108060001" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 03:12:47 -0000 This is a cryptographically signed message in MIME format. --------------ms030107070302080108060001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/1/10 8:21 PM, Allen Tom wrote: > The way we do this at Yahoo is that the developer must indicate what sc= opes > they want to access when registering for a client_identifier/secret. >=20 > Although we've done it this way for several years, we've gotten plenty = of > feedback that client developers want the flexibility to specify the sco= pes > at user authorization time. OK, so the scope is something that the [developer of a] Client establishes beforehand with the Authorization Service. But that still doesn't tell us what a scope is. Does someone have a definition? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030107070302080108060001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQwMjAzMTMxN1owIwYJKoZIhvcNAQkEMRYEFAuA0j3aNHa15OwcZdy4 HWb1wpcDMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAl197tFHbqzBfpZv5Vz3jSJl0l2QVnEtQIFXuZcTI BquSe7akujnrJh346BxRV7mqcYS1OJE44+u1pDE+rATQkQn/wKyT1lZsjv30z6FcqEW1cXrq ruf5rWYl9ZFKJburxSQH3gzMows2ekbZLWE94VGxLPnfPPNmwJQQPzveC+3nzbKVzRUdGL6v PTb8bvsUM9dLZVruRJ68Bm23ajQdP5v5TyMy1lnvuFo1jyny8Q0+GA2Gxy/JQn5aC5Ml6tNe 3buJsnB72Tnu86OJ6hayniF25IBZqkRabcjmmXR7evRT5K0CoDsAy5L3zz1FksS+b2DMu+jM saACf5o4BBbX4QAAAAAAAA== --------------ms030107070302080108060001-- From atom@yahoo-inc.com Thu Apr 1 20:16:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5FCC3A69CB for ; Thu, 1 Apr 2010 20:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.004 X-Spam-Level: X-Spam-Status: No, score=-13.004 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNM2BDuVLa95 for ; Thu, 1 Apr 2010 20:16:44 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id C013B3A67C0 for ; Thu, 1 Apr 2010 20:16:44 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o323Ful6019649; Thu, 1 Apr 2010 20:15:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type:x-originalarrivaltime; b=jJrPyDO2y+N1yP04CJFfFVW4mO0wP3IhGUzTQ6b113nHoqNCNu+w41fyBeSVKMTu Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 20:15:56 -0700 Received: from 172.21.148.134 ([172.21.148.134]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Apr 2010 03:15:12 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 01 Apr 2010 20:15:07 -0700 From: Allen Tom To: George Fletcher , "oauth@ietf.org" Message-ID: Thread-Topic: [OAUTH-WG] Re-scoping OAuth access tokens Thread-Index: AcrSErHvBM+iwfYNl0Kd54BZKQ2B0g== In-Reply-To: <4BACF59D.9090805@aol.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3352997710_7019253" X-OriginalArrivalTime: 02 Apr 2010 03:15:56.0528 (UTC) FILETIME=[CF750F00:01CAD212] Subject: Re: [OAUTH-WG] Re-scoping OAuth access tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 03:16:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3352997710_7019253 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi George - I=B9m trying to figure out the re-scoping flow as well, to allow clients to progressively upgrade their scopes over time. A potential pitfall is the scenario where multiple clients, share the same client_id and secret. For instance, a developer might have both a website and also an iphone app, and reuses the same client_id for both. Should the Service Provider keep the scopes in sync for both apps? If the refresh_token is not passed to the re-auth flow, the Service Provider will have a hard time determining which instance of the app is requesting the upgraded scope. Perhaps this doesn't matter, because it can be argued that although there might be multiple instances of the same client_id, it=B9s all the same app anyway. So maybe it=B9s OK to upgrade the scopes for all instances of a given client_id. Allen On 3/26/10 10:57 AM, "George Fletcher" wrote: >=20 >=20 > It it sufficient for the client to just start a new web server flow and > specify a new scope parameter that includes both "read buddylist" and "se= nd > IM"? The AS would then show Alice that she'd already approved "read buddy= list" > and just needed to approve "send IM"? This requires the client to keep tr= ack > of all scopes requested for a given user:protected_resource. >=20 > Another option might be to just allow the client to pass in the refresh_t= oken > (as that likely has the scoped embedded/associated with it). In this case= the > client could just ask for the new scope it wanted. >=20 > Thoughts? Anyone else have a need for dynamic re-scoping? >=20 > Thanks, > George >=20 > P.S. This flow is deployedas part of the AOL IM APIs. However, when > dynamically adding an authorization, we only show the user what their bei= ng > asked to consent to, not what they've done in the past. >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --B_3352997710_7019253 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] Re-scoping OAuth access tokens Hi George -

I’m trying to figure out the re-scoping flow as well, to allow client= s to progressively upgrade their scopes over time.

A potential pitfall is the scenario where multiple clients, share the same = client_id and secret. For instance, a developer might have both a website an= d also an iphone app, and reuses the same client_id for both.

Should the Service Provider keep the scopes in sync for both apps? If the r= efresh_token is not passed to the re-auth flow, the Service Provider will ha= ve a hard time determining which instance of the app is requesting the upgra= ded scope.

Perhaps this doesn't matter, because it can be argued that although there m= ight be multiple instances of the same client_id, it’s all the same ap= p anyway. So maybe it’s OK to upgrade the scopes for all instances of = a given client_id.

Allen

On 3/26/10 10:57 AM, "George Fletcher" <gffletch@aol.com> wrote:



It it sufficient for the client to just start a new web server flow and spe= cify a new scope parameter that includes both "read buddylist" and= "send IM"? The AS would then show Alice that she'd already approv= ed "read buddylist" and just needed to approve "send IM"= ? This requires the client to keep track of all scopes requested for a given= user:protected_resource.

Another option might be to just allow the client to pass in the refresh_tok= en (as that likely has the scoped embedded/associated with it). In this case= the client could just ask for the new scope it wanted.

Thoughts?  Anyone else have a need for dynamic re-scoping?

Thanks,
George

P.S. This flow is deployedas part of the AOL IM APIs. However, when dynamic= ally adding an authorization, we only show the user what their being asked t= o consent to, not what they've done in the past.


___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth
--B_3352997710_7019253-- From brent@facebook.com Thu Apr 1 20:25:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812743A69B6 for ; Thu, 1 Apr 2010 20:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.465 X-Spam-Level: X-Spam-Status: No, score=0.465 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+Z-npIA-arc for ; Thu, 1 Apr 2010 20:25:41 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 8EA603A68AF for ; Thu, 1 Apr 2010 20:25:41 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o323Pd5w027762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Apr 2010 20:25:40 -0700 Received: from sc-hub02.TheFacebook.com (192.168.18.105) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.682.1; Thu, 1 Apr 2010 20:25:52 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Thu, 1 Apr 2010 20:25:49 -0700 From: Brent Goldman To: Allen Tom Date: Thu, 1 Apr 2010 20:25:08 -0700 Thread-Topic: [OAUTH-WG] User Interface specs? Thread-Index: AcrSFDB31fHtGMoYQWKPrse8oENLoQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F2D61FDB9B5A4C1A8276E36AF055F859facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_02:2010-02-06, 2010-04-02, 2010-04-01 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] User Interface specs? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 03:25:42 -0000 --_000_F2D61FDB9B5A4C1A8276E36AF055F859facebookcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 on both Regarding clickjacking: If we don't want the flows to be inlined in an ifra= me, specifying that the clients must show the server in a popup doesn't pro= tect against malicious clients that choose to show it in an iframe anyway. = So I think it also make sense to add to the core spec that servers should p= rotect against this. The JavaScript is simple enough that perhaps the spec = could give an example snippet that any OAuth server to use. E.g., if (top != =3D self && !isTopWindowSafe(top)) { showBigassTransparentDivWithHighZIndex= _or_redirectToErrorPage(); }. -Brent On Apr 1, 2010, at 5:48 PM, Allen Tom wrote: Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open a p= opup window to the user=92s Identity Provider for user to complete the Auth= Z/AuthN flow rather than taking the user away from the referring site via a= full page redirect. In the case where a popup window is used, it=92s a very good idea to requir= e that that the browser=92s address bar is displayed, and that an independe= nt browser window is used, rather than an inline iframe. These requirements= are needed to help prevent the user from being phished in the case where t= he user has to enter their password, and to ensure that the user=92s consen= t was not forged via a clickjacking attack. I believe that the Web Server Flow and the Web Client Flow will often take = place within a popup window, so it would make sense to put into the core sp= ec that popups should be independent browser windows with the address bar c= learly displayed. Another missing feature in the core spec is support for multiple languages.= Given that many Service Providers have a global userbase, client applicati= ons will want to have a way to specify the language to be used on the auth = screen. While the User Agent=92s Accept-Language: HTTP header, as well as t= he user=92s IP address could be used as language hints, in practice clients= will want the ability to specify the language. Is there consensus to get Popup Window requirements and language support in= to the OAuth2 core spec? Allen --_000_F2D61FDB9B5A4C1A8276E36AF055F859facebookcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1 on both
=
Regarding clickjacking: If we don't want the flows to be inlined = in an iframe, specifying that the clients must show the server in a popup d= oesn't protect against malicious clients that choose to show it in an ifram= e anyway. So I think it also make sense to add to the core spec that server= s should protect against this. The JavaScript is simple enough that perhaps= the spec could give an example snippet that any OAuth server to use. = E.g., if (top !=3D self && !isTopWindowSafe(top)) { showBigassTrans= parentDivWithHighZIndex_or_redirectToErrorPage(); }.

-Brent


On Apr 1, 2010, at 5:48 PM, A= llen Tom wrote:

Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often op= en a popup window to the user=92s Identity Provider for user to complete th= e AuthZ/AuthN flow rather than taking the user away from the referring site= via a full page redirect.

In the case where a popup window is used, it=92s a very good idea to requir= e that that the browser=92s address bar is displayed, and that an independe= nt browser window is used, rather than an inline iframe. These requirements= are needed to help prevent the user from being phished in the case where t= he user has to enter their password, and to ensure that the user=92s consen= t was not forged via a clickjacking attack.

I believe that the Web Server Flow and the Web Client Flow will often take = place within a popup window, so it would make sense to put into the core sp= ec that popups should be independent browser windows with the address bar c= learly displayed.

Another missing feature in the core spec is support for multiple languages.= Given that many Service Providers have a global userbase, client applicati= ons will want to have a way to specify the language to be used on the auth = screen. While the User Agent=92s Accept-Language: HTTP header, as well as t= he user=92s IP address could be used as language hints, in practice clients= will want the ability to specify the language.

Is there consensus to get Popup Window requirements and language support in= to the OAuth2 core spec?

Allen
<ATT00001..txt>

=
= --_000_F2D61FDB9B5A4C1A8276E36AF055F859facebookcom_-- From eran@hueniverse.com Thu Apr 1 21:02:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4350C3A693F for ; Thu, 1 Apr 2010 21:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h85RoL8WPlQu for ; Thu, 1 Apr 2010 21:02:25 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A41B23A6863 for ; Thu, 1 Apr 2010 21:02:24 -0700 (PDT) Received: (qmail 8576 invoked from network); 2 Apr 2010 04:02:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 04:02:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Apr 2010 21:02:13 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Thu, 1 Apr 2010 21:02:11 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrR+b3eIZ0qtQkjQ5Gxo8m3q38+gAAH4dPJ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7DABA5331B60eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 04:02:29 -0000 --_000_C7DABA5331B60eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This boils down to: if the flow cannot be used without further profile, and= it is less than a page long, what's the value of putting it in the specifi= cation, as opposed to a fully specified extension? Or the alternative to pr= ovide one fully specified flow using the most common type of assertions (I'= m not a SAML expert so I have no clue what that might be), and let others u= se that as a template. But providing a half baked flow that is short enough to just replicate wher= e needed and cannot be fully implemented by generic libraries doesn't reall= y offer much. I am not putting a stake in the ground on this but I am doing my job as edi= tor to point out to the authors and users of this spec that as written, the= flow is just not actually useful. It has the same value as if I posted it = on my blog because to use it, someone will have to write a new spec that pr= ofiles it to an interop-capable setup. EHL On 4/1/10 5:16 PM, "Brian Eaton" wrote: On Thu, Apr 1, 2010 at 5:10 PM, Eran Hammer-Lahav wro= te: > Are they profiling a half page spec? The spec is 66 pages long. But the widely used pieces are quite a bit shorter. =3D) --_000_C7DABA5331B60eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>This boils down to: if the flow cannot be used without further profil= e, and it is less than a page long, what’s the value of putting it in= the specification, as opposed to a fully specified extension? Or the alter= native to provide one fully specified flow using the most common type of as= sertions (I’m not a SAML expert so I have no clue what that might be)= , and let others use that as a template.<BR> <BR> But providing a half baked flow that is short enough to just replicate wher= e needed and cannot be fully implemented by generic libraries doesn’t= really offer much.<BR> <BR> I am not putting a stake in the ground on this but I am doing my job as edi= tor to point out to the authors and users of this spec that as written, the= flow is just not actually useful. It has the same value as if I posted it = on my blog because to use it, someone will have to write a new spec that pr= ofiles it to an interop-capable setup.<BR> <BR> EHL<BR> <BR> <BR> On 4/1/10 5:16 PM, "Brian Eaton" <<a href=3D"beaton@google.com= ">beaton@google.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>On Thu, Apr 1, 2010 at 5:10 PM, Eran Hammer= -Lahav <<a href=3D"eran@hueniverse.com">eran@hueniverse.com</a>> wrot= e:<BR> > Are they profiling a half page spec?<BR> <BR> The spec is 66 pages long.  But the widely used pieces are quite a bit= <BR> shorter. =3D)<BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C7DABA5331B60eranhueniversecom_-- From brent@facebook.com Thu Apr 1 21:06:50 2010 Return-Path: <brent@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD8E3A6916 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.466 X-Spam-Level: X-Spam-Status: No, score=0.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXfKzFUbEcZc for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:06:49 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id F2F063A695A for <oauth@ietf.org>; Thu, 1 Apr 2010 21:06:48 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o3246pmJ015838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Apr 2010 21:06:57 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.682.1; Thu, 1 Apr 2010 21:07:07 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Thu, 1 Apr 2010 21:07:07 -0700 From: Brent Goldman <brent@facebook.com> To: Eric Sachs <esachs@google.com> Date: Thu, 1 Apr 2010 21:06:26 -0700 Thread-Topic: [OAUTH-WG] Device Flow - Session Fixation? Thread-Index: AcrSGfW5TykVMTtMTuy6bQ4aCECZEA== Message-ID: <710CC9A4-422B-424A-8FC2-AB190F41E87F@facebook.com> References: <C7DAAA5D.29853%atom@yahoo-inc.com> <j2oc4161f511004012005xb631ee6fx4a16c4381c58ceed@mail.gmail.com> In-Reply-To: <j2oc4161f511004012005xb631ee6fx4a16c4381c58ceed@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_710CC9A4422B424A8FC2AB190F41E87Ffacebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_05:2010-02-06, 2010-04-02, 2010-04-01 signatures=0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Device Flow - Session Fixation? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 04:06:50 -0000 --_000_710CC9A4422B424A8FC2AB190F41E87Ffacebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Isn't there a similar attack for the reverse protocol? The attacker would s= ocially engineer the user to give them the post-auth verification code disp= layed on the computer. This gives the attacker access to everything. We could make this more strict by having both a device code and verificatio= n code. That is, have the user enter the device code into the computer, whi= ch would produce a verification code that needs to be entered back into the= device. But this is susceptible to the same attack: after visiting the lin= k sent by the attacker, and clicking "approve on a strange auth screen", th= e user would have to send the verification code back to the attacker. This = is slightly better in that for an attack to be successful, the user has to = communicate with the attacker twice instead of once. I can't really think of a good way to eliminate the attack entirely, though= . -Brent On Apr 1, 2010, at 8:05 PM, Eric Sachs wrote: Here is the note I sent a few weeks ago where we also noted the potential s= ession fixation attack. However as we noted, we are still willing to start= with this profile and later work on where the user has to enter a code int= o the device. ---------- Forwarded message ---------- From: Eric Sachs <esachs@google.com<mailto:esachs@google.com>> Date: Wed, Mar 17, 2010 at 5:45 PM Subject: Re: [OAUTH-WG] Device Profile To: Brent Goldman <brent@facebook.com<mailto:brent@facebook.com>> Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" <oauth@ietf.org<mail= to:oauth@ietf.org>> Google has a similar requirement to move these types of devices to OAuth/WR= AP and away from our older "ClientLogin" protocol where the user is prompte= d for their username/password. The proposed profile looks fine, but we are= a few weeks from being able to do specific work on it, so we may have more= feedback at that time. If the device can accept some user input, then there are some security adva= ntages to requiring the user to get the code from their computer and then e= nter it into the device. In particular, it makes it easier to protect agai= nst a DOS attack targeted at the service-provider to request a large # of c= odes. That method also reduces the risk of a phishing/session-fixation typ= e attack. However we agree that some profile is needed for devices with no= user input. We also expect it will be easier to get these device vendors = to use a common industry technique, so we are fine with prioritizing our su= pport for this profile. Longer term the community could define a profile w= here the code is displayed on the computer. On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman <brent@facebook.com<mailto:b= rent@facebook.com>> wrote: Over the past couple days, Luke Shepard, David Recordon, and I have been br= ainstorming an OAuth profile for standardizing the flow that devices such a= s game consoles and entertainment centers use to hook up with services such= as Netflix and iTunes. The basic flow is that a device can gain authorizat= ion by directing the user to visit a URL on their computer and to enter a v= erification code copied from the device's screen. A draft spec is attached to this email. Any thoughts or feedback? Note: this is one of the many profiles going into the OAuth 2.0 draft that = David is writing (http://daveman692.livejournal.com/349384.html). -Brent _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <ATT00001..txt> --_000_710CC9A4422B424A8FC2AB190F41E87Ffacebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:= space; -webkit-line-break: after-white-space; ">Isn't there a similar atta= ck for the reverse protocol? The attacker would socially engineer the user = to give them the post-auth verification code displayed on the computer. Thi= s gives the attacker access to everything.<div><br></div><div>We could make= this more strict by having both a device code and verification code. That = is, have the user enter the device code into the computer, which would prod= uce a verification code that needs to be entered back into the device. But = this is susceptible to the same attack: after visiting the link sent b= y the attacker, and clicking "approve on a strange auth screen", the user w= ould have to send the verification code back to the attacker. This is sligh= tly better in that for an attack to be successful, the user has to communic= ate with the attacker twice instead of once.</div><div><br></div><div>I can= 't really think of a good way to eliminate the attack entirely, though.</di= v><div><br></div><div>-Brent</div><div><br></div><div><div><br><div><div>On= Apr 1, 2010, at 8:05 PM, Eric Sachs wrote:</div><br class=3D"Apple-interch= ange-newline"><blockquote type=3D"cite"><div>Here is the note I sent a few = weeks ago where we also noted the potential session fixation attack.  = However as we noted, we are still willing to start with this profile and la= ter work on where the user has to enter a code into the device.</div> <div><br></div><br><div class=3D"gmail_quote">---------- Forwarded message = ----------<br>From: <b class=3D"gmail_sendername">Eric Sachs</b> = <span dir=3D"ltr"><<a href=3D"mailto:esachs@google.com">esachs@google.co= m</a>></span><br> Date: Wed, Mar 17, 2010 at 5:45 PM<br>Subject: Re: [OAUTH-WG] Device Profil= e<br>To: Brent Goldman <<a href=3D"mailto:brent@facebook.com">brent@face= book.com</a>><br>Cc: "OAuth WG (<a href=3D"mailto:oauth@ietf.org">oauth@= ietf.org</a>)" <<a href=3D"mailto:oauth@ietf.org">oauth@ietf.org</a>>= <br> <br><br>Google has a similar requirement to move these types of devices to = OAuth/WRAP and away from our older "ClientLogin" protocol where the user is= prompted for their username/password.  The proposed profile looks fin= e, but we are a few weeks from being able to do specific work on it, so we = may have more feedback at that time.<div> <br></div><div>If the device can accept some user input, then there are som= e security advantages to requiring the user to get the code from their comp= uter and then enter it into the device.  In particular, it makes it ea= sier to protect against a DOS attack targeted at the service-provider to re= quest a large # of codes.  That method also reduces the risk of a phis= hing/session-fixation type attack.  However we agree that some profile= is needed for devices with no user input.  We also expect it will be = easier to get these device vendors to use a common industry technique, so w= e are fine with prioritizing our support for this profile.  Longer ter= m the community could define a profile where the code is displayed on = the computer.</div> <div><div></div><div class=3D"h5"><div><br></div><div>On Thu, Mar 11, 2010 = at 3:27 AM, Brent Goldman <span dir=3D"ltr"><<a href=3D"mailto:bren= t@facebook.com" target=3D"_blank">brent@facebook.com</a>></span> wr= ote:</div></div> </div><div><div><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_= quote" style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; mar= gin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 2= 04); border-left-style: solid; padding-left: 1ex; "> <div><div></div><div class=3D"h5">Over the past couple days, Luke Shepard, = David Recordon, and I have been brainstorming an OAuth profile for standard= izing the flow that devices such as game consoles and entertainment centers= use to hook up with services such as Netflix and iTunes. The basic flow is= that a device can gain authorization by directing the user to visit a URL = on their computer and to enter a verification code copied from the device's= screen.<br> <br>A draft spec is attached to this email. Any thoughts or feedback?<br><b= r>Note: this is one of the many profiles going into the OAuth 2.0 draft tha= t David is writing (<a href=3D"http://daveman692.livejournal.com/349384.htm= l" target=3D"_blank">http://daveman692.livejournal.com/349384.html</a>).<br= > <font color=3D"#888888"><br>-Brent<br><br><br></font><br></div></div><div c= lass=3D"im">_______________________________________________<br>OAuth mailin= g list<br><a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br><br></div></blockquote></= div><br></div></div></div></div> <span><ATT00001..txt></span></blockquote></div><br></div></div></body= ></html>= --_000_710CC9A4422B424A8FC2AB190F41E87Ffacebookcom_-- From lshepard@facebook.com Thu Apr 1 21:07:29 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681353A6A66 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.032 X-Spam-Level: X-Spam-Status: No, score=0.032 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc+VRq9MuOr8 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:07:28 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id A9A683A6916 for <oauth@ietf.org>; Thu, 1 Apr 2010 21:07:28 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.212]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o3247RCG030034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Apr 2010 21:07:27 -0700 Received: from sc-hub01.TheFacebook.com (192.168.18.104) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.682.1; Thu, 1 Apr 2010 21:07:31 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Thu, 1 Apr 2010 21:07:31 -0700 From: Luke Shepard <lshepard@facebook.com> To: Peter Saint-Andre <stpeter@stpeter.im> Date: Thu, 1 Apr 2010 21:07:30 -0700 Thread-Topic: [OAUTH-WG] Draft progress update Thread-Index: AcrSGgP0ozMUemMATp+Umrvbqdwnwg== Message-ID: <AFE1F948-AAE1-49C4-89E3-C03348317087@facebook.com> References: <191F411E00E19F4E943ECDB6D65C6085168FCFE8@TK5EX14MBXC115.redmond.corp.microsoft.com> <C7DA40B8.31B0F%eran@hueniverse.com> <o2x74caaad21004011321w7414318ai6f52ea84dea0862e@mail.gmail.com> <191F411E00E19F4E943ECDB6D65C60851690A880@TK5EX14MBXC115.redmond.corp.microsoft.com> <4BB54F92.1060201@stpeter.im> In-Reply-To: <4BB54F92.1060201@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AFE1F948AAE149C489E3C03348317087facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_05:2010-02-06, 2010-04-02, 2010-04-01 signatures=0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 04:07:29 -0000 --_000_AFE1F948AAE149C489E3C03348317087facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote: If that's true, then how does the Authorization Server know what scope is appropriate at the Protected Resource? Does inclusion of the scope parameter require a 1:1 mapping between AS and PR, or at least communication between AS and PR? My preferred way of handling this is to have the Protected Resource throw a= 403 Forbidden error, with an error message that specifies the scope needed= - e.g., "oauth_scope_required=3Dphoto_read". So an app that tries to access a protected resource should be able to progr= amatically take the scope in the error message and then construct an OAuth = authorization request to get that permission from the user. Even if the sco= pe is totally opaque, it should still be possible for a library to handle t= hem in this way. I believe David or Eran were thinking of writing this into the spec? --_000_AFE1F948AAE149C489E3C03348317087facebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:= space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 1, 20= 10, at 6:59 PM, Peter Saint-Andre wrote:</div><blockquote type=3D"cite"><di= v><font class=3D"Apple-style-span" color=3D"#000000"><br></font>If that's t= rue, then how does the Authorization Server know what scope<br>is appropria= te at the Protected Resource? Does inclusion of the scope<br>parameter requ= ire a 1:1 mapping between AS and PR, or at least<br>communication between A= S and PR?<br></div></blockquote></div><br><div>My preferred way of handling= this is to have the Protected Resource throw a 403 Forbidden error, with a= n error message that specifies the scope needed - e.g., "oauth_scope_requir= ed=3Dphoto_read".</div><div><br></div><div>So an app that tries to access a= protected resource should be able to programatically take the scope in the= error message and then construct an OAuth authorization request to get tha= t permission from the user. Even if the scope is totally opaque, it should = still be possible for a library to handle them in this way.</div><div><br><= /div><div>I believe David or Eran were thinking of writing this into the sp= ec?</div></body></html>= --_000_AFE1F948AAE149C489E3C03348317087facebookcom_-- From eran@hueniverse.com Thu Apr 1 21:08:07 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8E83A6A66 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.237 X-Spam-Level: X-Spam-Status: No, score=0.237 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmK+3yTgPdMM for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:08:06 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 92DB83A6916 for <oauth@ietf.org>; Thu, 1 Apr 2010 21:08:05 -0700 (PDT) Received: (qmail 11635 invoked from network); 2 Apr 2010 04:08:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 04:08:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Apr 2010 21:07:34 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Allen Tom <atom@yahoo-inc.com>, OAuth WG <oauth@ietf.org> Date: Thu, 1 Apr 2010 21:07:31 -0700 Thread-Topic: [OAUTH-WG] User Interface specs? Thread-Index: AcrR/joXiTwdAhjxhEyE3qdhMST83AAG8nTv Message-ID: <C7DABB93.31B64%eran@hueniverse.com> In-Reply-To: <C7DA8CF4.2980D%atom@yahoo-inc.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] User Interface specs? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 04:08:07 -0000 On 4/1/10 5:48 PM, "Allen Tom" <atom@yahoo-inc.com> wrote: > Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open a > popup window to the user=B9s Identity Provider for user to complete the > AuthZ/AuthN flow rather than taking the user away from the referring site= via > a full page redirect. >=20 > In the case where a popup window is used, it=B9s a very good idea to requ= ire > that that the browser=B9s address bar is displayed, and that an independe= nt > browser window is used, rather than an inline iframe. These requirements = are > needed to help prevent the user from being phished in the case where the = user > has to enter their password, and to ensure that the user=B9s consent was = not > forged via a clickjacking attack. >=20 > I believe that the Web Server Flow and the Web Client Flow will often tak= e > place within a popup window, so it would make sense to put into the core = spec > that popups should be independent browser windows with the address bar cl= early > displayed.=20 It certainly belongs in the security considerations section, but unless there is a way for the server to enforce it, a MUST directive is pointless. An attacker will obviously not comply... > Another missing feature in the core spec is support for multiple language= s. > Given that many Service Providers have a global userbase, client applicat= ions > will want to have a way to specify the language to be used on the auth sc= reen. > While the User Agent=B9s Accept-Language: HTTP header, as well as the use= r=B9s IP > address could be used as language hints, in practice clients will want th= e > ability to specify the language. >=20 > Is there consensus to get Popup Window requirements and language support = into > the OAuth2 core spec? Don't ask. Write a proposal and send to the list for each of these items (don't spend time on editorial or language). I'll add it to the spec and we'll see how well it fits in. At this stage we should be liberal in what w= e include so we can get the full picture. Then we will decide what to drop or spin-off. EHL From eran@hueniverse.com Thu Apr 1 21:16:25 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6577F3A6978 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.029 X-Spam-Level: X-Spam-Status: No, score=-1.029 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZy550VNgTbN for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:16:24 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id F3DAA3A68F0 for <oauth@ietf.org>; Thu, 1 Apr 2010 21:16:23 -0700 (PDT) Received: (qmail 15960 invoked from network); 2 Apr 2010 04:16:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 04:16:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Apr 2010 21:14:54 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Peter Saint-Andre <stpeter@stpeter.im>, Allen Tom <atom@yahoo-inc.com> Date: Thu, 1 Apr 2010 21:14:51 -0700 Thread-Topic: Scope (was: [OAUTH-WG] Draft progress update) Thread-Index: AcrSEnWh2oW20umIQnu0BUIaT0XzLgACJSLh Message-ID: <C7DABD4B.31B69%eran@hueniverse.com> In-Reply-To: <4BB560CD.9000004@stpeter.im> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: [OAUTH-WG] Scope (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 04:16:25 -0000 On 4/1/10 8:13 PM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote: > On 4/1/10 8:21 PM, Allen Tom wrote: >> The way we do this at Yahoo is that the developer must indicate what sco= pes >> they want to access when registering for a client_identifier/secret. >>=20 >> Although we've done it this way for several years, we've gotten plenty o= f >> feedback that client developers want the flexibility to specify the scop= es >> at user authorization time. >=20 > OK, so the scope is something that the [developer of a] Client > establishes beforehand with the Authorization Service. But that still > doesn't tell us what a scope is. Does someone have a definition? There isn't one - its service specific. The easy ones are: Duration List of protected resources, URI wildcard, or name of protected segment Read/write access or HTTP methods 3 years ago when we dropped the scope/token_attributes parameter from the spec we decided to bring it back when we have enough deployment experience. I strongly believe this rule still holds. It would be great if those with OAuth 1.0a deployments can share how they specify scope. EHL From eran@hueniverse.com Thu Apr 1 21:18:05 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8BB3A68F0 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.255 X-Spam-Level: X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vr19EuHHiBF7 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:18:04 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E12F33A6A5C for <oauth@ietf.org>; Thu, 1 Apr 2010 21:17:48 -0700 (PDT) Received: (qmail 18823 invoked from network); 2 Apr 2010 04:18:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 04:18:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Apr 2010 21:18:21 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Allen Tom <atom@yahoo-inc.com>, George Fletcher <gffletch@aol.com>, OAuth WG <oauth@ietf.org> Date: Thu, 1 Apr 2010 21:18:17 -0700 Thread-Topic: [OAUTH-WG] Re-scoping OAuth access tokens Thread-Index: AcrSErHvBM+iwfYNl0Kd54BZKQ2B0gACNMFL Message-ID: <C7DABE19.31B6C%eran@hueniverse.com> In-Reply-To: <C7DAAF4B.2985E%atom@yahoo-inc.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Re-scoping OAuth access tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 04:18:06 -0000 Only the access token (or refresh token) represents the access grant (which includes scope). To extend the scope of an already granted authorization, the client must use the access token or refresh token to do so. EHL On 4/1/10 8:15 PM, "Allen Tom" <atom@yahoo-inc.com> wrote: > Hi George - >=20 > I=B9m trying to figure out the re-scoping flow as well, to allow clients = to > progressively upgrade their scopes over time. >=20 > A potential pitfall is the scenario where multiple clients, share the sam= e > client_id and secret. For instance, a developer might have both a website= and > also an iphone app, and reuses the same client_id for both. >=20 > Should the Service Provider keep the scopes in sync for both apps? If the > refresh_token is not passed to the re-auth flow, the Service Provider wil= l > have a hard time determining which instance of the app is requesting the > upgraded scope. >=20 > Perhaps this doesn't matter, because it can be argued that although there > might be multiple instances of the same client_id, it=B9s all the same ap= p > anyway. So maybe it=B9s OK to upgrade the scopes for all instances of a g= iven > client_id. >=20 > Allen >=20 > On 3/26/10 10:57 AM, "George Fletcher" <gffletch@aol.com> wrote: >=20 >>=20 >>=20 >> It it sufficient for the client to just start a new web server flow and >> specify a new scope parameter that includes both "read buddylist" and "s= end >> IM"? The AS would then show Alice that she'd already approved "read >> buddylist" and just needed to approve "send IM"? This requires the clien= t to >> keep track of all scopes requested for a given user:protected_resource. >>=20 >> Another option might be to just allow the client to pass in the refresh_= token >> (as that likely has the scoped embedded/associated with it). In this cas= e the >> client could just ask for the new scope it wanted. >>=20 >> Thoughts? Anyone else have a need for dynamic re-scoping? >>=20 >> Thanks, >> George >>=20 >> P.S. This flow is deployedas part of the AOL IM APIs. However, when >> dynamically adding an authorization, we only show the user what their be= ing >> asked to consent to, not what they've done in the past. >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From atom@yahoo-inc.com Thu Apr 1 21:18:26 2010 Return-Path: <atom@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B213A69F0 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.896 X-Spam-Level: X-Spam-Status: No, score=-12.896 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVmnUXHMDULi for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 21:18:19 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 0C7CB3A6A7B for <oauth@ietf.org>; Thu, 1 Apr 2010 21:18:13 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o324IJDH040245; Thu, 1 Apr 2010 21:18:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:cc:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type:x-originalarrivaltime; b=rWr7J2LcgmknrM3vkyQ4fWbLT5UOl5ZJYFHRuqUCsAfY3HL5ssbJ/N+SA1r3c22c Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 21:18:19 -0700 Received: from 172.21.148.134 ([172.21.148.134]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Apr 2010 04:18:14 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 01 Apr 2010 21:18:11 -0700 From: Allen Tom <atom@yahoo-inc.com> To: Brent Goldman <brent@facebook.com>, Eric Sachs <esachs@google.com> Message-ID: <C7DABE13.29882%atom@yahoo-inc.com> Thread-Topic: [OAUTH-WG] Device Flow - Session Fixation? Thread-Index: AcrSGfW5TykVMTtMTuy6bQ4aCECZEAAAYunt In-Reply-To: <710CC9A4-422B-424A-8FC2-AB190F41E87F@facebook.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3353001492_7209047" X-OriginalArrivalTime: 02 Apr 2010 04:18:19.0809 (UTC) FILETIME=[86A06910:01CAD21B] Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Device Flow - Session Fixation? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 04:18:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3353001492_7209047 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Perhaps the best (usable) solution would be: 1. The approval screen must clearly indicate to the user that they should only be seeing that screen if they are trying to provision a device. The user should not have clicked on a link to get to the screen 2. The Auth server should also check for the presence of an HTTP Referrer. There should not be a referrer, since the user should not have clicked on anything to have landed on the screen 3. The Auth server must not enable =B3auto approval=B2 for the device flow. Meaning that the user must click through the approval screen, even if the user had previously authorized the same client_id previously Allen On 4/1/10 9:06 PM, "Brent Goldman" <brent@facebook.com> wrote: > Isn't there a similar attack for the reverse protocol? The attacker would > socially engineer the user to give them the post-auth verification code > displayed on the computer. This gives the attacker access to everything. >=20 > We could make this more strict by having both a device code and verificat= ion > code. That is, have the user enter the device code into the computer, whi= ch > would produce a verification code that needs to be entered back into the > device. But this is susceptible to the same attack: after visiting the li= nk > sent by the attacker, and clicking "approve on a strange auth screen", th= e > user would have to send the verification code back to the attacker. This = is > slightly better in that for an attack to be successful, the user has to > communicate with the attacker twice instead of once. >=20 > I can't really think of a good way to eliminate the attack entirely, thou= gh. >=20 > -Brent >=20 >=20 > On Apr 1, 2010, at 8:05 PM, Eric Sachs wrote: >=20 >> Here is the note I sent a few weeks ago where we also noted the potentia= l >> session fixation attack. However as we noted, we are still willing to s= tart >> with this profile and later work on where the user has to enter a code i= nto >> the device. >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: Eric Sachs <esachs@google.com> >> Date: Wed, Mar 17, 2010 at 5:45 PM >> Subject: Re: [OAUTH-WG] Device Profile >> To: Brent Goldman <brent@facebook.com> >> Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> >>=20 >>=20 >> Google has a similar requirement to move these types of devices to OAuth= /WRAP >> and away from our older "ClientLogin" protocol where the user is prompte= d for >> their username/password. The proposed profile looks fine, but we are a = few >> weeks from being able to do specific work on it, so we may have more fee= dback >> at that time. >>=20 >> If the device can accept some user input, then there are some security >> advantages to requiring the user to get the code from their computer and= then >> enter it into the device. In particular, it makes it easier to protect >> against a DOS attack targeted at the service-provider to request a large= # of >> codes. That method also reduces the risk of a phishing/session-fixation= type >> attack. However we agree that some profile is needed for devices with n= o >> user input. We also expect it will be easier to get these device vendor= s to >> use a common industry technique, so we are fine with prioritizing our su= pport >> for this profile. Longer term the community could define a profile wher= e the >> code is displayed on the computer. >>=20 >> On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman <brent@facebook.com> wrot= e: >>> Over the past couple days, Luke Shepard, David Recordon, and I have bee= n >>> brainstorming an OAuth profile for standardizing the flow that devices = such >>> as game consoles and entertainment centers use to hook up with services= such >>> as Netflix and iTunes. The basic flow is that a device can gain >>> authorization by directing the user to visit a URL on their computer an= d to >>> enter a verification code copied from the device's screen. >>>=20 >>> A draft spec is attached to this email. Any thoughts or feedback? >>>=20 >>> Note: this is one of the many profiles going into the OAuth 2.0 draft t= hat >>> David is writing (http://daveman692.livejournal.com/349384.html). >>>=20 >>> -Brent >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> <ATT00001..txt> >=20 >=20 --B_3353001492_7209047 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] Device Flow - Session Fixation? Perhaps the best (usable) solution would be:

  1. The approval screen must clearly indicate to the use= r that they should only be seeing that screen if they are trying to provisio= n a device. The user should not have clicked on a link to get to the screen
  2. The Auth server should also check for the presence of an= HTTP Referrer. There should not be a referrer, since the user should not ha= ve clicked on anything to have landed on the screen
  3. The Auth server must not enable “auto approvalR= 21; for the device flow. Meaning that the user must click through the approv= al screen, even if the user had previously authorized the same client_id pre= viously

Allen




On 4/1/10 9:06 PM, "Brent Goldman" <brent@facebook.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Isn't there a similar attack for the reverse pro= tocol? The attacker would socially engineer the user to give them the post-a= uth verification code displayed on the computer. This gives the attacker acc= ess to everything.

We could make this more strict by having both a device code and verificatio= n code. That is, have the user enter the device code into the computer, whic= h would produce a verification code that needs to be entered back into the d= evice. But this is susceptible to the same attack: after visiting the link s= ent by the attacker, and clicking "approve on a strange auth screen&quo= t;, the user would have to send the verification code back to the attacker. = This is slightly better in that for an attack to be successful, the user has= to communicate with the attacker twice instead of once.

I can't really think of a good way to eliminate the attack entirely, though= .

-Brent


On Apr 1, 2010, at 8:05 PM, Eric Sachs wrote:

<= SPAN STYLE=3D'font-size:11pt'>Here is the note I sent a few weeks ago where we= also noted the potential session fixation attack.  However as we noted= , we are still willing to start with this profile and later work on where th= e user has to enter a code into the device.


---------- Forwarded message ----------
From: Eric Sachs <esachs@google.com>
Date: Wed, Mar 17, 2010 at 5:45 PM
Subject: Re: [OAUTH-WG] Device Profile
To: Brent Goldman <brent@facebook.com&g= t;
Cc: "OAuth WG (oauth@ietf.org)" <= ;oauth@ietf.org>


Google has a similar requirement to move these types of devices to OAuth/WR= AP and away from our older "ClientLogin" protocol where the user i= s prompted for their username/password.  The proposed profile looks fin= e, but we are a few weeks from being able to do specific work on it, so we m= ay have more feedback at that time.

If the device can accept some user input, then there are some security adva= ntages to requiring the user to get the code from their computer and then en= ter it into the device.  In particular, it makes it easier to protect a= gainst a DOS attack targeted at the service-provider to request a large # of= codes.  That method also reduces the risk of a phishing/session-fixati= on type attack.  However we agree that some profile is needed for devic= es with no user input.  We also expect it will be easier to get these d= evice vendors to use a common industry technique, so we are fine with priori= tizing our support for this profile.  Longer term the community could d= efine a profile where the code is displayed on the computer.

On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman <brent@facebook.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Over the past couple days, Luke Shepard, David R= ecordon, and I have been brainstorming an OAuth profile for standardizing th= e flow that devices such as game consoles and entertainment centers use to h= ook up with services such as Netflix and iTunes. The basic flow is that a de= vice can gain authorization by directing the user to visit a URL on their co= mputer and to enter a verification code copied from the device's screen.

A draft spec is attached to this email. Any thoughts or feedback?

Note: this is one of the many profiles going into the OAuth 2.0 draft that = David is writing (ht= tp://daveman692.livejournal.com/349384.html).

-Brent



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

=
<ATT00001..txt>
=

--B_3353001492_7209047-- From eran@hueniverse.com Thu Apr 1 21:19:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85223A6938 for ; Thu, 1 Apr 2010 21:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.286 X-Spam-Level: X-Spam-Status: No, score=0.286 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4qYp7CDeWBK for ; Thu, 1 Apr 2010 21:19:41 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 61B243A6916 for ; Thu, 1 Apr 2010 21:19:34 -0700 (PDT) Received: (qmail 19105 invoked from network); 2 Apr 2010 04:20:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 04:20:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Apr 2010 21:20:07 -0700 From: Eran Hammer-Lahav To: Brent Goldman , Allen Tom Date: Thu, 1 Apr 2010 21:20:03 -0700 Thread-Topic: [OAUTH-WG] User Interface specs? Thread-Index: AcrSFDB31fHtGMoYQWKPrse8oENLoQAB5Oo0 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] User Interface specs? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 04:19:49 -0000 Can you write this as an actual proposal for the text? EHL On 4/1/10 8:25 PM, "Brent Goldman" wrote: > +1 on both >=20 > Regarding clickjacking: If we don't want the flows to be inlined in an if= rame, > specifying that the clients must show the server in a popup doesn't prote= ct > against malicious clients that choose to show it in an iframe anyway. So = I > think it also make sense to add to the core spec that servers should prot= ect > against this. The JavaScript is simple enough that perhaps the spec could= give > an example snippet that any OAuth server to use. E.g., if (top !=3D self = && > !isTopWindowSafe(top)) { > showBigassTransparentDivWithHighZIndex_or_redirectToErrorPage(); }. >=20 > -Brent >=20 >=20 > On Apr 1, 2010, at 5:48 PM, Allen Tom wrote: >=20 >> Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open = a >> popup window to the user=B9s Identity Provider for user to complete the >> AuthZ/AuthN flow rather than taking the user away from the referring sit= e via >> a full page redirect. >>=20 >> In the case where a popup window is used, it=B9s a very good idea to req= uire >> that that the browser=B9s address bar is displayed, and that an independ= ent >> browser window is used, rather than an inline iframe. These requirements= are >> needed to help prevent the user from being phished in the case where the= user >> has to enter their password, and to ensure that the user=B9s consent was= not >> forged via a clickjacking attack. >>=20 >> I believe that the Web Server Flow and the Web Client Flow will often ta= ke >> place within a popup window, so it would make sense to put into the core= spec >> that popups should be independent browser windows with the address bar >> clearly displayed. >>=20 >> Another missing feature in the core spec is support for multiple languag= es. >> Given that many Service Providers have a global userbase, client applica= tions >> will want to have a way to specify the language to be used on the auth >> screen. While the User Agent=B9s Accept-Language: HTTP header, as well a= s the >> user=B9s IP address could be used as language hints, in practice clients= will >> want the ability to specify the language. >>=20 >> Is there consensus to get Popup Window requirements and language support= into >> the OAuth2 core spec? >>=20 >> Allen >> >=20 >=20 From atom@yahoo-inc.com Thu Apr 1 21:23:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88533A6A5C for ; Thu, 1 Apr 2010 21:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.279 X-Spam-Level: X-Spam-Status: No, score=-14.279 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyFAqH0KpYJt for ; Thu, 1 Apr 2010 21:23:50 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id F13EF3A6938 for ; Thu, 1 Apr 2010 21:23:41 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o324MLZY046439; Thu, 1 Apr 2010 21:22:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type:x-originalarrivaltime; b=pmzaSuCJf16tocgV6E07j/4dYbyjdamqyeDoYg0PY3Tki92Yewa7nBh5BCOXoQzO Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 21:22:21 -0700 Received: from 172.21.148.134 ([172.21.148.134]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Apr 2010 04:21:55 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 01 Apr 2010 21:21:52 -0700 From: Allen Tom To: Luke Shepard , Peter Saint-Andre , "oauth@ietf.org" Message-ID: Thread-Topic: [OAUTH-WG] Draft progress update Thread-Index: AcrSGgP0ozMUemMATp+UmrvbqdwnwgAAgEm1 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3353001714_7234313" X-OriginalArrivalTime: 02 Apr 2010 04:22:21.0217 (UTC) FILETIME=[16845910:01CAD21C] Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 04:23:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3353001714_7234313 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit +1 How about if the Protected Resource returns an HTTP 302 redirect to the Auth URL? The scope information can be encoded in the URL. Allen On 4/1/10 9:07 PM, "Luke Shepard" wrote: > > On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote: >> >> If that's true, then how does the Authorization Server know what scope >> is appropriate at the Protected Resource? Does inclusion of the scope >> parameter require a 1:1 mapping between AS and PR, or at least >> communication between AS and PR? > > My preferred way of handling this is to have the Protected Resource throw a > 403 Forbidden error, with an error message that specifies the scope needed - > e.g., "oauth_scope_required=photo_read". > > So an app that tries to access a protected resource should be able to > programatically take the scope in the error message and then construct an > OAuth authorization request to get that permission from the user. Even if the > scope is totally opaque, it should still be possible for a library to handle > them in this way. > > I believe David or Eran were thinking of writing this into the spec? > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --B_3353001714_7234313 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] Draft progress update +1

How about if the Protected Resource returns an HTTP 302 redirect to the Aut= h URL? The scope information can be encoded in the URL.

Allen



On 4/1/10 9:07 PM, "Luke Shepard" <lshepard@facebook.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>
On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote:
<= SPAN STYLE=3D'font-size:11pt'>
If that's true, then how does the Authorization Server know what scope
is appropriate at the Protected Resource? Does inclusion of the scope
parameter require a 1:1 mapping between AS and PR, or at least
communication between AS and PR?
=
My preferred way of handling this is to have the Protected Resource throw a= 403 Forbidden error, with an error message that specifies the scope needed = - e.g., "oauth_scope_required=3Dphoto_read".

So an app that tries to access a protected resource should be able to progr= amatically take the scope in the error message and then construct an OAuth a= uthorization request to get that permission from the user. Even if the scope= is totally opaque, it should still be possible for a library to handle them= in this way.

I believe David or Eran were thinking of writing this into the spec?

___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth
--B_3353001714_7234313-- From eran@hueniverse.com Thu Apr 1 21:24:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06C693A695A for ; Thu, 1 Apr 2010 21:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ9jYiaKKcd7 for ; Thu, 1 Apr 2010 21:24:35 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7FD8D3A693F for ; Thu, 1 Apr 2010 21:24:35 -0700 (PDT) Received: (qmail 20207 invoked from network); 2 Apr 2010 04:25:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 04:25:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Apr 2010 21:25:08 -0700 From: Eran Hammer-Lahav To: Luke Shepard , Peter Saint-Andre Date: Thu, 1 Apr 2010 21:25:05 -0700 Thread-Topic: [OAUTH-WG] Scope (was: Draft progress update) Thread-Index: AcrSGgP0ozMUemMATp+UmrvbqdwnwgAAnQvG Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: [OAUTH-WG] Scope (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 04:24:37 -0000 On 4/1/10 9:07 PM, "Luke Shepard" wrote: >=20 > On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote: >>=20 >> If that's true, then how does the Authorization Server know what scope >> is appropriate at the Protected Resource? Does inclusion of the scope >> parameter require a 1:1 mapping between AS and PR, or at least >> communication between AS and PR? >=20 > My preferred way of handling this is to have the Protected Resource throw= a > 403 Forbidden error, with an error message that specifies the scope neede= d - > e.g., "oauth_scope_required=3Dphoto_read". >=20 > So an app that tries to access a protected resource should be able to > programatically take the scope in the error message and then construct an > OAuth authorization request to get that permission from the user. Even if= the > scope is totally opaque, it should still be possible for a library to han= dle > them in this way. >=20 > I believe David or Eran were thinking of writing this into the spec? >=20 How is this any better/different than plain old 401 with realm=3D'something= '. Why not have the client request a token capable of accessing the realm specified? Before we go and invent a new mechanism that has exactly the same limited capabilities, we should see if the existing one can be reused or improved upon. EHL From mscurtescu@google.com Thu Apr 1 21:45:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04E93A69E4 for ; Thu, 1 Apr 2010 21:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.455 X-Spam-Level: X-Spam-Status: No, score=-104.455 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpLv+yp-pX22 for ; Thu, 1 Apr 2010 21:45:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C45983A6832 for ; Thu, 1 Apr 2010 21:45:41 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [10.3.21.5]) by smtp-out.google.com with ESMTP id o324k7aj001459 for ; Thu, 1 Apr 2010 21:46:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270183568; bh=gq9CBXTeXk/U3fMn9pWQfNdWK4E=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=CtImb0MRugzehduUpe8Q4xYrDu4OG0PHYT4aRfee5MajMMKlrBt1Y3yb7rVl/UyKL kyVpD12BolpIXXtsN9IRQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=dJz4Uh0v89sl11aqwUw5PkeY1s2beNdOTmv+z1Uphs6Iq28KqNbIagCjoGLBugo0w vW1Fy1Xgj/YJ4EssIz0yQ== Received: from pzk10 (pzk10.prod.google.com [10.243.19.138]) by hpaq5.eem.corp.google.com with ESMTP id o324jwsb002161 for ; Fri, 2 Apr 2010 06:46:06 +0200 Received: by pzk10 with SMTP id 10so92093pzk.21 for ; Thu, 01 Apr 2010 21:45:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Thu, 1 Apr 2010 21:45:38 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Thu, 1 Apr 2010 21:45:38 -0700 Received: by 10.141.88.1 with SMTP id q1mr75132rvl.198.1270183558165; Thu, 01 Apr 2010 21:45:58 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 04:45:42 -0000 On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav wro= te: > But providing a half baked flow that is short enough to just replicate wh= ere > needed and cannot be fully implemented by generic libraries doesn=92t rea= lly > offer much. I think this is similar to the scope parameter argument, that libraries cannot really use an opaque scope. OAuth libraries will neither generate nor consume the assertions, the assertion itself can be opaque. The client application need= s to obtain an assertion somehow, this is out of scope, then pass it to a librar= y and the library can use it as is, pass it to the Authorization Server and deal with the response. Works perfectly fine IMO. Marius From brent@facebook.com Thu Apr 1 21:46:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B353A6830 for ; Thu, 1 Apr 2010 21:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.466 X-Spam-Level: X-Spam-Status: No, score=0.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAj7hw5YnttL for ; Thu, 1 Apr 2010 21:46:48 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 140533A679F for ; Thu, 1 Apr 2010 21:46:48 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o324kbo3030735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Apr 2010 21:46:39 -0700 Received: from sc-hub02.TheFacebook.com (192.168.18.105) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.682.1; Thu, 1 Apr 2010 21:46:53 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Thu, 1 Apr 2010 21:46:53 -0700 From: Brent Goldman To: Allen Tom Date: Thu, 1 Apr 2010 21:46:13 -0700 Thread-Topic: [OAUTH-WG] Device Flow - Session Fixation? Thread-Index: AcrSH4QXQPxhZoZ9Sc69WZSGRgyfQA== Message-ID: <44EA5F42-47BD-44C0-8C06-E382C98AF517@facebook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44EA5F4247BD44C08C06E382C98AF517facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_05:2010-02-06, 2010-04-02, 2010-04-01 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Device Flow - Session Fixation? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 04:46:49 -0000 --_000_44EA5F4247BD44C08C06E382C98AF517facebookcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Those 3 sound great. Add in clickjacking protection and I think we're set. -Brent On Apr 1, 2010, at 9:18 PM, Allen Tom wrote: Perhaps the best (usable) solution would be: 1. The approval screen must clearly indicate to the user that they should= only be seeing that screen if they are trying to provision a device. The u= ser should not have clicked on a link to get to the screen 2. The Auth server should also check for the presence of an HTTP Referrer= . There should not be a referrer, since the user should not have clicked on= anything to have landed on the screen 3. The Auth server must not enable =93auto approval=94 for the device flo= w. Meaning that the user must click through the approval screen, even if th= e user had previously authorized the same client_id previously Allen On 4/1/10 9:06 PM, "Brent Goldman" > wrote: Isn't there a similar attack for the reverse protocol? The attacker would s= ocially engineer the user to give them the post-auth verification code disp= layed on the computer. This gives the attacker access to everything. We could make this more strict by having both a device code and verificatio= n code. That is, have the user enter the device code into the computer, whi= ch would produce a verification code that needs to be entered back into the= device. But this is susceptible to the same attack: after visiting the lin= k sent by the attacker, and clicking "approve on a strange auth screen", th= e user would have to send the verification code back to the attacker. This = is slightly better in that for an attack to be successful, the user has to = communicate with the attacker twice instead of once. I can't really think of a good way to eliminate the attack entirely, though= . -Brent On Apr 1, 2010, at 8:05 PM, Eric Sachs wrote: Here is the note I sent a few weeks ago where we also noted the potential s= ession fixation attack. However as we noted, we are still willing to start= with this profile and later work on where the user has to enter a code int= o the device. ---------- Forwarded message ---------- From: Eric Sachs > Date: Wed, Mar 17, 2010 at 5:45 PM Subject: Re: [OAUTH-WG] Device Profile To: Brent Goldman > Cc: "OAuth WG (oauth@ietf.org)" > Google has a similar requirement to move these types of devices to OAuth/WR= AP and away from our older "ClientLogin" protocol where the user is prompte= d for their username/password. The proposed profile looks fine, but we are= a few weeks from being able to do specific work on it, so we may have more= feedback at that time. If the device can accept some user input, then there are some security adva= ntages to requiring the user to get the code from their computer and then e= nter it into the device. In particular, it makes it easier to protect agai= nst a DOS attack targeted at the service-provider to request a large # of c= odes. That method also reduces the risk of a phishing/session-fixation typ= e attack. However we agree that some profile is needed for devices with no= user input. We also expect it will be easier to get these device vendors = to use a common industry technique, so we are fine with prioritizing our su= pport for this profile. Longer term the community could define a profile w= here the code is displayed on the computer. On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman > wrote: Over the past couple days, Luke Shepard, David Recordon, and I have been br= ainstorming an OAuth profile for standardizing the flow that devices such a= s game consoles and entertainment centers use to hook up with services such= as Netflix and iTunes. The basic flow is that a device can gain authorizat= ion by directing the user to visit a URL on their computer and to enter a v= erification code copied from the device's screen. A draft spec is attached to this email. Any thoughts or feedback? Note: this is one of the many profiles going into the OAuth 2.0 draft that = David is writing (http://daveman692.livejournal.com/349384.html). -Brent _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_44EA5F4247BD44C08C06E382C98AF517facebookcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Those 3 sound great. Add i= n clickjacking protection and I think we're set.

-Brent<= /div>


On Apr 1, 2010, at 9:18 PM, All= en Tom wrote:

Perhaps the best (usable) solution would be:

  1. The approval screen must clearly indicate to th= e user that they should only be seeing that screen if they are trying to pr= ovision a device. The user should not have clicked on a link to get to the = screen
  2. The Auth server should also check for the pres= ence of an HTTP Referrer. There should not be a referrer, since the user sh= ould not have clicked on anything to have landed on the screen
  3. The Auth server must not enable =93auto approv= al=94 for the device flow. Meaning that the user must click through the app= roval screen, even if the user had previously authorized the same client_id= previously
<= span style=3D"font-size:11pt">
Allen




On 4/1/10 9:06 PM, "Brent Goldman" <brent@facebook.com> wrote:

Isn't there a similar attack = for the reverse protocol? The attacker would socially engineer the user to = give them the post-auth verification code displayed on the computer. This g= ives the attacker access to everything.

We could make this more strict by having both a device code and verificatio= n code. That is, have the user enter the device code into the computer, whi= ch would produce a verification code that needs to be entered back into the= device. But this is susceptible to the same attack: after visiting the lin= k sent by the attacker, and clicking "approve on a strange auth screen", th= e user would have to send the verification code back to the attacker. This = is slightly better in that for an attack to be successful, the user has to = communicate with the attacker twice instead of once.

I can't really think of a good way to eliminate the attack entirely, though= .

-Brent


On Apr 1, 2010, at 8:05 PM, Eric Sachs wrote:

Here is the note I sent a few= weeks ago where we also noted the potential session fixation attack.  = ;However as we noted, we are still willing to start with this profile and l= ater work on where the user has to enter a code into the device.


---------- Forwarded message ----------
From: Eric Sachs <esachs= @google.com>
Date: Wed, Mar 17, 2010 at 5:45 PM
Subject: Re: [OAUTH-WG] Device Profile
To: Brent Goldman <brent@faceb= ook.com>
Cc: "OAuth WG (oauth@ietf.org)" = <oauth@ietf.org>


Google has a similar requirement to move these types of devices to OAuth/WR= AP and away from our older "ClientLogin" protocol where the user is prompte= d for their username/password.  The proposed profile looks fine, but w= e are a few weeks from being able to do specific work on it, so we may have= more feedback at that time.

If the device can accept some user input, then there are some security adva= ntages to requiring the user to get the code from their computer and then e= nter it into the device.  In particular, it makes it easier to protect= against a DOS attack targeted at the service-provider to request a large #= of codes.  That method also reduces the risk of a phishing/session-fi= xation type attack.  However we agree that some profile is needed for = devices with no user input.  We also expect it will be easier to get t= hese device vendors to use a common industry technique, so we are fine with= prioritizing our support for this profile.  Longer term the community= could define a profile where the code is displayed on the computer.

On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman <brent@facebook.com> wrote:
Over the past couple days, Lu= ke Shepard, David Recordon, and I have been brainstorming an OAuth profile = for standardizing the flow that devices such as game consoles and entertain= ment centers use to hook up with services such as Netflix and iTunes. The b= asic flow is that a device can gain authorization by directing the user to = visit a URL on their computer and to enter a verification code copied from = the device's screen.

A draft spec is attached to this email. Any thoughts or feedback?

Note: this is one of the many profiles going into the OAuth 2.0 draft that = David is writing (http://daveman692.livejournal.com/349384.html).

-Brent



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


<ATT00001..txt>



= --_000_44EA5F4247BD44C08C06E382C98AF517facebookcom_-- From lshepard@facebook.com Thu Apr 1 21:47:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6A73A6A64 for ; Thu, 1 Apr 2010 21:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVkuvgPi5rhx for ; Thu, 1 Apr 2010 21:47:37 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 813103A6A71 for ; Thu, 1 Apr 2010 21:47:37 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.212]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o324lam0031428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Apr 2010 21:47:36 -0700 Received: from sc-hub02.TheFacebook.com (192.168.18.105) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.682.1; Thu, 1 Apr 2010 21:48:09 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Thu, 1 Apr 2010 21:48:09 -0700 From: Luke Shepard To: Eran Hammer-Lahav Date: Thu, 1 Apr 2010 21:48:06 -0700 Thread-Topic: [OAUTH-WG] Scope (was: Draft progress update) Thread-Index: AcrSH7EJ1moTSgeVRaCL37K5LVTi1Q== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_05:2010-02-06, 2010-04-02, 2010-04-01 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 04:47:38 -0000 Sure, I don't care about the exact mechanism - although "realm" and "scope"= don't seem equivalent concepts. Allen - I don't think a redirect is what we want, since the Protected Resou= rce is typically server-to-server, or if done in a browser then it's not in= a user-visible screen. On Apr 1, 2010, at 9:25 PM, Eran Hammer-Lahav wrote: >=20 >=20 >=20 > On 4/1/10 9:07 PM, "Luke Shepard" wrote: >=20 >>=20 >> On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote: >>>=20 >>> If that's true, then how does the Authorization Server know what scope >>> is appropriate at the Protected Resource? Does inclusion of the scope >>> parameter require a 1:1 mapping between AS and PR, or at least >>> communication between AS and PR? >>=20 >> My preferred way of handling this is to have the Protected Resource thro= w a >> 403 Forbidden error, with an error message that specifies the scope need= ed - >> e.g., "oauth_scope_required=3Dphoto_read". >>=20 >> So an app that tries to access a protected resource should be able to >> programatically take the scope in the error message and then construct a= n >> OAuth authorization request to get that permission from the user. Even i= f the >> scope is totally opaque, it should still be possible for a library to ha= ndle >> them in this way. >>=20 >> I believe David or Eran were thinking of writing this into the spec? >>=20 >=20 > How is this any better/different than plain old 401 with realm=3D'somethi= ng'. > Why not have the client request a token capable of accessing the realm > specified? >=20 > Before we go and invent a new mechanism that has exactly the same limited > capabilities, we should see if the existing one can be reused or improved > upon. >=20 > EHL >=20 From eran@hueniverse.com Thu Apr 1 21:55:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B323A6A49 for ; Thu, 1 Apr 2010 21:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjI58MG1lec4 for ; Thu, 1 Apr 2010 21:55:44 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 84BA53A6832 for ; Thu, 1 Apr 2010 21:55:44 -0700 (PDT) Received: (qmail 3662 invoked from network); 2 Apr 2010 04:56:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 04:56:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Apr 2010 21:54:09 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Thu, 1 Apr 2010 21:54:06 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrSH2X4k8c2eoOeTLOKlQtgNp0QaAAAR/ja Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7DAC67E31B7Ceranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 04:55:48 -0000 --_000_C7DAC67E31B7Ceranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the assertion format? Binary? XML? Should the library encode it? Is= the application using the library responsible for providing it with a URI-= safe string? EHL On 4/1/10 9:45 PM, "Marius Scurtescu" wrote: On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav wro= te: > But providing a half baked flow that is short enough to just replicate wh= ere > needed and cannot be fully implemented by generic libraries doesn't reall= y > offer much. I think this is similar to the scope parameter argument, that libraries cannot really use an opaque scope. OAuth libraries will neither generate nor consume the assertions, the assertion itself can be opaque. The client application need= s to obtain an assertion somehow, this is out of scope, then pass it to a librar= y and the library can use it as is, pass it to the Authorization Server and deal with the response. Works perfectly fine IMO. Marius --_000_C7DAC67E31B7Ceranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>What is the assertion format? Binary? XML? Should the library encode = it? Is the application using the library responsible for providing it with = a URI-safe string?<BR> <BR> EHL<BR> <BR> <BR> On 4/1/10 9:45 PM, "Marius Scurtescu" <<a href=3D"mscurtescu@g= oogle.com">mscurtescu@google.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer= -Lahav <<a href=3D"eran@hueniverse.com">eran@hueniverse.com</a>> wrot= e:<BR> > But providing a half baked flow that is short enough to just replicate= where<BR> > needed and cannot be fully implemented by generic libraries doesn̵= 7;t really<BR> > offer much.<BR> <BR> I think this is similar to the scope parameter argument, that<BR> libraries cannot really<BR> use an opaque scope. OAuth libraries will neither generate nor consume the<= BR> assertions, the assertion itself can be opaque. The client application need= s to<BR> obtain an assertion somehow, this is out of scope, then pass it to a librar= y and<BR> the library can use it as is, pass it to the Authorization Server and<BR> deal with the<BR> response. Works perfectly fine IMO.<BR> <BR> Marius<BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C7DAC67E31B7Ceranhueniversecom_-- From mscurtescu@google.com Thu Apr 1 22:00:34 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2E03A67F0 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 22:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.494 X-Spam-Level: X-Spam-Status: No, score=-104.494 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qGfxf1A3oha for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 22:00:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CBBFF3A6801 for <oauth@ietf.org>; Thu, 1 Apr 2010 22:00:32 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id o32515S4019079 for <oauth@ietf.org>; Thu, 1 Apr 2010 22:01:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270184465; bh=Wem2DcaTlfULdSfHr/ht71Aqlts=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=FVKOZKP7Vk/g9QVETuZoHSxVUraloayCLTseKx7iwbpGKOVXtPc03aWjXlAnBVZV9 /xTdLzuS4h1/brib69WWA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=Zbq9ji+sWHFE8+eoRMpzITylTlsT7hXEtNPagpJ5b+/UTbbodUKuRRizHDBtoq4jv rFLVymoGXeW+lSaR+Y64Q== Received: from pwj10 (pwj10.prod.google.com [10.241.219.74]) by kpbe13.cbf.corp.google.com with ESMTP id o325140X011810 for <oauth@ietf.org>; Fri, 2 Apr 2010 00:01:04 -0500 Received: by pwj10 with SMTP id 10so1599747pwj.12 for <oauth@ietf.org>; Thu, 01 Apr 2010 22:01:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Thu, 1 Apr 2010 22:00:44 -0700 (PDT) In-Reply-To: <C7DAC67E.31B7C%eran@hueniverse.com> References: <l2i74caaad21004012145r7f789f8av76df4f14a2420139@mail.gmail.com> <C7DAC67E.31B7C%eran@hueniverse.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Thu, 1 Apr 2010 22:00:44 -0700 Received: by 10.140.248.9 with SMTP id v9mr1281656rvh.101.1270184464138; Thu, 01 Apr 2010 22:01:04 -0700 (PDT) Message-ID: <p2k74caaad21004012200x8a118a1fq18096442f3cc6042@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 05:00:34 -0000 On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > What is the assertion format? Binary? XML? Should the library encode it? Is > the application using the library responsible for providing it with a > URI-safe string? UTF-8 string I guess, the rest should not matter. Marius From eran@hueniverse.com Thu Apr 1 22:09:52 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129773A6882 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 22:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.015 X-Spam-Level: X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URuwFsml1DLP for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 22:09:48 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A5BE93A6855 for <oauth@ietf.org>; Thu, 1 Apr 2010 22:09:47 -0700 (PDT) Received: (qmail 10690 invoked from network); 2 Apr 2010 05:10:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 05:10:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Apr 2010 22:10:19 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Thu, 1 Apr 2010 22:10:16 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrSIYEyWUX95UJLT66OKhyAoQfoNwAAUbQ4 Message-ID: <C7DACA48.31B81%eran@hueniverse.com> In-Reply-To: <p2k74caaad21004012200x8a118a1fq18096442f3cc6042@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7DACA4831B81eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 05:09:52 -0000 --_000_C7DACA4831B81eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The current draft allows the following characters: value-char =3D ALPHA / DIGIT / "-" / "." / "_" / "~" / "%" Which means a utf-8 string will need to be encoded somehow. Should it be pe= rcent-encoded? Something else? EHL On 4/1/10 10:00 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te: > What is the assertion format? Binary? XML? Should the library encode it? = Is > the application using the library responsible for providing it with a > URI-safe string? UTF-8 string I guess, the rest should not matter. Marius --_000_C7DACA4831B81eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>The current draft allows the following characters:<BR> <BR>   value-char  =3D ALPHA / DIGIT / "-" / ".&qu= ot; / "_" / "~" / "%"<BR> <BR> Which means a utf-8 string will need to be encoded somehow. Should it be pe= rcent-encoded? Something else?<BR> <BR> EHL<BR> <BR> <BR> On 4/1/10 10:00 PM, "Marius Scurtescu" <<a href=3D"mscurtescu@= google.com">mscurtescu@google.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer= -Lahav <<a href=3D"eran@hueniverse.com">eran@hueniverse.com</a>> wrot= e:<BR> > What is the assertion format? Binary? XML? Should the library encode i= t? Is<BR> > the application using the library responsible for providing it with a<= BR> > URI-safe string?<BR> <BR> UTF-8 string I guess, the rest should not matter.<BR> <BR> Marius<BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C7DACA4831B81eranhueniversecom_-- From recordond@gmail.com Thu Apr 1 22:46:39 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428293A69DC for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 22:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcsU3d96Q903 for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 22:46:08 -0700 (PDT) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by core3.amsl.com (Postfix) with ESMTP id 0F3C53A686C for <oauth@ietf.org>; Thu, 1 Apr 2010 22:45:53 -0700 (PDT) Received: by gxk20 with SMTP id 20so1343100gxk.12 for <oauth@ietf.org>; Thu, 01 Apr 2010 22:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=jKGU1Z1FRwZosJaHnYUeQtULlmKUECHugP+u8AuYhE0=; b=aYXkQrKH1tc85OKIAj//lWW551tZj148/Edz8nCXgGD9oabKLQ7Kq4x0igdRVlzgqd R7AkeC7pPT13T9fcahkP2hrs7FtVI1mKLW2L6i6k2HLQMBWtVJUiS+xepmkTZwKUrGBd I2CatON+U92hnjtcfE9O7MkRrIo8/pwHRLfnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tcXq1HzL/GNkJqqlTfLK7M6Uy8T6kyZo/TmZlnP75KLozrZ5EYf8FLA4YgMLm60iwy T4f4qRacgGHk4HdBsCcEZH6NWkN7nQq9WkddywZqcyPcYIuW9oAfxpqM2ivBOmmbPJSC mXiBGa5MrVvg29dn5kqJ5DmHeuh44d3PqDnxo= MIME-Version: 1.0 Received: by 10.231.183.18 with HTTP; Thu, 1 Apr 2010 22:46:23 -0700 (PDT) In-Reply-To: <C7DABEF0.29886%atom@yahoo-inc.com> References: <AFE1F948-AAE1-49C4-89E3-C03348317087@facebook.com> <C7DABEF0.29886%atom@yahoo-inc.com> Date: Thu, 1 Apr 2010 22:46:23 -0700 Received: by 10.150.160.8 with SMTP id i8mr2333423ybe.141.1270187183585; Thu, 01 Apr 2010 22:46:23 -0700 (PDT) Message-ID: <s2nfd6741651004012246mbd515142t2d804b978085800b@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Allen Tom <atom@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 05:46:39 -0000 401 seems more semantically correct, but I'm sure Eran knows the true answer. :) +1 to this idea though. Helps client dynamically authorize users if it turns out they didn't ask for the right scope. On Thu, Apr 1, 2010 at 9:21 PM, Allen Tom <atom@yahoo-inc.com> wrote: > +1 > > How about if the Protected Resource returns an HTTP 302 redirect to the Auth > URL? The scope information can be encoded in the URL. > > Allen > > > > On 4/1/10 9:07 PM, "Luke Shepard" <lshepard@facebook.com> wrote: > > > On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote: > > If that's true, then how does the Authorization Server know what scope > is appropriate at the Protected Resource? Does inclusion of the scope > parameter require a 1:1 mapping between AS and PR, or at least > communication between AS and PR? > > My preferred way of handling this is to have the Protected Resource throw a > 403 Forbidden error, with an error message that specifies the scope needed - > e.g., "oauth_scope_required=photo_read". > > So an app that tries to access a protected resource should be able to > programatically take the scope in the error message and then construct an > OAuth authorization request to get that permission from the user. Even if > the scope is totally opaque, it should still be possible for a library to > handle them in this way. > > I believe David or Eran were thinking of writing this into the spec? > > ________________________________ > _______________________________________________ > OAuth mailing 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 brent@facebook.com Thu Apr 1 23:01:30 2010 Return-Path: <brent@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E0E3A688E for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 23:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.465 X-Spam-Level: X-Spam-Status: No, score=0.465 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNxnuevWUKlY for <oauth@core3.amsl.com>; Thu, 1 Apr 2010 23:01:28 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id A381B3A6880 for <oauth@ietf.org>; Thu, 1 Apr 2010 23:01:28 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.212]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o3261M5Z028434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Apr 2010 23:01:22 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.682.1; Thu, 1 Apr 2010 23:01:54 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Thu, 1 Apr 2010 23:01:54 -0700 From: Brent Goldman <brent@facebook.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Date: Thu, 1 Apr 2010 23:01:13 -0700 Thread-Topic: [OAUTH-WG] User Interface specs? Thread-Index: AcrSKf6gW+/vSkh2T2ORROkWyq6puw== Message-ID: <73848F08-3CC3-4638-BD70-63A33123F99C@facebook.com> References: <C7DABE83.31B6F%eran@hueniverse.com> In-Reply-To: <C7DABE83.31B6F%eran@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_05:2010-02-06, 2010-04-02, 2010-04-01 signatures=0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] User Interface specs? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 06:01:30 -0000 7.1.1. Browser-Based Attacks This section describes common attacks against OAuth flows involving web bro= wsers, as well as protections against these attacks. The flows involving we= b browsers are the Web Callback Flow, the Web Client Flow, and the Device F= low. 7.1.1.1 Phishing Phishing is the process of a malicious website attempting to acquire sensit= ive information such as usernames and passwords by masquerading as a trustw= orthy website. With regards to OAuth, an attacker could build a malicious w= ebsite embedding a masquerade version of an OAuth Authorization Server to o= btain the user's credentials. The attacker could then use these credentials= to authorize any application on the user's behalf, essentially stealing th= e user's identity. For a phishing attack to be successful, the user must voluntarily enter the= ir credentials into the masqueraded site. It is difficult for a user to dis= tinguish between a trustworthy site and a masqueraded version if the user c= annot see the URL bar. 7.1.1.2. Clickjacking Clickjacking is the process of a malicious website tricking the user into p= erforming undesired actions (such as authorizing an OAuth flow), without th= e user realizing this is happening, by having the user click a button that = appears to perform an innocuous function. In more detail, a malicious site = loads the target site in a transparent iframe overlaid on top of a set of d= ummy buttons which are carefully constructed to be placed directly under im= portant buttons on the target site. When a user clicks a visible button, th= ey are actually clicking a button (such as an "Authorize" button) on the hi= dden page. 7.1.1.3. Protection Both phishing and clickjacking attack vectors can be avoided by disallowing= iframes. OAuth clients SHOULD redirect to to the Authorization Server or show the Au= thorization Server in a popup window, and SHOULD NOT display the Authorizat= ion Server in an iframe. In the case that a popup window is used, the popup= window MUST display the browser's address bar. Since malicious clients will not comply with these recommendations, OAuth A= uthorization Servers SHOULD also enforce protection. It is not possible for= the server to determine if a browser's address bar is displayed or not, bu= t it is possible for the server to protect against being displayed in an if= rame. In newer versions of Internet Explorer, Safari, and Chrome, a page is preve= nted from being iframed if the HTTP header X-FRAME-OPTION is set to DENY. I= f this header is set to SAMEORIGIN, only sites with a different origin are = blocked from iframing the site. For older browsers not supporting X-FRAME-OPTION, a page can be prevented f= rom being iframed using JavaScript. To determine if the site is being ifram= ed, a site just needs to check that top !=3D self. If this condition is tru= e (and if the top URL is not trustworthy -- e.g., it's not owned by the sam= e domain), the JavaScript should redirect to an error page explaining that = the site should not be iframed. Other options include opening the same page= in a popup window, or showing a large DIV with high z-index covering the e= ntire screen, preventing any clicks from reaching the buttons underneath. For browsers not supporting either X-FRAME-OPTION or JavaScript, a page can= not be prevented from being displayed in an iframe. On Apr 1, 2010, at 9:20 PM, Eran Hammer-Lahav wrote: > Can you write this as an actual proposal for the text? >=20 > EHL >=20 >=20 > On 4/1/10 8:25 PM, "Brent Goldman" <brent@facebook.com> wrote: >=20 >> +1 on both >>=20 >> Regarding clickjacking: If we don't want the flows to be inlined in an i= frame, >> specifying that the clients must show the server in a popup doesn't prot= ect >> against malicious clients that choose to show it in an iframe anyway. So= I >> think it also make sense to add to the core spec that servers should pro= tect >> against this. The JavaScript is simple enough that perhaps the spec coul= d give >> an example snippet that any OAuth server to use. E.g., if (top !=3D self= && >> !isTopWindowSafe(top)) { >> showBigassTransparentDivWithHighZIndex_or_redirectToErrorPage(); }. >>=20 >> -Brent >>=20 >>=20 >> On Apr 1, 2010, at 5:48 PM, Allen Tom wrote: >>=20 >>> Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open= a >>> popup window to the user=B9s Identity Provider for user to complete the >>> AuthZ/AuthN flow rather than taking the user away from the referring si= te via >>> a full page redirect. >>>=20 >>> In the case where a popup window is used, it=B9s a very good idea to re= quire >>> that that the browser=B9s address bar is displayed, and that an indepen= dent >>> browser window is used, rather than an inline iframe. These requirement= s are >>> needed to help prevent the user from being phished in the case where th= e user >>> has to enter their password, and to ensure that the user=B9s consent wa= s not >>> forged via a clickjacking attack. >>>=20 >>> I believe that the Web Server Flow and the Web Client Flow will often t= ake >>> place within a popup window, so it would make sense to put into the cor= e spec >>> that popups should be independent browser windows with the address bar >>> clearly displayed. >>>=20 >>> Another missing feature in the core spec is support for multiple langua= ges. >>> Given that many Service Providers have a global userbase, client applic= ations >>> will want to have a way to specify the language to be used on the auth >>> screen. While the User Agent=B9s Accept-Language: HTTP header, as well = as the >>> user=B9s IP address could be used as language hints, in practice client= s will >>> want the ability to specify the language. >>>=20 >>> Is there consensus to get Popup Window requirements and language suppor= t into >>> the OAuth2 core spec? >>>=20 >>> Allen >>> <ATT00001..txt> >>=20 >>=20 >=20 From torsten@lodderstedt.net Fri Apr 2 02:18:06 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646F53A6949 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 02:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.726 X-Spam-Level: X-Spam-Status: No, score=0.726 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZNZbxdWvxWs for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 02:18:00 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id B10E53A67A6 for <oauth@ietf.org>; Fri, 2 Apr 2010 02:17:59 -0700 (PDT) Received: from p4fff05ca.dip.t-dialin.net ([79.255.5.202] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1Nxd1J-0003vh-2H; Fri, 02 Apr 2010 11:18:29 +0200 Message-ID: <4BB5B661.7090407@lodderstedt.net> Date: Fri, 02 Apr 2010 11:18:25 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Allen Tom <atom@yahoo-inc.com> References: <C7DAA2C7.2984A%atom@yahoo-inc.com> In-Reply-To: <C7DAA2C7.2984A%atom@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 09:18:07 -0000 The OAuth implementation at Deutsche Telekom uses a non-standard parameter "serviceId" to identity the protected resource the client wants to access. The client passes such an id as parameter when requesting a token. The authorization server knows all services it issues tokens for. The service id is used to - constucts the screen for user consent - create a token with the content required at that particular service. I would vote for a similar parameter as part of the standard. So far, I have seen the "scope" parameter that way. regards, Torsten. > The way we do this at Yahoo is that the developer must indicate what scopes > they want to access when registering for a client_identifier/secret. > > Although we've done it this way for several years, we've gotten plenty of > feedback that client developers want the flexibility to specify the scopes > at user authorization time. > > Allen > > > On 4/1/10 6:59 PM, "Peter Saint-Andre"<stpeter@stpeter.im> wrote: > > >> >> If that's true, then how does the Authorization Server know what scope >> is appropriate at the Protected Resource? Does inclusion of the scope >> parameter require a 1:1 mapping between AS and PR, or at least >> communication between AS and PR? >> >> Peter >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From cmortimore@salesforce.com Fri Apr 2 07:31:21 2010 Return-Path: <cmortimore@salesforce.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63AE03A679C for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 07:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.985 X-Spam-Level: X-Spam-Status: No, score=-4.985 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29XEYVuNn60T for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 07:31:20 -0700 (PDT) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by core3.amsl.com (Postfix) with SMTP id 4C35C3A6784 for <oauth@ietf.org>; Fri, 2 Apr 2010 07:31:20 -0700 (PDT) Received: from source ([204.14.239.238]) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKS7X/2lNUdVXgsXbiNujd1jLaUYCIpyG3@postini.com; Fri, 02 Apr 2010 07:31:54 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Fri, 2 Apr 2010 07:31:53 -0700 From: Chuck Mortimore <cmortimore@salesforce.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, Marius Scurtescu <mscurtescu@google.com> Date: Fri, 2 Apr 2010 07:31:21 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrSIYEyWUX95UJLT66OKhyAoQfoNwAAUbQ4ABOYbWA= Message-ID: <77AEC44D4DA08A46ADAA723286626BC12E2D43FAB9@EXSFM-MB01.internal.salesforce.com> References: <p2k74caaad21004012200x8a118a1fq18096442f3cc6042@mail.gmail.com>, <C7DACA48.31B81%eran@hueniverse.com> In-Reply-To: <C7DACA48.31B81%eran@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 14:31:21 -0000 For SAML it should be Base64 encoded. -cmort ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Thursday, April 01, 2010 10:10 PM To: Marius Scurtescu Cc: OAuth WG Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) The current draft allows the following characters: value-char =3D ALPHA / DIGIT / "-" / "." / "_" / "~" / "%" Which means a utf-8 string will need to be encoded somehow. Should it be pe= rcent-encoded? Something else? EHL On 4/1/10 10:00 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te: > What is the assertion format? Binary? XML? Should the library encode it? = Is > the application using the library responsible for providing it with a > URI-safe string? UTF-8 string I guess, the rest should not matter. Marius From cmortimore@salesforce.com Fri Apr 2 07:44:33 2010 Return-Path: <cmortimore@salesforce.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567A23A68EE for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 07:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[AWL=-1.853, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FRT_PROFILE1=2.555, FRT_PROFILE2=1.981, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIBDE9EZMLVN for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 07:44:32 -0700 (PDT) Received: from exprod8og112.obsmtp.com (exprod8og112.obsmtp.com [64.18.3.24]) by core3.amsl.com (Postfix) with SMTP id 426123A67F2 for <oauth@ietf.org>; Fri, 2 Apr 2010 07:44:32 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob112.postini.com ([64.18.7.12]) with SMTP ID DSNKS7YC8klYtMG1AQ0F6LJJtI3QJuBfdbDz@postini.com; Fri, 02 Apr 2010 07:45:06 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Fri, 2 Apr 2010 07:45:05 -0700 From: Chuck Mortimore <cmortimore@salesforce.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, Marius Scurtescu <mscurtescu@google.com> Date: Fri, 2 Apr 2010 07:45:05 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrSH2X4k8c2eoOeTLOKlQtgNp0QaAAAR/jaABQwORM= Message-ID: <77AEC44D4DA08A46ADAA723286626BC12E2D43FABA@EXSFM-MB01.internal.salesforce.com> References: <l2i74caaad21004012145r7f789f8av76df4f14a2420139@mail.gmail.com>, <C7DAC67E.31B7C%eran@hueniverse.com> In-Reply-To: <C7DAC67E.31B7C%eran@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 14:44:33 -0000 The format would be specified by a profilie. For instance, a SAML profil= e might define: assertion_format=3Durn:oasis:names:tc:SAML:2.0:cm:bearer assertion=3D{SAML 2 bearer assertion, optionally wrapped in a SAML response= , Signature must cover the assertion and can be inherited from the Response= signature, based64 encoded. Subject format and attribute statement left u= ndefined and implementation specific} Some other implementation may want a SAML1.1 profile, or an Encrypted Asser= tion Profile, which would all be base64 encoded, but the details of the exp= ected assertion would change. Someone may want to develop a Siteminder prof= ile. In this case, a siteminder session token would be exchanged for an O= auth token. This would have a completely opaque format, and might be hex = encode. Someone else might want to develop an x.509 profile. Etc, etc. It really wouldn't be up to conformant Oauth2 clients to support these prof= iles, or even the core assertion profile for that matter. As Marius point= s out, the method for obtaining/validating the assertions will be out of sc= ope, and hence this is a specialized Oauth client/server you're dealing wit= h by definition. -cmort ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Thursday, April 01, 2010 9:54 PM To: Marius Scurtescu Cc: OAuth WG Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) What is the assertion format? Binary? XML? Should the library encode it? Is= the application using the library responsible for providing it with a URI-= safe string? EHL On 4/1/10 9:45 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te: > But providing a half baked flow that is short enough to just replicate wh= ere > needed and cannot be fully implemented by generic libraries doesn=92t rea= lly > offer much. I think this is similar to the scope parameter argument, that libraries cannot really use an opaque scope. OAuth libraries will neither generate nor consume the assertions, the assertion itself can be opaque. The client application need= s to obtain an assertion somehow, this is out of scope, then pass it to a librar= y and the library can use it as is, pass it to the Authorization Server and deal with the response. Works perfectly fine IMO. Marius From cmortimore@salesforce.com Fri Apr 2 07:58:29 2010 Return-Path: <cmortimore@salesforce.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314313A68FE for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 07:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.823 X-Spam-Level: X-Spam-Status: No, score=-4.823 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uruuDo68kOi for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 07:58:28 -0700 (PDT) Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by core3.amsl.com (Postfix) with SMTP id 25CF13A68F7 for <oauth@ietf.org>; Fri, 2 Apr 2010 07:58:28 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKS7YGNniSNZt5xesFVH0BO/1howGyu0P0@postini.com; Fri, 02 Apr 2010 07:59:02 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Fri, 2 Apr 2010 07:59:01 -0700 From: Chuck Mortimore <cmortimore@salesforce.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, Brian Eaton <beaton@google.com> Date: Fri, 2 Apr 2010 07:54:40 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrR+b3eIZ0qtQkjQ5Gxo8m3q38+gAAH4dPJABbJl6g= Message-ID: <77AEC44D4DA08A46ADAA723286626BC12E2D43FABB@EXSFM-MB01.internal.salesforce.com> References: <y2rdaf5b9571004011716t5c475c74p5d813a464f78592@mail.gmail.com>, <C7DABA53.31B60%eran@hueniverse.com> In-Reply-To: <C7DABA53.31B60%eran@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 14:58:29 -0000 Other profiles will be required. The only point is to give these profiling= specs clear guidelines on how they should approach the problem. In any case, I get your point about what you want included in the core spec= ification and why. I'll put forth a proposal for the SAML format. -cmort=20 ________________________________________ From: Eran Hammer-Lahav [eran@hueniverse.com] Sent: Thursday, April 01, 2010 9:02 PM To: Brian Eaton Cc: Chuck Mortimore; OAuth WG Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) This boils down to: if the flow cannot be used without further profile, and= it is less than a page long, what=92s the value of putting it in the speci= fication, as opposed to a fully specified extension? Or the alternative to = provide one fully specified flow using the most common type of assertions (= I=92m not a SAML expert so I have no clue what that might be), and let othe= rs use that as a template. But providing a half baked flow that is short enough to just replicate wher= e needed and cannot be fully implemented by generic libraries doesn=92t rea= lly offer much. I am not putting a stake in the ground on this but I am doing my job as edi= tor to point out to the authors and users of this spec that as written, the= flow is just not actually useful. It has the same value as if I posted it = on my blog because to use it, someone will have to write a new spec that pr= ofiles it to an interop-capable setup. EHL On 4/1/10 5:16 PM, "Brian Eaton" <beaton@google.com> wrote: On Thu, Apr 1, 2010 at 5:10 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te: > Are they profiling a half page spec? The spec is 66 pages long. But the widely used pieces are quite a bit shorter. =3D) From cmortimore@salesforce.com Fri Apr 2 08:08:28 2010 Return-Path: <cmortimore@salesforce.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF9B3A6980 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyqgV1NTrHLc for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 08:08:27 -0700 (PDT) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by core3.amsl.com (Postfix) with SMTP id 175693A6907 for <oauth@ietf.org>; Fri, 2 Apr 2010 08:08:27 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKS7YIjbf4Z8Pb76BeO51Ppkwx676D9Y6E@postini.com; Fri, 02 Apr 2010 08:09:01 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Fri, 2 Apr 2010 08:09:00 -0700 From: Chuck Mortimore <cmortimore@salesforce.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, Brian Eaton <beaton@google.com> Date: Fri, 2 Apr 2010 08:07:40 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrR+b3eIZ0qtQkjQ5Gxo8m3q38+gAAH4dPJABc9xn4= Message-ID: <77AEC44D4DA08A46ADAA723286626BC12E2D43FABC@EXSFM-MB01.internal.salesforce.com> References: <y2rdaf5b9571004011716t5c475c74p5d813a464f78592@mail.gmail.com>, <C7DABA53.31B60%eran@hueniverse.com> In-Reply-To: <C7DABA53.31B60%eran@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 15:08:28 -0000 Other profiles will be required. The only point is to give these profiling= specs clear guidelines on how they should approach the problem. In any case, I get your point about what you want included in the core spec= ification and why. I'll try and draft a proposal for the SAML format over= the weekend and present it to the list. -cmort=20 ________________________________________ From: Eran Hammer-Lahav [eran@hueniverse.com] Sent: Thursday, April 01, 2010 9:02 PM To: Brian Eaton Cc: Chuck Mortimore; OAuth WG Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) This boils down to: if the flow cannot be used without further profile, and= it is less than a page long, what=92s the value of putting it in the speci= fication, as opposed to a fully specified extension? Or the alternative to = provide one fully specified flow using the most common type of assertions (= I=92m not a SAML expert so I have no clue what that might be), and let othe= rs use that as a template. But providing a half baked flow that is short enough to just replicate wher= e needed and cannot be fully implemented by generic libraries doesn=92t rea= lly offer much. I am not putting a stake in the ground on this but I am doing my job as edi= tor to point out to the authors and users of this spec that as written, the= flow is just not actually useful. It has the same value as if I posted it = on my blog because to use it, someone will have to write a new spec that pr= ofiles it to an interop-capable setup. EHL On 4/1/10 5:16 PM, "Brian Eaton" <beaton@google.com> wrote: On Thu, Apr 1, 2010 at 5:10 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te: > Are they profiling a half page spec? The spec is 66 pages long. But the widely used pieces are quite a bit shorter. =3D) From beaton@google.com Fri Apr 2 08:53:21 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378F63A682F for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 08:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.346 X-Spam-Level: X-Spam-Status: No, score=-100.346 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTZE0Xw7u+rx for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 08:53:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D52FB3A67D4 for <oauth@ietf.org>; Fri, 2 Apr 2010 08:53:19 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o32Frnlj012571 for <oauth@ietf.org>; Fri, 2 Apr 2010 17:53:49 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270223629; bh=3WvO5aXOwdM5cejAOZfP/xMGb3k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=wIgOisPRVyEZ44czoseBbmU2arZVIjarAdUSrILv02ReJm/BG5cVlDIE2fgDkkmTo anmAOS62sZeYQrOgTu+1w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=UuJaAzRudhm7+MxsZjPMiVJh4jloIo+tsGyua3LVckH+/b09AWi75hhZmexSrzaVT 7ePGTNdgExIfniWHououA== Received: from vws6 (vws6.prod.google.com [10.241.21.134]) by kpbe16.cbf.corp.google.com with ESMTP id o32Frlrk021495 for <oauth@ietf.org>; Fri, 2 Apr 2010 08:53:48 -0700 Received: by vws6 with SMTP id 6so209577vws.9 for <oauth@ietf.org>; Fri, 02 Apr 2010 08:53:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.2 with HTTP; Fri, 2 Apr 2010 08:53:46 -0700 (PDT) In-Reply-To: <C7DABE13.29882%atom@yahoo-inc.com> References: <710CC9A4-422B-424A-8FC2-AB190F41E87F@facebook.com> <C7DABE13.29882%atom@yahoo-inc.com> Date: Fri, 2 Apr 2010 08:53:46 -0700 Received: by 10.220.108.106 with SMTP id e42mr1233659vcp.79.1270223626880; Fri, 02 Apr 2010 08:53:46 -0700 (PDT) Message-ID: <u2vdaf5b9571004020853q2b527d1aw160c9105ec48eb84@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: Allen Tom <atom@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Device Flow - Session Fixation? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 15:53:21 -0000 On Thu, Apr 1, 2010 at 9:18 PM, Allen Tom <atom@yahoo-inc.com> wrote: > The Auth server should also check for the presence of an HTTP Referrer. > There should not be a referrer, since the user should not have clicked on > anything to have landed on the screen I don't think this one is going to work in practice. Manufacturers may not point users directly at the OAuth approval page. They are going to end up pointing users to something shorter, e.g. "http://google.samsung.com". That web site will then redirect the user to the right approval page. Otherwise we end up needing to tell users to manually type-in long, complex urls like https://www.google.com/accounts/OAuthAuthorize?client_id=1238979. Cheers, Brian From eran@hueniverse.com Fri Apr 2 09:03:27 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC1563A6808 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.238 X-Spam-Level: * X-Spam-Status: No, score=1.238 tagged_above=-999 required=5 tests=[AWL=-1.829, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FRT_PROFILE1=2.555, FRT_PROFILE2=1.981] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOEzdY+KO4TE for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:03:26 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id DC1603A67D4 for <oauth@ietf.org>; Fri, 2 Apr 2010 09:03:26 -0700 (PDT) Received: (qmail 5827 invoked from network); 2 Apr 2010 16:03:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 16:03:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 2 Apr 2010 09:03:33 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Chuck Mortimore <cmortimore@salesforce.com> Date: Fri, 2 Apr 2010 09:03:25 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrSfgto5XGIZ8MUR6Gyxqxk8a9mDA== Message-ID: <2EF9AB07-95F6-41A2-BA05-43C2CF20D129@hueniverse.com> References: <l2i74caaad21004012145r7f789f8av76df4f14a2420139@mail.gmail.com>, <C7DAC67E.31B7C%eran@hueniverse.com> <77AEC44D4DA08A46ADAA723286626BC12E2D43FABA@EXSFM-MB01.internal.salesforce.com> In-Reply-To: <77AEC44D4DA08A46ADAA723286626BC12E2D43FABA@EXSFM-MB01.internal.salesforce.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 16:03:27 -0000 VGhlIHByb2JsZW0gd2l0aCBiYXNlNjQgKGV2ZW4gdGhlIHVyaSBzYWZlIGZsYXZvcikgaXMgdGhl IHBhZGRpbmQgIA0KY2hhcmFjdGVyICg9KSBpcyBub3QgYWxsb3dlZCB3aXRob3V0IHBlcmNlbnQg ZW5jb2RpbmcuIFRoaXMgZ2V0cyBtZXNzeSAgDQp3aXRob3V0IGNsZWFyIGVuY29kaW5nIHByb2Nl c3MuDQoNClRoZSBleGFtcGxlIGJlbG93IHNob3cgdGhhdCB0aGUgcHJvZmlsZXMgYXJlIGxpa2Vs eSB0byBiZSBtdWNoIGxvbmdlciAgDQp0aGFuIHRoZSBmbG93IGl0c2VsZiwgcmFpc2luZyBteSBx dWVzdGlvbiBvZiB3aGV0aGVyIGl0IGlzIHJlYWxseSBhbGwgIA0KdGhhdCB1c2VmdWwgdG8gYmUg aW5jbHVkZWQuDQoNCklmIHdlIGFyZSBnb2luZyB0byBrZWVwIHRoaXMgaW4gdGhlIGNvcmUgc3Bl YyB3ZSBuZWVkIGEgbGlzdCBvZiB3aGF0IGEgIA0KcHJvZmlsZSBtdXN0IHNwZWNpZnkgKGp1c3Qg dGhlIGl0ZW1zLCBub3QgdGhlIGFjdHVhbCBkZXRhaWxzKSBhbmQgd2UgIA0KbmVlZCBhbiBleGFt cGxlLiBJIGNhbiBsaXZlIHdpdGggdGhhdC4NCg0KQW5vdGhlciBvcHRpb24gaXMgdG8gbW92ZSBp dCB0byBhIHNlcGFyYXRlIGFzc2VydGlvbiBmbG93cyBzcGVjIHdoaWNoICANCndpbGwgaW5jbHVk ZSBhIGZldyBnZW5lcmFsbHkgdXNlZnVsIHByb2ZpbGVzLg0KDQpFSEwNCg0KT24gQXByIDIsIDIw MTAsIGF0IDEwOjQ1LCAiQ2h1Y2sgTW9ydGltb3JlIiAgDQo8Y21vcnRpbW9yZUBzYWxlc2ZvcmNl LmNvbT4gd3JvdGU6DQoNCj4gVGhlIGZvcm1hdCB3b3VsZCBiZSBzcGVjaWZpZWQgYnkgYSBwcm9m aWxpZS4gICAgRm9yIGluc3RhbmNlLCBhIFNBTUwgIA0KPiBwcm9maWxlIG1pZ2h0IGRlZmluZToN Cj4NCj4gYXNzZXJ0aW9uX2Zvcm1hdD11cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y206YmVh cmVyDQo+IGFzc2VydGlvbj17U0FNTCAyIGJlYXJlciBhc3NlcnRpb24sIG9wdGlvbmFsbHkgd3Jh cHBlZCBpbiBhIFNBTUwgIA0KPiByZXNwb25zZSwgU2lnbmF0dXJlIG11c3QgY292ZXIgdGhlIGFz c2VydGlvbiBhbmQgY2FuIGJlIGluaGVyaXRlZCAgDQo+IGZyb20gdGhlIFJlc3BvbnNlIHNpZ25h dHVyZSwgYmFzZWQ2NCBlbmNvZGVkLiAgU3ViamVjdCBmb3JtYXQgYW5kICANCj4gYXR0cmlidXRl IHN0YXRlbWVudCBsZWZ0IHVuZGVmaW5lZCBhbmQgaW1wbGVtZW50YXRpb24gc3BlY2lmaWN9DQo+ DQo+IFNvbWUgb3RoZXIgaW1wbGVtZW50YXRpb24gbWF5IHdhbnQgYSBTQU1MMS4xIHByb2ZpbGUs IG9yIGFuICANCj4gRW5jcnlwdGVkIEFzc2VydGlvbiBQcm9maWxlLCB3aGljaCB3b3VsZCBhbGwg YmUgYmFzZTY0IGVuY29kZWQsIGJ1dCAgDQo+IHRoZSBkZXRhaWxzIG9mIHRoZSBleHBlY3RlZCBh c3NlcnRpb24gd291bGQgY2hhbmdlLiBTb21lb25lIG1heSB3YW50ICANCj4gdG8gZGV2ZWxvcCBh IFNpdGVtaW5kZXIgcHJvZmlsZS4gICBJbiB0aGlzIGNhc2UsIGEgc2l0ZW1pbmRlciAgDQo+IHNl c3Npb24gdG9rZW4gd291bGQgYmUgZXhjaGFuZ2VkIGZvciBhbiBPYXV0aCB0b2tlbi4gICBUaGlz IHdvdWxkICANCj4gaGF2ZSBhIGNvbXBsZXRlbHkgb3BhcXVlIGZvcm1hdCwgYW5kIG1pZ2h0IGJl IGhleCBlbmNvZGUuICAgIFNvbWVvbmUgIA0KPiBlbHNlIG1pZ2h0IHdhbnQgdG8gZGV2ZWxvcCBh biB4LjUwOSBwcm9maWxlLiAgIEV0YywgZXRjLg0KPg0KPiBJdCByZWFsbHkgd291bGRuJ3QgYmUg dXAgdG8gY29uZm9ybWFudCBPYXV0aDIgY2xpZW50cyB0byBzdXBwb3J0ICANCj4gdGhlc2UgcHJv ZmlsZXMsIG9yIGV2ZW4gdGhlIGNvcmUgYXNzZXJ0aW9uIHByb2ZpbGUgZm9yIHRoYXQgIA0KPiBt YXR0ZXIuICAgQXMgTWFyaXVzIHBvaW50cyBvdXQsIHRoZSBtZXRob2QgZm9yIG9idGFpbmluZy92 YWxpZGF0aW5nICANCj4gdGhlIGFzc2VydGlvbnMgd2lsbCBiZSBvdXQgb2Ygc2NvcGUsIGFuZCBo ZW5jZSB0aGlzIGlzIGEgc3BlY2lhbGl6ZWQgIA0KPiBPYXV0aCBjbGllbnQvc2VydmVyIHlvdSdy ZSBkZWFsaW5nIHdpdGggYnkgZGVmaW5pdGlvbi4NCj4NCj4gLWNtb3J0DQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogb2F1dGgtYm91bmNlc0Bp ZXRmLm9yZyBbb2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mICANCj4gRXJhbiBI YW1tZXItTGFoYXYgW2VyYW5AaHVlbml2ZXJzZS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJp bCAwMSwgMjAxMCA5OjU0IFBNDQo+IFRvOiBNYXJpdXMgU2N1cnRlc2N1DQo+IENjOiBPQXV0aCBX Rw0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTQU1MIEFzc2VydGlvbiBGbG93ICh3YXM6IERy YWZ0IHByb2dyZXNzICANCj4gdXBkYXRlKQ0KPg0KPiBXaGF0IGlzIHRoZSBhc3NlcnRpb24gZm9y bWF0PyBCaW5hcnk/IFhNTD8gU2hvdWxkIHRoZSBsaWJyYXJ5IGVuY29kZSAgDQo+IGl0PyBJcyB0 aGUgYXBwbGljYXRpb24gdXNpbmcgdGhlIGxpYnJhcnkgcmVzcG9uc2libGUgZm9yIHByb3ZpZGlu ZyAgDQo+IGl0IHdpdGggYSBVUkktc2FmZSBzdHJpbmc/DQo+DQo+IEVITA0KPg0KPg0KPiBPbiA0 LzEvMTAgOTo0NSBQTSwgIk1hcml1cyBTY3VydGVzY3UiIDxtc2N1cnRlc2N1QGdvb2dsZS5jb20+ IHdyb3RlOg0KPg0KPiBPbiBUaHUsIEFwciAxLCAyMDEwIGF0IDk6MDIgUE0sIEVyYW4gSGFtbWVy LUxhaGF2ICANCj4gPGVyYW5AaHVlbml2ZXJzZS5jb20+IHdyb3RlOg0KPj4gQnV0IHByb3ZpZGlu ZyBhIGhhbGYgYmFrZWQgZmxvdyB0aGF0IGlzIHNob3J0IGVub3VnaCB0byBqdXN0ICANCj4+IHJl cGxpY2F0ZSB3aGVyZQ0KPj4gbmVlZGVkIGFuZCBjYW5ub3QgYmUgZnVsbHkgaW1wbGVtZW50ZWQg YnkgZ2VuZXJpYyBsaWJyYXJpZXMgZG9lc27igJkgDQo+PiB0IHJlYWxseQ0KPj4gb2ZmZXIgbXVj aC4NCj4NCj4gSSB0aGluayB0aGlzIGlzIHNpbWlsYXIgdG8gdGhlIHNjb3BlIHBhcmFtZXRlciBh cmd1bWVudCwgdGhhdA0KPiBsaWJyYXJpZXMgY2Fubm90IHJlYWxseQ0KPiB1c2UgYW4gb3BhcXVl IHNjb3BlLiBPQXV0aCBsaWJyYXJpZXMgd2lsbCBuZWl0aGVyIGdlbmVyYXRlIG5vciAgDQo+IGNv bnN1bWUgdGhlDQo+IGFzc2VydGlvbnMsIHRoZSBhc3NlcnRpb24gaXRzZWxmIGNhbiBiZSBvcGFx dWUuIFRoZSBjbGllbnQgIA0KPiBhcHBsaWNhdGlvbiBuZWVkcyB0bw0KPiBvYnRhaW4gYW4gYXNz ZXJ0aW9uIHNvbWVob3csIHRoaXMgaXMgb3V0IG9mIHNjb3BlLCB0aGVuIHBhc3MgaXQgdG8gYSAg DQo+IGxpYnJhcnkgYW5kDQo+IHRoZSBsaWJyYXJ5IGNhbiB1c2UgaXQgYXMgaXMsIHBhc3MgaXQg dG8gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGFuZA0KPiBkZWFsIHdpdGggdGhlDQo+IHJlc3Bv bnNlLiBXb3JrcyBwZXJmZWN0bHkgZmluZSBJTU8uDQo+DQo+IE1hcml1cw0KPg0K From eran@hueniverse.com Fri Apr 2 09:18:11 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CEF63A6869 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIt2QpsTqIxL for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:18:10 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 55D483A6A04 for <oauth@ietf.org>; Fri, 2 Apr 2010 09:18:06 -0700 (PDT) Received: (qmail 6726 invoked from network); 2 Apr 2010 16:18:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 16:18:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 2 Apr 2010 09:18:38 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: OAuth WG <oauth@ietf.org> Date: Fri, 2 Apr 2010 09:18:36 -0700 Thread-Topic: Scope using Realm idea Thread-Index: AcrSgCV7VO0G3FAHREmKYhTk5ZzLvQ== Message-ID: <C7DB66EC.31BA0%eran@hueniverse.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 16:18:11 -0000 This is half baked but I wanted to get people's reaction: Clients tries accessing a resource with or without an access token: GET /resource/1 HTTP/1.1 Host: server.example.com The server replies with: HTTP/1.1 401 Unauthorized WWW-Authenticate: OAuth realm=3D'example' Clients requests an access token (using the client credentials flow) and includes the requested realm (line breaks for display purposes): POST /access_token HTTP/1.1 Host: server.example.com =20 client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpnqmM& mode=3Dflow_client&realm=3Dexample The server issues a access token capable of accessing the resource realm. This means one new parameter on the request side which is already baked int= o the 401 response in a standard way. Thoughts? EHL From email@pbryan.net Fri Apr 2 09:22:24 2010 Return-Path: <email@pbryan.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645713A659A for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rps4OSvshMex for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:22:22 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 635E83A684F for <oauth@ietf.org>; Fri, 2 Apr 2010 09:22:17 -0700 (PDT) Received: from [192.168.1.4] (S0106001346fbe4af.vf.shawcable.net [174.1.44.35]) by maple.anode.ca (Postfix) with ESMTPSA id BA7E06458 for <oauth@ietf.org>; Fri, 2 Apr 2010 16:22:50 +0000 (UTC) From: "Paul C. Bryan" <email@pbryan.net> To: OAuth WG <oauth@ietf.org> In-Reply-To: <C7DB66EC.31BA0%eran@hueniverse.com> References: <C7DB66EC.31BA0%eran@hueniverse.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 02 Apr 2010 09:24:28 -0700 Message-ID: <1270225468.14570.2.camel@Dynamo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 16:22:24 -0000 Presumably, the realm was used to discover the token issuance endpoints. Why wouldn't the discovered URL of the access token endpoint dictate realm, and why can't the realm then be implicit beyond discovery? -----Original Message----- From: Eran Hammer-Lahav <eran@hueniverse.com> To: OAuth WG <oauth@ietf.org> Subject: [OAUTH-WG] Scope using Realm idea Date: Fri, 2 Apr 2010 09:18:36 -0700 This is half baked but I wanted to get people's reaction: Clients tries accessing a resource with or without an access token: GET /resource/1 HTTP/1.1 Host: server.example.com The server replies with: HTTP/1.1 401 Unauthorized WWW-Authenticate: OAuth realm='example' Clients requests an access token (using the client credentials flow) and includes the requested realm (line breaks for display purposes): POST /access_token HTTP/1.1 Host: server.example.com client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM& mode=flow_client&realm=example The server issues a access token capable of accessing the resource realm. This means one new parameter on the request side which is already baked into the 401 response in a standard way. Thoughts? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Fri Apr 2 09:23:23 2010 Return-Path: <zachary.zeltsan@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279C33A6808 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcYMlXbIJ9rR for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:23:20 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 6AB023A6896 for <oauth@ietf.org>; Fri, 2 Apr 2010 09:23:20 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o32GNrGL012927 for <oauth@ietf.org>; Fri, 2 Apr 2010 11:23:53 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o32GNrLA006001 for <oauth@ietf.org>; Fri, 2 Apr 2010 11:23:53 -0500 (CDT) Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 2 Apr 2010 11:23:53 -0500 From: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> To: OAuth WG <oauth@ietf.org> Date: Fri, 2 Apr 2010 11:23:52 -0500 Thread-Topic: OAUTH use cases Thread-Index: AcrSgOHnMmdQ0rxVSf+0VfSMncz7Dw== Message-ID: <5710F82C0E73B04FA559560098BF95B124F7A92BE6@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_5710F82C0E73B04FA559560098BF95B124F7A92BE6USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [OAUTH-WG] OAUTH use cases X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 16:23:23 -0000 --_004_5710F82C0E73B04FA559560098BF95B124F7A92BE6USNAVSXCHMBSA_ Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B124F7A92BE6USNAVSXCHMBSA_" --_000_5710F82C0E73B04FA559560098BF95B124F7A92BE6USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the Anaheim meeting I volunteered to document the use cases of OAuth. T= he objective is to identify the use cases as a base for establishing the re= quirements that the OAuth specifications should meet. As a first step, I have compiled a list of the use cases that I have found = in the drafts and in the OAUTH-WG email archive. At this point, the list does not reflect any decisions on whether a particu= lar use case should be supported or not. My intention was to identify the u= se cases that have been discussed. It is likely that I have missed some, th= erefore I ask for your input on the additional use cases. The use cases in the attached document are unedited and often abbreviated. Your feedback is welcome, Zachary --_000_5710F82C0E73B04FA559560098BF95B124F7A92BE6USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:st=3D"" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:"FuturaA Bk BT"; panose-1:2 11 5 2 2 2 4 2 3 3;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"FuturaA Bk BT";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:#606420; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:Arial; color:windowtext;} @page Section1 {size:595.3pt 841.9pt; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3D"#606420"> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>At the <st1:City w:st=3D"on"><st1:place w:st=3D"on">Anah= eim</st1:place></st1:City> meeting I volunteered to document the use cases of OAuth.  The objecti= ve is to identify the use cases as a base for establishing the requirements that = the OAuth specifications should meet. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>As a first step, I have compiled a list of the use cases that I have found in the drafts and in the OAUTH-WG email archive.<o:p></o:= p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>At this point, the list does not reflect any decisions o= n whether a particular use case should be supported or not. My intention was = to identify the use cases that have been discussed. It is likely that I have missed som= e, therefore I ask for your input on the additional use cases.<o:p></o:p></spa= n></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>The use cases in the attached document are unedited and often abbreviated.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Your feedback is welcome,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Zachary<o:p></o:p></span></font></p> </div> </body> </html> --_000_5710F82C0E73B04FA559560098BF95B124F7A92BE6USNAVSXCHMBSA_-- --_004_5710F82C0E73B04FA559560098BF95B124F7A92BE6USNAVSXCHMBSA_ Content-Type: text/html; name="oauth-use-cases.htm" Content-Description: oauth-use-cases.htm Content-Disposition: attachment; filename="oauth-use-cases.htm"; size=60643; creation-date="Fri, 02 Apr 2010 11:13:20 GMT"; modification-date="Fri, 02 Apr 2010 11:13:20 GMT" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiDQp4bWxuczpvPSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiDQp4bWxuczp3PSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIg0KeG1sbnM6c3QxPSJ1cm46c2NoZW1hcy1t aWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiDQp4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQo8bWV0YSBuYW1lPVBy b2dJZCBjb250ZW50PVdvcmQuRG9jdW1lbnQ+DQo8bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMSI+DQo8bWV0YSBuYW1lPU9yaWdpbmF0b3IgY29udGVudD0iTWlj cm9zb2Z0IFdvcmQgMTEiPg0KPGxpbmsgcmVsPUZpbGUtTGlzdCBocmVmPSJvYXV0aC11c2UtY2Fz ZXNfZmlsZXMvZmlsZWxpc3QueG1sIj4NCjx0aXRsZT5PQXV0aCBVc2UgQ2FzZXM8L3RpdGxlPg0K PG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9IkNpdHkiLz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3Bh Y2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1l PSJwbGFjZSIvPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86RG9jdW1lbnRQcm9wZXJ0 aWVzPg0KICA8bzpBdXRob3I+emVsdHNhbjwvbzpBdXRob3I+DQogIDxvOkxhc3RBdXRob3I+emVs dHNhbjwvbzpMYXN0QXV0aG9yPg0KICA8bzpSZXZpc2lvbj4yPC9vOlJldmlzaW9uPg0KICA8bzpU b3RhbFRpbWU+MTwvbzpUb3RhbFRpbWU+DQogIDxvOkxhc3RQcmludGVkPjIwMTAtMDQtMDJUMTU6 Mzg6MDBaPC9vOkxhc3RQcmludGVkPg0KICA8bzpDcmVhdGVkPjIwMTAtMDQtMDJUMTY6MTM6MDBa PC9vOkNyZWF0ZWQ+DQogIDxvOkxhc3RTYXZlZD4yMDEwLTA0LTAyVDE2OjEzOjAwWjwvbzpMYXN0 U2F2ZWQ+DQogIDxvOlBhZ2VzPjE8L286UGFnZXM+DQogIDxvOldvcmRzPjIzNzQ8L286V29yZHM+ DQogIDxvOkNoYXJhY3RlcnM+MTM1Mzc8L286Q2hhcmFjdGVycz4NCiAgPG86Q29tcGFueT5BbGNh dGVsLUx1Y2VudDwvbzpDb21wYW55Pg0KICA8bzpMaW5lcz4xMTI8L286TGluZXM+DQogIDxvOlBh cmFncmFwaHM+MzE8L286UGFyYWdyYXBocz4NCiAgPG86Q2hhcmFjdGVyc1dpdGhTcGFjZXM+MTU4 ODA8L286Q2hhcmFjdGVyc1dpdGhTcGFjZXM+DQogIDxvOlZlcnNpb24+MTEuOTk5OTwvbzpWZXJz aW9uPg0KIDwvbzpEb2N1bWVudFByb3BlcnRpZXM+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3OlZhbGlkYXRlQWdhaW5z dFNjaGVtYXMvPg0KICA8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93OlNhdmVJZlhNTEludmFs aWQ+DQogIDx3Oklnbm9yZU1peGVkQ29udGVudD5mYWxzZTwvdzpJZ25vcmVNaXhlZENvbnRlbnQ+ DQogIDx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNl aG9sZGVyVGV4dD4NCiAgPHc6Q29tcGF0aWJpbGl0eT4NCiAgIDx3OkZvb3Rub3RlTGF5b3V0TGlr ZVdXOC8+DQogICA8dzpTaGFwZUxheW91dExpa2VXVzgvPg0KICAgPHc6QWxpZ25UYWJsZXNSb3dC eVJvdy8+DQogICA8dzpGb3JnZXRMYXN0VGFiQWxpZ25tZW50Lz4NCiAgIDx3OkxheW91dFJhd1Rh YmxlV2lkdGgvPg0KICAgPHc6TGF5b3V0VGFibGVSb3dzQXBhcnQvPg0KICAgPHc6VXNlV29yZDk3 TGluZUJyZWFraW5nUnVsZXMvPg0KICAgPHc6U2VsZWN0RW50aXJlRmllbGRXaXRoU3RhcnRPckVu ZC8+DQogICA8dzpVc2VXb3JkMjAwMlRhYmxlU3R5bGVSdWxlcy8+DQogIDwvdzpDb21wYXRpYmls aXR5Pg0KICA8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8L3c6QnJv d3NlckxldmVsPg0KIDwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpMYXRlbnRTdHlsZXMgRGVmTG9ja2VkU3RhdGU9ImZhbHNl IiBMYXRlbnRTdHlsZUNvdW50PSIxNTYiPg0KIDwvdzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmICFtc29dPjxvYmplY3QNCiBjbGFzc2lkPSJjbHNpZDozODQ4MTgwNy1D QTBFLTQyRDItQkYzOS1CMzNBRjEzNUNDNEQiIGlkPWllb291aT48L29iamVjdD4NCjxzdHlsZT4N CnN0MVw6KntiZWhhdmlvcjp1cmwoI2llb291aSkgfQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPg0K PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwOw0KCW1z by1mb250LWNoYXJzZXQ6MjsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTphdXRvOw0KCW1zby1m b250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTowIDI2ODQzNTQ1NiAwIDAg LTIxNDc0ODM2NDggMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJGdXR1cmFBIEJrIEJU IjsNCglwYW5vc2UtMToyIDExIDUgMiAyIDIgNCAyIDMgMzsNCgltc28tZm9udC1jaGFyc2V0OjA7 DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFi bGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjEzNSAwIDAgMCAyNyAwO30NCiAvKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjExLjBwdDsNCglt c28tYmlkaS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJGdXR1cmFBIEJrIEJUIjsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVy bGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2Nv bG9yOiM2MDY0MjA7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGlu ZTpzaW5nbGU7fQ0KcHJlDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0Kc3Bhbi5taDENCgl7bXNvLXN0eWxlLW5hbWU6bV9oMTsNCglmb250LWZhbWls eTpBcmlhbDsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OkFyaWFsOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsOw0KCWZvbnQtd2VpZ2h0 OmJvbGQ7fQ0Kc3Bhbi5tZnRyMQ0KCXttc28tc3R5bGUtbmFtZTptX2Z0cjE7DQoJY29sb3I6Z3Jh eTt9DQpzcGFuLm1oZHIxDQoJe21zby1zdHlsZS1uYW1lOm1faGRyMTsNCgljb2xvcjpncmF5O30N CkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NTk1LjNwdCA4NDEuOXB0Ow0KCW1hcmdpbjoxLjBpbiAx LjI1aW4gMS4waW4gMS4yNWluOw0KCW1zby1oZWFkZXItbWFyZ2luOjM1LjRwdDsNCgltc28tZm9v dGVyLW1hcmdpbjozNS40cHQ7DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5TZWN0aW9uMQ0K CXtwYWdlOlNlY3Rpb24xO30NCiAvKiBMaXN0IERlZmluaXRpb25zICovDQogQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6MjIzNDk2MDk5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotNjE4MTE4NTIyIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MzQ4MTQ2MzIwOw0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjYzODM0MzIwIDY3Njk4NzA5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS11cHBlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyDQoJe21zby1s aXN0LWlkOjM3MjMxMTc4NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTEzNzY0NTYwNDAgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDo1MjA2MjkwMDA7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1MTQxNDk0MCA2NzY5ODcxMSA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNTt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTI4NzgwODQ3NjsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEyNjQ1OTUyNiA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlkOjEzMjUxNTg5NzI7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1Mzg5NjY2 MiA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsNTpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2DQoJe21zby1s aXN0LWlkOjE2NTA0MDAzMDg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjE2NDU2MzgyMTggNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDY6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsNw0KCXttc28tbGlzdC1pZDoxOTE1MDQ4Mjc1Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoyMDc3OTQ2NTAwO30NCkBsaXN0IGw3OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDc6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpc RjBBNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDc6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpc RjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDc6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDc6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNv IDEwXT4NCjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHRhYmxlLk1zb05vcm1h bFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93 YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9z aG93OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5nLWFsdDowaW4gNS40 cHQgMGluIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdpbjowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1hbnNpLWxhbmd1 YWdlOiMwNDAwOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOiMwNDAwOw0KCW1zby1iaWRpLWxhbmd1 YWdlOiMwNDAwO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIyMDUwIi8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIi8+DQogPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVT IGxpbms9Ymx1ZSB2bGluaz0iIzYwNjQyMCIgc3R5bGU9J3RhYi1pbnRlcnZhbDouNWluJz4NCg0K PGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBz dHlsZT0nbWFyZ2luLWJvdHRvbTo2LjBwdDt0ZXh0LWFsaWduOmNlbnRlcjsNCmxpbmUtaGVpZ2h0 OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAy NzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5 NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxiPjxzcGFuDQpzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz5PQXV0 aCBVc2UNCkNhc2VzPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjYuMHB0O2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3Rv cHM6DQo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZw dCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0 IDY4Ny4wcHQgNzMyLjhwdCc+PGI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1i aWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPjEuIFVzZQ0KY2FzZSBvZiB0 aGUgZHJhZnQgPGkgc3R5bGU9J21zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsJz5UaGUgT0F1dGgg MS4wIFByb3RvY29sPC9pPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0 IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQg NDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+ PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PihkcmFmdC1oYW1tZXItb2F1dGgtMTAgYXV0aG9yZWQNCmJ5IEUuIEhhbW1lci1MYWhhdiwgRWQu OyBwdWJsaXNoZWQgb24gRmVicnVhcnkgNSwgMjAxMCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0O3RhYi1zdG9wczo0 NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYu NHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4w cHQgNzMyLjhwdCc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPkEgd2ViIHVzZXIgKHJlc291cmNlIG93bmVyKQ0KY2FuIGdyYW50IGEgcHJp bnRpbmcgc2VydmljZSAoY2xpZW50KSBhY2Nlc3MgdG8gaGVyIHByaXZhdGUgcGhvdG9zIHN0b3Jl ZCBhdCBhDQpwaG90byBzaGFyaW5nIHNlcnZpY2UgKHNlcnZlciksIHdpdGhvdXQgc2hhcmluZyBo ZXIgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIHdpdGgNCnRoZSBwcmludGluZyBzZXJ2aWNlLjxzcGFu IHN0eWxlPSdtc28tc3BhY2VydW46eWVzJz6gIDwvc3Bhbj5JbnN0ZWFkLCBzaGUNCmF1dGhlbnRp Y2F0ZXMgZGlyZWN0bHkgd2l0aCB0aGUgcGhvdG8gc2hhcmluZyBzZXJ2aWNlIHdoaWNoIGlzc3Vl cyB0aGUgcHJpbnRpbmcNCnNlcnZpY2UgZGVsZWdhdGlvbi1zcGVjaWZpYyBjcmVkZW50aWFscy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1o ZWlnaHQ6MTQuNHB0O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjku MHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42 cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjYu MHB0O2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6DQo0NS44cHQgOTEuNnB0IDEzNy40cHQg MTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1 MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PGI+PHNwYW4N CnN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6QXJpYWwnPjIuIFVzZQ0KY2FzZXMgb2YgdGhlIGRyYWZ0IDxpIHN0eWxlPSdtc28tYmlk aS1mb250LXN0eWxlOm5vcm1hbCc+T0F1dGggV2ViIFJlc291cmNlDQpBdXRob3JpemF0aW9uIFBy b2ZpbGVzIDxzcGFuIHN0eWxlPSdtc28tc3BhY2VydW46eWVzJz6gPC9zcGFuPjwvaT48bzpwPjwv bzpwPjwvc3Bhbj48L2I+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVp Z2h0OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBw dCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0 IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4oZHJhZnQtaGFyZHQtb2F1dGgtMDEN CmF1dGhvcmVkIGJ5IEQuIEhhcmR0LCBFZC4sIE1pY3Jvc29mdCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0O3RhYi1z dG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZw dCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0 IDY4Ny4wcHQgNzMyLjhwdCc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPjxzcGFuDQpzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+oDwvc3Bh bj5BLiBUb20sIFlhaG9vISwgQi4gRWF0b24sIEdvb2dsZSwgWS4gR29sYW5kLA0KTWljcm9zb2Z0 OyBwdWJsaXNoZWQgb24gSmFudWFyeSAxNSwgMjAxMCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0O3RhYi1zdG9wczo0 NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYu NHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4w cHQgNzMyLjhwdCc+PGINCnN0eWxlPSdtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwnPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIkNvdXJpZXIgTmV3Iic+QXV0 b25vbW91cyBDbGllbnQgUHJvZmlsZXM8c3Bhbg0Kc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgDQo8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCg0KPHVsIHN0eWxlPSdtYXJn aW4tdG9wOjBpbicgdHlwZT1kaXNjPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1ib3R0b206Ni4wcHQ7bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzE7DQogICAgIHRhYi1zdG9wczps aXN0IC41aW4gbGVmdCA0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44 cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRw dCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PGINCiAgICAgc3R5bGU9J21zby1iaWRpLWZvbnQt d2VpZ2h0Om5vcm1hbCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQogICAgIGZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPkNsaWVudCBBY2NvdW50IGFuZCBQYXNzd29yZCA8L3NwYW4+ PC9iPjxzcGFuDQogICAgIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+DQo8L3VsPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi10b3A6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo2LjBwdDsNCm1hcmdpbi1sZWZ0Oi41aW47bGluZS1oZWlnaHQ6MTQuNHB0O3RhYi1zdG9wczo0 NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYu NHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4w cHQgNzMyLjhwdCc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPlRoZSBDbGllbnQgaXMgcHJvdmlzaW9uZWQNCndpdGggYW4gYWNjb3VudCBu YW1lIGFuZCBjb3JyZXNwb25kaW5nIHBhc3N3b3JkIGJ5IHRoZSBBdXRob3JpemF0aW9uDQpTZXJ2 ZXIuPHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqAgPC9zcGFuPlRoZSBDbGllbnQgcHJl c2VudHMgdGhlIGFjY291bnQNCm5hbWUgYW5kIHBhc3N3b3JkIHRvIHRoZSBBY2Nlc3MgVG9rZW4g VVJMIGF0IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBpbiBleGNoYW5nZQ0KZm9yIGFuIEFjY2Vz cyBUb2tlbi4gVGhpcyBwcm9maWxlIGlzIG5vdCBpbnRlbmRlZCBmb3IgYSBDbGllbnQgYWN0aW5n IG9uIGJlaGFsZg0Kb2YgYSBVc2VyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHVsIHN0eWxl PSdtYXJnaW4tdG9wOjBpbicgdHlwZT1kaXNjPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1ib3R0b206Ni4wcHQ7bGluZS1oZWlnaHQ6MTQuNHB0O21zby1saXN0Og0KICAgICBs NCBsZXZlbDEgbGZvMTt0YWItc3RvcHM6bGlzdCAuNWluIGxlZnQgNDUuOHB0IDkxLjZwdCAxMzcu NHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4w cHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxiDQog ICAgIHN0eWxlPSdtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KICAgICBmb250LWZhbWlseToiQ291cmllciBOZXciJz5Bc3NlcnRpb248 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQogICAgIDEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4gPGIgc3R5bGU9J21zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCc+ UHJvZmlsZTwvYj48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPg0KPC91bD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tdG9wOjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206Ni4wcHQ7DQptYXJnaW4tbGVmdDouNWluO3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40 cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBw dCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PHNwYW4N CnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlRoaXMg cHJvZmlsZSBlbmFibGVzIGENCkNsaWVudCB3aXRoIGEgU0FNTCA8c3BhbiBzdHlsZT0nbXNvLXNw YWNlcnVuOnllcyc+oDwvc3Bhbj5vciBvdGhlciBhc3NlcnRpb24NCnJlY29nbml6ZWQgYnkgdGhl IEF1dGhvcml6YXRpb24gU2VydmVyLjxzcGFuIHN0eWxlPSdtc28tc3BhY2VydW46eWVzJz6gDQo8 L3NwYW4+VGhlIENsaWVudCBwcmVzZW50cyB0aGUgYXNzZXJ0aW9uIHRvIHRoZSBBY2Nlc3MgVG9r ZW4gVVJMIGF0IHRoZQ0KQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaW4gZXhjaGFuZ2UgZm9yIGFuIEFj Y2VzcyBUb2tlbi48c3Bhbg0Kc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqAgPC9zcGFuPkhvdyB0 aGUgQ2xpZW50IG9idGFpbnMgdGhlIGFzc2VydGlvbiBpcyBvdXQNCm9mIHNjb3BlIG9mIE9BdXRo IFdSQVAuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4y cHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhw dCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxiDQpzdHlsZT0nbXNv LWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToNCiJDb3VyaWVyIE5ldyInPlVzZXIgRGVsZWdhdGlvbiBQcm9maWxlczxvOnA+ PC9vOnA+PC9zcGFuPjwvYj48L3A+DQoNCjx1bCBzdHlsZT0nbWFyZ2luLXRvcDowaW4nIHR5cGU9 ZGlzYz4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjYuMHB0O21z by1saXN0Omw0IGxldmVsMSBsZm8xOw0KICAgICB0YWItc3RvcHM6bGlzdCAuNWluIGxlZnQgNDUu OHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRw dCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0 IDczMi44cHQnPjxiDQogICAgIHN0eWxlPSdtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KICAgICBmb250LWZhbWlseToiQ291cmllciBO ZXciJz5Vc2VybmFtZSBhbmQgUGFzc3dvcmQgUHJvZmlsZTwvc3Bhbj48L2I+PHNwYW4NCiAgICAg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD48 L286cD48L3NwYW4+PC9saT4NCjwvdWw+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLXRvcDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjYuMHB0Ow0KbWFyZ2lu LWxlZnQ6LjVpbjt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBw dCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0 IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5UaGlzIHByb2ZpbGUgaXMgc3VpdGFi bGUNCndoZXJlIHRoZSBDbGllbnQgaXMgYW4gYXBwbGljYXRpb24gdGhlIFVzZXIgaGFzIGluc3Rh bGxlZCBvbiB0aGVpciBjb21wdXRlciBhbmQNCnRoZSBVc2VyIHVzZXMgYSB1c2VybmFtZSBhbmQg cGFzc3dvcmQgdG8gYXV0aGVudGljYXRlIHRvIHRoZSBBdXRob3JpemF0aW9uIHNlcnZlci48c3Bh bg0Kc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqAgPC9zcGFuPlRoaXMgcHJvZmlsZSBlbmFibGVz IGEgQ2xpZW50IHRvIGFjdCBvbg0KYmVoYWxmIG9mIHRoZSBVc2VyIHdpdGhvdXQgaGF2aW5nIHRv IHBlcm1hbmVudGx5IHN0b3JlIHRoZSBVc2VyJ3MgdXNlcm5hbWUgYW5kDQpwYXNzd29yZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjx1bCBzdHlsZT0nbWFyZ2luLXRvcDowaW4nIHR5cGU9ZGlz Yz4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjYuMHB0O21zby1s aXN0Omw0IGxldmVsMSBsZm8xOw0KICAgICB0YWItc3RvcHM6bGlzdCAuNWluIGxlZnQgNDUuOHB0 IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0 MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDcz Mi44cHQnPjxiDQogICAgIHN0eWxlPSdtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwnPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KICAgICBmb250LWZhbWlseToiQ291cmllciBOZXci Jz5XZWIgQXBwIFByb2ZpbGU8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9saT4NCjwvdWw+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLXRvcDowaW47bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjYuMHB0Ow0KbWFyZ2luLWxlZnQ6LjVpbjt0YWItc3RvcHM6NDUuOHB0IDkx LjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIu MnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44 cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz5UaGlzIHByb2ZpbGUgaXMgc3VpdGFibGUNCndoZW4gdGhlIENsaWVudCBpcyBhIHdlYiBh cHBsaWNhdGlvbiBjYWxsaW5nIHRoZSBQcm90ZWN0ZWQgUmVzb3VyY2Ugb24gYmVoYWxmDQpvZiBh IFVzZXIuPHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqAgPC9zcGFuPlRoaXMgcHJvZmls ZSBlbmFibGVzIGEgQ2xpZW50DQp0byBhY3Qgb24gYmVoYWxmIG9mIHRoZSBVc2VyIHdpdGhvdXQg YWNxdWlyaW5nIGEgVXNlcidzIGNyZWRlbnRpYWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHVsIHN0eWxlPSdtYXJnaW4tdG9wOjBpbicgdHlwZT1kaXNjPg0KIDxsaSBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1ib3R0b206Ni4wcHQ7bXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzI7DQog ICAgIHRhYi1zdG9wczpsaXN0IC41aW4gbGVmdCA0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJw dCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0 IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PGINCiAgICAgc3R5bGU9 J21zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7DQogICAgIGZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlJpY2ggQXBwPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCiAgICAgZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+IDxiIHN0eWxlPSdtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwnPlByb2ZpbGU8L2I+ PG86cD48L286cD48L3NwYW4+PC9saT4NCjwvdWw+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLXRvcDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjYuMHB0Ow0K bWFyZ2luLWxlZnQ6LjVpbjt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQg MjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1 NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5UaGlzIHByb2ZpbGUgaXMg c3VpdGFibGUNCndoZW4gdGhlIENsaWVudCBpcyBhbiBhcHBsaWNhdGlvbiB0aGUgVXNlciBoYXMg aW5zdGFsbGVkIG9uIHRoZWlyIGRldmljZSBhbmQgYSB3ZWINCmJyb3dzZXIgaXMgYXZhaWxhYmxl LCBidXQgaXQgaXMgdW5kZXNpcmFibGUgZm9yIHRoZSBVc2VyIHRvIHByb3ZpZGUgdGhlaXINCnVz ZXJuYW1lIGFuZCBwYXNzd29yZCB0byBhbiBhcHBsaWNhdGlvbiwgb3IgdGhlIHVzZXIgbWF5IG5v dCBiZSB1c2luZyBhDQp1c2VybmFtZSBhbmQgcGFzc3dvcmQgdG8gYXV0aGVudGljYXRlIHRvIHRo ZSBBdXRob3JpemF0aW9uIFNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0ndGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0 IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQg NTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48c3Bhbg0Kc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206Ni4wcHQ7dGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4w cHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZw dCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpBcmlhbCc+ My4gRGV2aWNlIFByb2ZpbGU8L3NwYW4+PC9iPjxiDQpzdHlsZT0nbXNvLWJpZGktZm9udC13ZWln aHQ6bm9ybWFsJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiJD b3VyaWVyIE5ldyInPiA8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206Ni4wcHQ7dGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQg MTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0 NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48 c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ KHN1Ym1pdHRlZCB0byBbT0FVVEgtV0ddDQpsaXN0IGJ5IEJyZW50IEdvbGRtYW4sIEZhY2Vib29r IG9uIDMvMTEvMjAxMCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo2LjBwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcu NHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4w cHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFu DQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5UaGUg RGV2aWNlIFByb2ZpbGUgaXMNCnN1aXRhYmxlIHdoZW4gdGhlIGNsaWVudCBpcyBhIGRldmljZSB3 aGljaCBkb2VzIG5vdCBoYXZlIGFuIGVhc3kgZGF0YSBlbnRyeQ0KbWV0aG9kIChlLmcuLCBnYW1l IGNvbnNvbGVzIG9yIGVudGVydGFpbm1lbnQgY2VudGVycyksIGJ1dCB3aGVyZSB0aGUgZW5kIHVz ZXINCmhhcyBhY2Nlc3MgdG8gYSBzZXBhcmF0ZSBjb21wdXRlciB3aXRoIHNpbXBsZSBkYXRhIGVu dHJ5IG1ldGhvZHMgKGUuZy4sIHRoZWlyDQpob21lIGNvbXB1dGVyLCBhIGxhcHRvcCwgb3IgYSBz bWFydHBob25lKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWJvdHRvbTo2LjBwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0 IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQg NTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5QcmlvciB0 byBtYWtpbmcgYSByZXF1ZXN0DQp1c2luZyB0aGlzIHByb2ZpbGUsIHRoZSBjbGllbnQgTVVTVCBo YXZlIG9idGFpbmVkIGEgY2xpZW50IGlkZW50aWZpZXIgZnJvbSB0aGUNCmF1dGhvcml6YXRpb24g c2VydmVyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbGluZS1oZWlnaHQ6MTQuNHB0O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgz LjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMu OHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PHNwYW4NCnN0eWxl PSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7bXNvLWJpZGktZm9udC13ZWlnaHQ6DQpib2xkJz49PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhlaWdodDox NC40cHQ7dGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0 LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUu NHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpBcmlhbCc+NC4gVXNl DQpjYXNlcyBvZiB0aGUgZHJhZnQgPGkgc3R5bGU9J21zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFs Jz5UaGUgT0F1dGggMi4wIFByb3RvY29sPC9pPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo2LjBwdDt0YWItc3RvcHM6 NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2 LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcu MHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4oZHJhZnQgPGENCmhyZWY9Imh0dHA6Ly9naXRodWIuY29tL3RoZVJhem9y QmxhZGUvZHJhZnQtaWV0Zi1vYXV0aC9yYXcvbWFzdGVyL2RyYWZ0LWlldGYtb2F1dGgudHh0Ij5o dHRwOi8vZ2l0aHViLmNvbS90aGVSYXpvckJsYWRlL2RyYWZ0LWlldGYtb2F1dGgvcmF3L21hc3Rl ci9kcmFmdC1pZXRmLW9hdXRoLnR4dDwvYT4NCmF1dGhvcmVkIGJ5IEUuIEhhbW1lci1MYWhhdiwg RWQuLCBZYWFob28hLCBELiBSZWNvcmRvbiwgRmFjZWJvb2ssIGFuZCBELiBIYXJkdCwNCk1pY3Jv c29mdCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbTo2LjBwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4y cHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhw dCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5UaGUgc3BlY2lmaWNh dGlvbiBkZWZpbmVzIGENCm51bWJlciBvZiBhdXRob3JpemF0aW9uIGZsb3dzIHRvIHN1cHBvcnQg ZGlmZmVyZW50IGNsaWVudCB0eXBlcyBhbmQgc2NlbmFyaW9zLiBUaGVzZQ0KYXV0aG9yaXphdGlv biBmbG93cyBjYW4gYmUgc2VwYXJhdGVkIGludG8gdGhyZWUgZ3JvdXBzOiB1c2VyIGRlbGVnYXRp b24gZmxvd3MNCndoZXJlIHRoZSBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBhbiBlbmQg dXNlciwgZW5kIHVzZXIgY3JlZGVudGlhbHMgZmxvd3MNCndoZXJlIHRoZSBjbGllbnQgdXNlcyB0 aGUgZW5kIHVzZXIncyBjcmVkZW50aWFscyBkaXJlY3RseSB0byBvYnRhaW4gYXV0aG9yaXphdGlv biwNCmFuZCBhdXRvbm9tb3VzIGZsb3dzIHdoZXJlIHRoZSBjbGllbnQgaXMgYWN0aW5nIGZvciBp dHNlbGYgKHRoZSBjbGllbnQgaXMgYWxzbw0KdGhlIHJlc291cmNlIG93bmVyKS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo2 LjBwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQu OHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40 cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxiDQpzdHlsZT0nbXNvLWJpZGktZm9udC13ZWln aHQ6bm9ybWFsJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiJD b3VyaWVyIE5ldyInPlVzZXIgRGVsZWdhdGlvbiBGbG93czxvOnA+PC9vOnA+PC9zcGFuPjwvYj48 L3A+DQoNCjx1bCBzdHlsZT0nbWFyZ2luLXRvcDowaW4nIHR5cGU9ZGlzYz4NCiA8bGkgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjYuMHB0O21zby1saXN0Omw1IGxldmVsMSBs Zm8yOw0KICAgICB0YWItc3RvcHM6bGlzdCAuNWluIGxlZnQgNDUuOHB0IDkxLjZwdCAxMzcuNHB0 IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQg NTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxiDQogICAg IHN0eWxlPSdtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwnPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KICAgICBmb250LWZhbWlseToiQ291cmllciBOZXciJz5XZWIgQ2FsbGJhY2sg RmxvdzxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L2xpPg0KPC91bD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tdG9wOjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 Ni4wcHQ7DQptYXJnaW4tbGVmdDouNWluO3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQg MTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1 MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PHNwYW4NCnN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlRoZSB3ZWIg Y2FsbGJhY2sgZmxvdyBpcyBhDQp1c2VyIGRlbGVnYXRpb24gZmxvdyBzdWl0YWJsZSBmb3IgY2xp ZW50cyBjYXBhYmxlIG9mIGludGVyYWN0aW5nIHdpdGggdGhlIGVuZA0KdXNlcidzIHVzZXItYWdl bnQgKHR5cGljYWxseSBhIHdlYiBicm93c2VyKSBhbmQgY2FwYWJsZSBvZiByZWNlaXZpbmcgY2Fs bGJhY2sNCnJlcXVlc3RzIGZyb20gdGhlIHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN Cjx1bCBzdHlsZT0nbWFyZ2luLXRvcDowaW4nIHR5cGU9ZGlzYz4NCiA8bGkgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjYuMHB0O21zby1saXN0Omw1IGxldmVsMSBsZm8yOw0K ICAgICB0YWItc3RvcHM6bGlzdCAuNWluIGxlZnQgNDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4y cHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhw dCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxiDQogICAgIHN0eWxl PSdtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Ow0KICAgICBmb250LWZhbWlseToiQ291cmllciBOZXciJz5XZWIgQ2xpZW50IEZsb3c8bzpw PjwvbzpwPjwvc3Bhbj48L2I+PC9saT4NCjwvdWw+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLXRvcDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjYuMHB0Ow0K bWFyZ2luLWxlZnQ6LjVpbjt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQg MjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1 NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5UaGUgV2ViIENsaWVudCBG bG93IGlzDQpzaW1pbGFyIHRvIHRoZSBXZWIgQ2FsbGJhY2sgRmxvdywgYnV0IGl0IGhhcyBkaWZm ZXJlbnQgc2VjdXJpdHkNCmNoYXJhY3RlcmlzdGljcy4gQ2xpZW50LXNpZGUgYXBwbGljYXRpb25z IGFyZSB0aG9zZSB0aGF0IGxpdmUgZW50aXJlbHkgaW4NCkphdmFTY3JpcHQsIG9uIHRoZSBkZXNr dG9wLCBvbiBhIG1vYmlsZSBkZXZpY2UsIG9yIGluIG90aGVyIGVudmlyb25tZW50cyB3aGVyZSB0 aGUNCmNvZGUgZG9lcyBub3QgaGF2ZSBlYXN5IGFjY2VzcyB0byBhIHNlcnZlci48c3BhbiBzdHls ZT0nbXNvLXNwYWNlcnVuOnllcyc+oA0KPC9zcGFuPlRoZXNlIGFwcGxpY2F0aW9ucyBoYXZlIHRo ZSBhYmlsaXR5IHRvIGRpc3BsYXkgYSB3ZWIgcGFnZSB0byB0aGUgdXNlciwNCmJ1dCBjYW5ub3Qg cmVjZWl2ZSB0aGUgcmVzcG9uc2Ugb24gYSBzZXJ2ZXIuPHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1 bjp5ZXMnPqANCjwvc3Bhbj5CZWNhdXNlIHRoZSBlbnRpcmV0eSBvZiB0aGUgY2xpZW50IGlzIGRv d25sb2FkZWQgdG8gdGhlIHJlc291cmNlIG93bmVyJ3MNCnVzZXItYWdlbnQsIGl0IGlzIG5vdCBw b3NzaWJsZSB0byBjb21wbGV0ZWx5IHByb3RlY3QgdGhlIGNsaWVudCBzZWNyZXQuPHNwYW4NCnN0 eWxlPSdtc28tc3BhY2VydW46eWVzJz6gIDwvc3Bhbj5UaGlzIGZsb3cgYWxsb3dzIGZvciBhdXRo b3JpemF0aW9uIHdoaWxlDQp0YWtpbmcgdGhvc2Ugc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW50 byBhY2NvdW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHVsIHN0eWxlPSdtYXJnaW4tdG9w OjBpbicgdHlwZT1kaXNjPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206Ni4wcHQ7bXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzI7DQogICAgIHRhYi1zdG9wczpsaXN0IC41 aW4gbGVmdCA0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIw LjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEu MnB0IDY4Ny4wcHQgNzMyLjhwdCc+PGINCiAgICAgc3R5bGU9J21zby1iaWRpLWZvbnQtd2VpZ2h0 Om5vcm1hbCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQogICAgIGZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPkRldmljZSBGbG93PG86cD48L286cD48L3NwYW4+PC9iPjwvbGk+DQo8 L3VsPg0KDQo8cHJlIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz5UaGUgRGV2aWNlIEZsb3cgaXMg c3VpdGFibGUgd2hlbiB0aGUgY2xpZW50IGlzIGEgZGV2aWNlIHdoaWNoIGRvZXMgbm90IGhhdmUg YW4gZWFzeSBkYXRhLWVudHJ5IG1ldGhvZCAoZS5nLiBnYW1lIGNvbnNvbGVzIG9yPHNwYW4gc3R5 bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqCgIDwvc3Bhbj5lbnRlcnRhaW5tZW50IGNlbnRlcnMpLCBi dXQgd2hlcmUgdGhlIGVuZC11c2VyIGhhcyBhY2Nlc3MgdG8gYSBzZXBhcmF0ZSBjb21wdXRlciB3 aXRoIHNpbXBsZSBkYXRhLWVudHJ5IG1ldGhvZHMgKGUuZy4gdGhlaXIgaG9tZSBjb21wdXRlciwg YSBsYXB0b3Agb3IgYSBzbWFydHBob25lKS48L3ByZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjYuMHB0O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQg MTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1 MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PGINCnN0eWxl PSdtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5Og0KIkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9iPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjYuMHB0 O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQg MzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2 NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PGINCnN0eWxlPSdtc28tYmlkaS1mb250LXdlaWdodDpu b3JtYWwnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIkNvdXJp ZXIgTmV3Iic+RW5kIFVzZXIgQ3JlZGVudGlhbHMgRmxvd3M8bzpwPjwvbzpwPjwvc3Bhbj48L2I+ PC9wPg0KDQo8dWwgc3R5bGU9J21hcmdpbi10b3A6MGluJyB0eXBlPWRpc2M+DQogPGxpIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo2LjBwdDttc28tbGlzdDpsNSBsZXZlbDEg bGZvMjsNCiAgICAgdGFiLXN0b3BzOmxpc3QgLjVpbiBsZWZ0IDQ1LjhwdCA5MS42cHQgMTM3LjRw dCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0 IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48Yg0KICAg ICBzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCiAgICAgZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+VXNlcm5hbWUgYW5k IFBhc3N3b3JkIEZsb3c8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9saT4NCjwvdWw+DQoNCjxwcmUg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPlRoaXMgZmxvdyBpcyB1c2VkIHdoZW4gdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGdlbmVyYWxseSB0cnVzdHMgdGhlIGNsaWVudCB0byB0ZW1wb3Jhcmls eSBjb2xsZWN0IHRoZSBlbmQtdXNlcidzIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBhbmQgaXQgaXMg aW1wb3NzaWJsZSB0byB1c2Ugb25lIG9mIHRoZSBvdGhlciBhdXRob3JpemF0aW9uIGZsb3dzLiBU aGlzIGZsb3cgZW5hYmxlcyBhIGNsaWVudCB0byBhY3Qgb24gYmVoYWxmIG9mIHRoZSByZXNvdXJj ZSBvd25lciB3aXRob3V0IGhhdmluZyB0byBwZXJtYW5lbnRseSBzdG9yZSB0aGVpciB1c2VybmFt ZSBhbmQgcGFzc3dvcmQuIFRoaXMgZmxvdyBhbHNvIGVuYWJsZXMgY2xpZW50cyB3aG8gcHJldmlv dXNseSB1c2VkIHVzZXJuYW1lIGFuZCBwYXNzd29yZCB0byBwZXJmb3JtIGEgY29udmVyc2lvbiB0 byB0b2tlbiBiYXNlZCBjcmVkZW50aWFscy48L3ByZT48cHJlDQpzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjYuMHB0O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgz LjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMu OHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PGINCnN0eWxlPSdt c28tYmlkaS1mb250LXdlaWdodDpub3JtYWwnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5Og0KIkNvdXJpZXIgTmV3Iic+QXV0b25vbW91cyBDbGllbnQgRmxvd3M8bzpw PjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KDQo8dWwgc3R5bGU9J21hcmdpbi10b3A6MGluJyB0eXBl PWRpc2M+DQogPGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo2LjBwdDtt c28tbGlzdDpsNSBsZXZlbDEgbGZvMjsNCiAgICAgdGFiLXN0b3BzOmxpc3QgLjVpbiBsZWZ0IDQ1 LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40 cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBw dCA3MzIuOHB0Jz48Yg0KICAgICBzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCiAgICAgZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Q2xpZW50IENyZWRlbnRpYWxzIEZsb3c8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9saT4N CjwvdWw+DQoNCjxwcmUgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPlRoaXMgZmxvdyBpcyBzdWl0 YWJsZSB3aGVuIHRoZSBjbGllbnQgYWN0cyBhdXRvbm9tb3VzbHkgaW4gc2Vla2luZyBhY2Nlc3Mg YW5kIGlzIHRodXMgbm90IGFjY2Vzc2luZyBwcm90ZWN0ZWQgcmVzb3VyY2VzIHdpdGhpbiB0aGUg Y29udGV4dCBvZiBhIGdpdmVuIGVuZC11c2VyLjxzcGFuIHN0eWxlPSdtc28tc3BhY2VydW46eWVz Jz6gIDwvc3Bhbj5Gb3IgZXhhbXBsZSwgd2hlbiBhIGNsaWVudCBpcyBhY2Nlc3Npbmc8c3BhbiBz dHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+oKAgPC9zcGFuPm5vbi1wcml2YXRlIGRhdGEgb3IgbW9k aWZ5aW5nIGRhdGEgYWJvdXQgaXRzZWxmLjxzcGFuIHN0eWxlPSdtc28tc3BhY2VydW46eWVzJz6g IDwvc3Bhbj5UaGlzIGZsb3cgU0hPVUxEIE5PVCBiZSB1c2VkIHdoZW4gdGhlIGNsaWVudCBpcyBh Y3Rpbmcgb24gYmVoYWxmIG9mIGFuIGVuZC11c2VyLjwvcHJlPg0KDQo8dWwgc3R5bGU9J21hcmdp bi10b3A6MGluJyB0eXBlPWRpc2M+DQogPGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWJvdHRvbTo2LjBwdDttc28tbGlzdDpsNSBsZXZlbDEgbGZvMjsNCiAgICAgdGFiLXN0b3BzOmxp c3QgLjVpbiBsZWZ0IDQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0Ljhw dCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0 IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48Yg0KICAgICBzdHlsZT0nbXNvLWJpZGktZm9udC13 ZWlnaHQ6bm9ybWFsJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCiAgICAgZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+U0FNTCBBc3NlcnRpb24gRmxvdzxvOnA+PC9vOnA+PC9zcGFu PjwvYj48L2xpPg0KPC91bD4NCg0KPHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+VGhlIFNB TUwgYXNzZXJ0aW9uIGZsb3cgcmVxdWlyZXMgdGhlIGNsaWVudCB0byBvYnRhaW4gYSBTQU1MIGFz c2VydGlvbiBmcm9tIGFuIGFzc2VydGlvbiBpc3N1ZXIgcHJpb3IgdG8gaW5pdGlhdGluZyB0aGlz IGZsb3cuIFRoZSBwcm9jZXNzIGluIHdoaWNoIHRoZSBhc3NlcnRpb24gaXMgb2J0YWluZWQgaXMg ZGVmaW5lZCBieSB0aGUgYXNzZXJ0aW9uIGlzc3VlciBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyLCBhbmQgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uPC9wcmU+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo2LjBwdDt0YWItc3Rv cHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQg MzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2 ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0O3RhYi1zdG9wczo0NS44 cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0 IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQg NzMyLjhwdCc+PGI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPjUuIFVzZQ0KY2FzZXMgb2YgdGhlIGRyYWZ0 IDxpIHN0eWxlPSdtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCc+RXZhbHVhdGluZyBPQVVUSCdz DQpzdWl0YWJpbGl0eSBmb3IgU0lQIGF1dGhlbnRpY2F0aW9uPC9pPjwvc3Bhbj48L2I+PGkgc3R5 bGU9J21zby1iaWRpLWZvbnQtc3R5bGU6DQpub3JtYWwnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiA8L3NwYW4+PC9pPjxiPjxzcGFuDQpz dHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsJz48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcu NHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4w cHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFu DQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4oZHJh ZnQtYmVjay1vYXV0aC1zaXAtZXZhbC0wMA0KYXV0aG9yZWQgYnkgV29sZmdhbmcgQmVjaywgRGV1 dHNjaGUgVGVsZWtvbSBBRzsgcHVibGlzaGVkIG9uIE9jdG9iZXIgMTksIDIwMDkpPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8dWwgc3R5bGU9J21hcmdpbi10b3A6MGluJyB0eXBlPWRpc2M+DQog PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo2LjBwdDttc28tbGlzdDps NSBsZXZlbDEgbGZvMjsNCiAgICAgdGFiLXN0b3BzOmxpc3QgLjVpbiBsZWZ0IDQ1LjhwdCA5MS42 cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJw dCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0 Jz48Yg0KICAgICBzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCiAgICAgZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+RXN0 YWJsaXNobWVudCBvZiBhbiBNU1JQIHNlc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9saT4N CjwvdWw+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLXRvcDowaW47bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjYuMHB0Ow0KbWFyZ2luLWxlZnQ6LjI1aW47dGFiLXN0 b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0 IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQg Njg3LjBwdCA3MzIuOHB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+U29tZSB3ZWIgc2l0ZXMgaW1wbGVtZW50DQp0ZXh0IGNoYXQgdXNp bmcgYXN5bmNocm9ub3VzIEhUVFAgcmVxdWVzdHMgKDxzdDE6Q2l0eSB3OnN0PSJvbiI+PHN0MTpw bGFjZQ0KIHc6c3Q9Im9uIj5BSkFYPC9zdDE6cGxhY2U+PC9zdDE6Q2l0eT4pLiBUbyBjb25uZWN0 IHN1Y2ggd2ViIHNpdGVzIHRvIFNJUA0KZW52aXJvbm1lbnRzIHdpdGggU0lQL01TUlA8c3BhbiBz dHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+oKAgPC9zcGFuPihzZWUNCltSRkM0OTc1XSkgY2xpZW50 cywgYSBnYXRld2F5IGNhbiB1c2UgT0FVVEguPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi10b3A6MGluO21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo2LjBwdDsNCm1hcmdpbi1sZWZ0Oi4yNWluO3RhYi1zdG9wczo0NS44cHQgOTEu NnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4y cHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhw dCc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPjxzcGFuDQpzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+oKAgPC9zcGFuPjEuPHNwYW4gc3R5 bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqANCjwvc3Bhbj5UaGUgdXNlciBsb2dzIGludG8gYSB3ZWIg c2l0ZSBhbmQgdGhlIGJyb3dzZXIgbG9hZHMgdGhlIGVtYmVkZGVkIEphdmFTY3JpcHQNCmNvZGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1sZWZ0Oi4yNWluO2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAx MzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1 OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48 c3Bhbg0Kc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqCgIDwvc3Bhbj4yLjxzcGFuIHN0eWxlPSdt c28tc3BhY2VydW46eWVzJz6gDQo8L3NwYW4+VGhlIHdlYiBzaXRlJ3MgT0FVVEggY2xpZW50IGlu aXRpYXRlcyBhbiBPQVVUSCBleGNoYW5nZSB3aXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluO2xpbmUtaGVpZ2h0OjE0 LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQu OHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40 cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz50aGUgdXNlcidzIHByZWZlcnJlZCBTSVANCnBy b3ZpZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouMjVpbjtsaW5lLWhlaWdodDoxNC40cHQ7dGFiLXN0b3BzOjQ1LjhwdCA5 MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEy LjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIu OHB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+PHNwYW4NCnN0eWxlPSdtc28tc3BhY2VydW46eWVzJz6goCA8L3NwYW4+My48c3BhbiBz dHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+oA0KPC9zcGFuPlRoZSB3ZWIgc2l0ZSByZWRpcmVjdHMg dGhlIHVzZXIncyBicm93c2VyIHRvIHRoZSBhdXRoZW50aWNhdGlvbiB3ZWIgcGFnZQ0Kb2YgdGhl IFNJUCBwcm92aWRlcidzIE9BVVRIIHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjI1aW47bGluZS1oZWlnaHQ6MTQu NHB0O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44 cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRw dCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxzcGFuDQpzdHlsZT0nbXNvLXNwYWNlcnVuOnll cyc+oKAgPC9zcGFuPjQuPHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqANCjwvc3Bhbj5U aGUgdXNlciBlbnRlcnMgaGVyIGNyZWRlbnRpYWxzLiA8c3Bhbg0Kc3R5bGU9J21zby1zcGFjZXJ1 bjp5ZXMnPqA8L3NwYW4+VGhlIE9BVVRIIHNlcnZlciByZWRpcmVjdHMgaGVyIHRvIHRoZSB3ZWIN CnNpdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1sZWZ0Oi4yNWluO2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkx LjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIu MnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44 cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz48c3Bhbg0Kc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqCgIDwvc3Bhbj41LjxzcGFuIHN0 eWxlPSdtc28tc3BhY2VydW46eWVzJz6gDQo8L3NwYW4+VGhlIHdlYiBzaXRlIHRyYW5zbGF0ZXMg dGhlIHRleHQgY2hhdC1yZWxhdGVkIEhUVFAgcmVxdWVzdHMgaW50byBTSVAgYW5kDQpNU1JQLjxz cGFuIHN0eWxlPSdtc28tc3BhY2VydW46eWVzJz6gIDwvc3Bhbj5JdCBhZGRzIE9BVVRIIHRva2Vu IGNyZWRlbnRpYWxzIHRvDQp0aGUgU0lQIHJlcXVlc3RzIGl0IHNlbmRzIHRvd2FyZHMgdGhlIHVz ZXIncyBwcmVmZXJyZWQgU0lQIHByb3ZpZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhlaWdodDoxNC40cHQ7dGFiLXN0b3BzOjQ1Ljhw dCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQg NDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3 MzIuOHB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluO2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6 NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2 LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcu MHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz5BZnRlciB0aGlzLCB0aGUgT0FVVEggc2VydmVyDQpjaGVja3MgdGhlIHRv a2VuIGNyZWRlbnRpYWxzIGZvciB2YWxpZGl0eSBhbmQgY2hlY2tzIGlmIHRoZSBTSVAgcmVxdWVz dA0KY29tcGxpZXMgdG8gdGhlIHBvbGljeSB0aGUgdXNlciBoYXMgZ3JhbnRlZCBmb3IgdGhpcyBr aW5kIG9mIHRyYW5zYWN0aW9uLjxzcGFuDQpzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+oCA8L3Nw YW4+SWYgdGhlIFNJUCByZXF1ZXN0IHBhc3NlcyBhbGwgY2hlY2tzLCB0aGUNCk9BVVRIIHNlcnZl ciBmb3J3YXJkcyBpdCB0byB0aGUgc3Vic2VxdWVudCBTSVAgbm9kZXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8dWwgc3R5bGU9J21hcmdpbi10b3A6MGluJyB0eXBlPWRpc2M+DQogPGxpIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo2LjBwdDttc28tbGlzdDpsNSBsZXZl bDEgbGZvMjsNCiAgICAgdGFiLXN0b3BzOmxpc3QgLjVpbiBsZWZ0IDQ1LjhwdCA5MS42cHQgMTM3 LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTgu MHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48Yg0K ICAgICBzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsNCiAgICAgZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+R2F0ZXdheSBm b3IgYnJvd3Nlci1iYXNlZCBWb0lQIGFwcGxldHM8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9saT4N CjwvdWw+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjI1aW47bGlu ZS1oZWlnaHQ6MTQuNHB0O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAy MjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0 OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PHNwYW4NCnN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkEgbnVtYmVyIG9mIHRlY2hu b2xvZ2llcw0KZXhpc3QgdG8gaW1wbGVtZW50IFZvSVAgY2xpZW50cyBhcyBicm93c2VyIGFwcGxl dHMuIFRvIGtlZXAgYXBwbGV0IGxvYWRpbmcNCnRpbWVzIGxvdywgdmVuZG9ycyBkb24ndCBpbXBs ZW1lbnQgc3RhbmRhcmQgU0lQLCBidXQgdXNlIHN0cmlwcGVkLWRvd24gdmFyaWFudHMNCm9yIHBy b3ByaWV0YXJ5IHRlY2hub2xvZ3kuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluO2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWIt c3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42 cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJw dCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjI1aW47bGluZS1oZWlnaHQ6MTQuNHB0 O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQg MzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2 NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjEuIFRoZSB1c2VyIGxvZ3MgaW50byBhIHdlYg0Kc2l0 ZSBhbmQgdGhlIGJyb3dzZXIgbG9hZHMgdGhlIGVtYmVkZGVkIFZvSVAgYXBwbGV0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou MjVpbjtsaW5lLWhlaWdodDoxNC40cHQ7dGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAx ODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUw My44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48c3Bhbg0Kc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Mi48c3Bhbg0K c3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqAgPC9zcGFuPlRoZSB3ZWIgc2l0ZSdzIE9BVVRIIGNs aWVudCBpbml0aWF0ZXMgYW4NCk9BVVRIIGV4Y2hhbmdlIHdpdGggdGhlIHVzZXIncyBwcmVmZXJy ZWQgU0lQIHByb3ZpZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouMjVpbjtsaW5lLWhlaWdodDoxNC40cHQ7dGFiLXN0b3Bz OjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2 Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3 LjBwdCA3MzIuOHB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+My48c3Bhbg0Kc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqAgPC9zcGFu PlRoZSB3ZWIgc2l0ZSByZWRpcmVjdHMgdGhlIHVzZXIncyBicm93c2VyIHRvDQp0aGUgYXV0aGVu dGljYXRpb24gd2ViIHBhZ2Ugb2YgdGhlIFNJUCBwcm92aWRlcidzIE9BVVRIIHNlcnZlci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjI1aW47bGluZS1oZWlnaHQ6MTQuNHB0O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40 cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBw dCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PHNwYW4N CnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjQuPHNw YW4NCnN0eWxlPSdtc28tc3BhY2VydW46eWVzJz6gIDwvc3Bhbj5UaGUgdXNlciBlbnRlcnMgaGVy IGNyZWRlbnRpYWxzLjxzcGFuDQpzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+oCA8L3NwYW4+VGhl IE9BVVRIIHNlcnZlciByZWRpcmVjdHMgaGVyIHRvIHRoZSB3ZWINCnNpdGUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWlu O2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4y cHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhw dCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz41LjxzcGFuDQpzdHls ZT0nbXNvLXNwYWNlcnVuOnllcyc+oCA8L3NwYW4+VGhlIHdlYiBzaXRlIHRyYW5zbGF0ZXMgdGhl IHdlYiBhcHBsZXRzDQptZXNzYWdlcyBpbnRvIFNJUCBhbmQgUlRQLjxzcGFuIHN0eWxlPSdtc28t c3BhY2VydW46eWVzJz6gIDwvc3Bhbj5JdCBhZGRzIE9BVVRIDQp0b2tlbiBjcmVkZW50aWFscyB0 byB0aGUgU0lQIHJlcXVlc3RzIGl0IHNlbmRzIHRvd2FyZHMgdGhlIHVzZXIncyBwcmVmZXJyZWQg U0lQDQpwcm92aWRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjI1aW47bGluZS1oZWlnaHQ6MTQuNHB0O3RhYi1zdG9wczo0 NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYu NHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4w cHQgNzMyLjhwdCc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouMjVpbjtsaW5lLWhlaWdodDoxNC40cHQ7dGFiLXN0 b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0 IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQg Njg3LjBwdCA3MzIuOHB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+QWZ0ZXIgdGhpcywgdGhlIE9BVVRIIHNlcnZlcg0KY2hlY2tzIHRo ZSB0b2tlbiBjcmVkZW50aWFscyBmb3IgdmFsaWRpdHkgYW5kIGNoZWNrcyBpZiB0aGUgU0lQIHJl cXVlc3QNCmNvbXBsaWVzIHRvIHRoZSBwb2xpY3kgdGhlIHVzZXIgaGFzIGdyYW50ZWQgZm9yIHRo aXMga2luZCBvZiB0cmFuc2FjdGlvbi48c3Bhbg0Kc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqAg PC9zcGFuPklmIHRoZSBTSVAgcmVxdWVzdCBwYXNzZXMgYWxsIGNoZWNrcywgdGhlDQpPQVVUSCBz ZXJ2ZXIgZm9yd2FyZHMgaXQgdG8gdGhlIHN1YnNlcXVlbnQgU0lQIG5vZGVzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhlaWdodDoxNC40 cHQ7dGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0Ljhw dCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0 IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0O3RhYi1z dG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZw dCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0 IDY4Ny4wcHQgNzMyLjhwdCc+PGI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1i aWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPjYuIFVzZQ0KY2FzZXMgb2Yg dGhlIGRyYWZ0IDxpIHN0eWxlPSdtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCc+T0F1dGggQWNj ZXNzIFRva2Vucw0KdXNpbmcgY3JlZGVudGlhbHM8bzpwPjwvbzpwPjwvaT48L3NwYW4+PC9iPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhlaWdodDoxNC40cHQ7dGFiLXN0 b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0 IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQg Njg3LjBwdCA3MzIuOHB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+KGRyYWZ0LWRlaG9yYS1mYXJyZWxsLW9hdXRoLWFjY2Vzc3Rva2Vu LWNyZWRzLTAyDQphdXRob3JlZCBieSBCLiBkZSBoT3JhLCBhbmQgUy4gRmFycmVsbCwgTmV3QmF5 IFNvZnR3YXJlOyBwdWJsaXNoZWQgb24gRmVicnVhcnkNCjI0LCAyMDEwKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhlaWdodDoxNC40cHQ7 dGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAz MjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0 MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+VGhlIHVzZSBjYXNlcyB3aGVyZSBvbmUgb3INCmJvdGgg b2YgdGhlIGZvbGxvd2luZyBzaXR1YXRpb25zIGFwcGx5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHVsIHN0eWxlPSdtYXJnaW4tdG9wOjBpbicgdHlwZT1kaXNjPg0KIDxsaSBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdDttc28tbGlzdDpsNSBsZXZlbDEgbGZvMjsN CiAgICAgdGFiLXN0b3BzOmxpc3QgLjVpbiBsZWZ0IDQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMu MnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44 cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48c3Bhbg0KICAgICBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5UaGUgVXNl ciBpcyB1c2luZyBhDQogICAgIGRldmljZSB0aGF0IGNhbm5vdCBwbGF5IHRoZSBIVFRQIHJlLWRp cmVjdCBnYW1lIG5vcm1hbGx5IHBsYXllZCBpbiB0aGUNCiAgICAgJnF1b3Q7My1sZWdnZWQmcXVv dDsgT0F1dGggbW9kZWw8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPg0KIDxsaSBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdDttc28tbGlzdDpsNSBsZXZlbDEgbGZvMjsNCiAg ICAgdGFiLXN0b3BzOmxpc3QgLjVpbiBsZWZ0IDQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0 IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQg NTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48c3Bhbg0KICAgICBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5UaGUgQ29uc3Vt ZXIgaXMgYW4NCiAgICAgYWdncmVnYXRvciB0aGF0IHdpbGwgaW4gYW55IGNhc2UsIGJlIHByZXNl bnRlZCB3aXRoIHRoZSBjcmVkZW50aWFscyBvZiB0aGUNCiAgICAgZW5kLXVzZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPg0KPC91bD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhl aWdodDoxNC40cHQ7dGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4w cHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZw dCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpBcmlhbDttc28t YmlkaS1mb250LXdlaWdodDoNCmJvbGQnPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3Rv cHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQg MzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2 ODcuMHB0IDczMi44cHQnPjxiPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlk aS1mb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz43LiBVc2UNCmNhc2VzIG9mIHRo ZSBkcmFmdCBVc2luZyA8aSBzdHlsZT0nbXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwnPk9BdXRo IGZvcg0KUmVjdXJzaXZlIERlbGVnYXRpb248L2k+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiJDb3VyaWVyIE5ldyInPiA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0 O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQg MzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2 NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPihkcmFmdC12cmFuY2tlbi1vYXV0aC1yZWRlbGVnYXRp b24tMDENCmF1dGhvcmVkIGJ5IEIuIFZyYW5ja2VuLCBaLiBaZWx0c2FuOyBwdWJsaXNoZWQgaW4g RmVicnVhcnkgMjAxMCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjx1bCBzdHlsZT0nbWFyZ2lu LXRvcDowaW4nIHR5cGU9ZGlzYz4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhl aWdodDoxNC40cHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzY7DQogICAgIHRhYi1zdG9wczpsaXN0 IC41aW4gbGVmdCA0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQg MzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2 NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PGI+PHNwYW4NCiAgICAgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpBcmlhbCc+Q29udGVu dA0KICAgICBzaGFyaW5nPG86cD48L286cD48L3NwYW4+PC9iPjwvbGk+DQo8L3VsPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluO2xpbmUtaGVpZ2h0OjE0LjRw dDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0 IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQg NjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz5UaGUgT0F1dGggcHJvdG9jb2wgcHJvdmlkZXMNCmEg bWV0aG9kIGZvciBzZXJ2ZXJzIHRvIGFsbG93IHRoaXJkLXBhcnR5IGFjY2VzcyB0byBwcm90ZWN0 ZWQgcmVzb3VyY2VzIHdpdGhvdXQNCmZvcmNpbmcgdGhlaXIgZW5kLXVzZXJzIHRvIHJldmVhbCB0 aGVpciBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscy48c3Bhbg0Kc3R5bGU9J21zby1zcGFjZXJ1 bjp5ZXMnPqAgPC9zcGFuPlRoaXMgbWV0aG9kIGNhbiBiZSBlbXBsb3llZCB0byBzdXBwb3J0DQpv cmdhbml6aW5nIGFuZCBzaGFyaW5nIGluZm9ybWF0aW9uIGFtb25nIHRoZSBlbmQtdXNlcnMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0Oi4yNWluO2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcu NHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4w cHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFu DQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5Gb3Ig ZXhhbXBsZSwgYSBXZWIgdXNlcg0KKFJlc291cmNlIE93bmVyKSBjYW4gZ3JhbnQgZGF0YSBhY2Nl c3MgdG8gYSBwcmUtZGVmaW5lZCBzZXQgb2YgdXNlcnMuPHNwYW4NCnN0eWxlPSdtc28tc3BhY2Vy dW46eWVzJz6gIDwvc3Bhbj5UaGlzIGNhbiBiZSBkb25lIHdpdGggdGhlIHVzZSBvZiBhIHNwZWNp YWwgT0F1dGgNCkNsaWVudCAtIGNvbnRlbnQgbWFuYWdlciAtIHdoaWNoIHNlcnZlcyBhcyBhIHBy b3h5IGJldHdlZW4gdGhlIGVuZC11c2VycyBhbmQNCnRoZSBXZWIgc2VydmVycyB0aGF0IGhvc3Qg dGhlIHJlc291cmNlcyByZWxhdGVkIHRvIHRoZSBwcm9qZWN0LjxzcGFuDQpzdHlsZT0nbXNvLXNw YWNlcnVuOnllcyc+oCA8L3NwYW4+VGhlIGNvbnRlbnQgbWFuYWdlciBhbGxvd3MgYSB1c2VyICh0 aGUgb3duZXINCm9mIHRoZSByZXNvdXJjZXMpIHRvIHNwZWNpZnkgYSBzZXQgb2YgdGhlIHJlc291 cmNlcyByZWxhdGVkIHRvIGEgcHJvamVjdCAoZS5nLiwNCmJ5IHRhZ2dpbmcpIGFuZCBhIHNldCBv ZiB0aGUgdXNlcnMgYW5kIHRoZWlyIGFjY2VzcyByaWdodHMgaW4gcmVzcGVjdCB0byB0aGUNCnJl c291cmNlcy48c3BhbiBzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+oCA8L3NwYW4+VGhlIGNvbnRl bnQgbWFuYWdlciBtYXkgYWxzbw0KZW5hYmxlIHNlYXJjaGluZyBvZiB0aGUgcmVsYXRlZCBtYXRl cmlhbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4y cHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhw dCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQoNCjx1bCBzdHlsZT0nbWFyZ2luLXRvcDowaW4nIHR5cGU9ZGlzYz4N CiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhlaWdodDoxNC40cHQ7bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzY7DQogICAgIHRhYi1zdG9wczpsaXN0IC41aW4gbGVmdCA0NS44cHQgOTEu NnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4y cHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhw dCc+PGI+PHNwYW4NCiAgICAgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTpBcmlhbCc+QWRkaXRpb25hbA0KICAgICBleGFtcGxlPG86 cD48L286cD48L3NwYW4+PC9iPjwvbGk+DQo8L3VsPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0Oi4yNWluO2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0 IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0 MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDcz Mi44cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz5BIFJlc291cmNlIE93bmVyIGRlbGVnYXRlcw0KdGhlIGFjY2VzcyByaWdodHMgb24g dGhlIHBob3RvZ3JhcGhzIHRvIGEgcHJpbnRpbmcgc2VydmljZSB2aWEgYSBjb250ZW50DQptYW5h Z2VyLjxzcGFuIHN0eWxlPSdtc28tc3BhY2VydW46eWVzJz6gIDwvc3Bhbj5FdmVuIGlmIHRoZSBw aG90b2dyYXBocyBhcmUgc3RvcmVkDQpvbiB0aGUgZGlmZmVyZW50IFdlYiBzZXJ2ZXJzLCB0aGUg Y29udGVudCBtYW5hZ2VyIGVuYWJsZXMgdGhlIHByaW50aW5nIHNlcnZpY2UNCnRvIGFjY2VzcyB0 aGVtIHdpdGhvdXQgZm9yY2luZyB0aGUgUmVzb3VyY2UgT3duZXIgdG8gcmVwZWF0IHRoZSBhdXRo b3JpemF0aW9uDQpwcm9jZWR1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZw dCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0 IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQn PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tdG9wOjcuNXB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo3 LjVwdDsNCm1hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDoxMy4wcHQnPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KbXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTpBcmlhbCc+OC4gVU1BIHVzZSBjYXNlcyA8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6NDUu OHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRw dCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0 IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz5UaGUgZXh0ZW5zaXZlIGluZm9ybWF0aW9uDQphYm91dCBVTUGScyB1c2UgY2Fz ZXMgaXMgYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbGluZS1oZWlnaHQ6MTQuNHB0O3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgz LjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMu OHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCc+PHNwYW4NCnN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxhDQpocmVmPSJo dHRwOi8va2FudGFyYWluaXRpYXRpdmUub3JnL2NvbmZsdWVuY2UvZGlzcGxheS91bWEvVU1BK1Nj ZW5hcmlvcythbmQrVXNlK0Nhc2VzIj5odHRwOi8va2FudGFyYWluaXRpYXRpdmUub3JnL2NvbmZs dWVuY2UvZGlzcGxheS91bWEvVU1BK1NjZW5hcmlvcythbmQrVXNlK0Nhc2VzPC9hPg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0 OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAy NzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5 NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5UaGUgc3VtbWFyaWVzIG9mIHR3byBvZiB0 aGUNCmdyb3VwJ3MgYXBwcm92ZWQgc2NlbmFyaW9zIGFyZSBhcyBmb2xsb3dzIChzdWJtaXR0ZWQg dG8gW09BVVRILVdHXSBsaXN0IGJ5IEV2ZQ0KTWFsZXIgb24gMi8zLzIwMTApOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHVsIHN0eWxlPSdtYXJnaW4tdG9wOjBpbicgdHlwZT1kaXNjPg0KIDxs aSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdDttc28tbGlzdDpsMiBs ZXZlbDEgbGZvNjsNCiAgICAgdGFiLXN0b3BzOmxpc3QgLjVpbiBsZWZ0IDQ1LjhwdCA5MS42cHQg MTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0 NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48 Yg0KICAgICBzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsNCiAgICAgZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Q2FsZW5k YXJpbmc8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQogICAgIDEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz46IE9ubGluZSBjYWxlbmRhcnMsIHdob3NlIGNvbnRlbnQg aXMNCiAgICAgdm9sYXRpbGUsIGFyZSB2YWx1YWJsZSB0byBzaGFyZSBvbiBhbiBvbmdvaW5nLyZx dW90O2ZlZWQmcXVvdDsgYmFzaXMuIDxzcGFuDQogICAgIHN0eWxlPSdtc28tc3BhY2VydW46eWVz Jz6gPC9zcGFuPkluIHNvbWV3aGF0IHRoZSBzYW1lIGZhc2hpb24gdGhhdCBwZW9wbGUNCiAgICAg dG9kYXkgc2hhcmUgb25saW5lIGNhbGVuZGFycyBzZWxlY3RpdmVseSB3aXRoIG90aGVyIHBlb3Bs ZSwgYSB1c2VyIGNhbg0KICAgICBzaGFyZSBhIGNhbGVuZGFyIHdpdGggYSB2ZW5kb3IgZm9yIHZh cmlvdXMgcHVycG9zZXMuPHNwYW4NCiAgICAgc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPqAgPC9z cGFuPlByaW9yIHRvIGFsbG93aW5nIHRoZSBhY2Nlc3MsIHNoZSBtaWdodA0KICAgICB1c2UgVU1B IHRvIHJlcXVpcmUgdGhlIHJlcXVlc3RlciB0byBhc3N1cmUgaGVyIHRoZXkgd2lsbCBub3QgbWlz dXNlIG9yDQogICAgIGZ1cnRoZXIgc2hhcmUgaGVyIGluZm9ybWF0aW9uLjxzcGFuIHN0eWxlPSdt c28tc3BhY2VydW46eWVzJz6gDQogICAgIDwvc3Bhbj5IYXZpbmcgYXV0aG9yaXplZCBhY2Nlc3Mg dG8gYSBwYXJ0aWN1bGFyIHJlc291cmNlLCB0aGUgdXNlciBjYW4NCiAgICAgdGhlbiBleGFtaW5l IGFsbCB0aGUgY29ubmVjdGlvbnMgZm9yZ2VkIHRvIGFsbCBoZXIgc2hhcmVkIHJlc291cmNlcyBp bg0KICAgICBzaW1pbGFyIGZhc2hpb24sIGZyb20gYSBzaW5nbGUgY29uc29sZS48bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPg0KPC91bD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhl aWdodDoxNC40cHQ7dGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4w cHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZw dCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVy Om5vbmU7Ym9yZGVyLWJvdHRvbTpkb3VibGUgd2luZG93dGV4dCAyLjI1cHQ7DQpwYWRkaW5nOjBp biAwaW4gMTQuMHB0IDBpbjttYXJnaW4tbGVmdDouMjVpbjttYXJnaW4tcmlnaHQ6MGluJz4NCg0K PHVsIHN0eWxlPSdtYXJnaW4tdG9wOjBpbicgdHlwZT1kaXNjPg0KIDxsaSBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluO2xpbmUtaGVpZ2h0OjE0LjRwdDttc28tbGlzdDps MiBsZXZlbDEgbGZvNjsNCiAgICAgdGFiLXN0b3BzOmxpc3QgLjVpbiBsZWZ0IDQ1LjhwdCA5MS42 cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJw dCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0 Ow0KICAgICBib3JkZXI6bm9uZTttc28tYm9yZGVyLWJvdHRvbS1hbHQ6ZG91YmxlIHdpbmRvd3Rl eHQgMi4yNXB0O3BhZGRpbmc6MGluOw0KICAgICBtc28tcGFkZGluZy1hbHQ6MGluIDBpbiAxNC4w cHQgMGluJz48YiBzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsJz48c3Bhbg0KICAg ICBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5QZXJz b25hbCBMb2FuOjwvc3Bhbj48L2I+PHNwYW4NCiAgICAgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+IEEgdXNlciBhcHBsaWVzIGZvciBhDQogICAgIGxv YW4gb25saW5lLCBhbmQgdGhlIGxvYW4gYXBwbGljYXRpb24gc2l0ZSByZXF1aXJlcyBoaW0gdG8g cHJvdmlkZSBjZXJ0YWluDQogICAgIHRoaXJkLXBhcnR5LWF0dGVzdGVkIGluZm9ybWF0aW9uLCBz dWNoIGFzIGhpcyBzYWxhcnksIGJhbmsgYWNjb3VudCwgYW5kDQogICAgIGNyZWRpdCBzY29yZS48 c3BhbiBzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+oCA8L3NwYW4+VGhpcyBpbmZvcm1hdGlvbiBp cw0KICAgICBiZXN0IGhvc3RlZCBkaXJlY3RseSBvdXQgb2YgdGhlIChzZXZlcmFsKSBhdXRob3Jp dGF0aXZlIHNpdGVzIGZvciBpdCwgYnV0DQogICAgIHRoZSB1c2VyIGlzIGFibGUgdG8gcGFja2Fn ZSB1cCByZWZlcmVuY2VzIHRvIGFsbCBvZiBpdCBhbmQgcG9pbnQgdGhlIGxvYW4NCiAgICAgc2l0 ZSB0byB0aGUgcGFja2FnZTsgdGhlIGxvYW4gc2l0ZSBjYW4gdGhlbiBiZWNvbWUgYSByZXF1ZXN0 ZXIgb2YgZWFjaA0KICAgICByZWxldmFudCByZXNvdXJjZS48c3BhbiBzdHlsZT0nbXNvLXNwYWNl cnVuOnllcyc+oCA8L3NwYW4+VGhlIHVzZXIgY2FuDQogICAgIHNlZSwgZnJvbSBhIHNpbmdsZSBw bGFjZSwgd2hldGhlciB0aGUgaW5mb3JtYXRpb24gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5DQogICAg IHJlY2VpdmVkLCBhbmQgY2FuIGtlZXAgYSByZWNvcmQgb2YgaXRzIGFjY2Vzcy48c3Bhbg0KICAg ICBzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+oCA8L3NwYW4+KFRoZSB3ZWJpbmFyIHdpcmVmcmFt ZXMgc2hvdyBob3cgdGhpcw0KICAgICBwYWNrYWdpbmcgbWlnaHQgYmUgYWNoaWV2ZWQsIGFsb25n IHdpdGggaWxsdXN0cmF0aW5nIG90aGVyIHBvdGVudGlhbCBwYXJ0cw0KICAgICBvZiB0aGUgdXNl ciBleHBlcmllbmNlLjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28t YmlkaS1mb250LXNpemU6DQogICAgIDEyLjBwdDtmb250LWZhbWlseTpBcmlhbCc+PG86cD48L286 cD48L3NwYW4+PC9iPjwvbGk+DQo8L3VsPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48 Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTpBcmlhbCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0 LWF1dG9zcGFjZTpub25lJz48Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJp ZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpBcmlhbCc+OS48L3NwYW4+PC9iPjxzcGFu DQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4gPC9z cGFuPjxiPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz5Vc2UgY2FzZQ0KZm9yIHNpZ25hdHVyZSB3aXRoIGFz eW1tZXRyaWMgc2VjcmV0PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsN CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1h dXRvc3BhY2U6bm9uZSc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPihzdWJtaXR0ZWQgdG8gW09BVVRILVdHXQ0KbGlzdCBieSBFcmFuIEhh bW1lci1MYWhhdiBvbiAyLzE4LzIwMTApPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3Nw YWNlOm5vbmUnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9u ZSc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPkEgc2VydmljZSBwcm92aWRlciBpcw0Kb2ZmZXJpbmcgYW4gQVBJIGZvciBpbmNvbWluZyBt ZXNzYWdlcy4gSXQgaXMgbm90IHBvc3NpYmxlIGZvciB0aGlzIHNlcnZpY2UgdG8NCnJlcXVpcmUg cHJlLXJlZ2lzdHJhdGlvbiBvZiBjbGllbnRzIGJlY2F1c2Ugb2YgdGhlIG51bWJlciBvZiBwb3Nz aWJsZSBjbGllbnRzLA0Kb3IgdGhlIHR5cGUgb2YgY2xpZW50cy4gSW4gdGhpcyBzY2VuYXJpbywg dGhlIHNlcnZlciBpcyBtb3N0IGxpa2VseSBhIHNtYWxsDQpzaXRlLCB3aGlsZSB0aGUgY2xpZW50 cyBhcmUgbGFyZ2UgcHJvdmlkZXJzLiBJdCBpcyBub3QgbGlrZWx5IHRoYXQgdGhlc2UgbGFyZ2UN CnByb3ZpZGVycyB3aWxsIGJvdGhlciB0byByZWdpc3RlciB3aXRoIHRoZSBzZXJ2ZXIuIEluIGFk ZGl0aW9uLCB0aGUgc2VydmVyDQptaWdodCB3YW50IHRvIG1haW50YWluIGEgd2hpdGUgb3IgYmxh Y2sgbGlzdCBvZiBhbGxvd2VkIGNsaWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0 b3NwYWNlOm5vbmUnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6 bm9uZSc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPlRoZSB3YXkgdGhpcyB3b3JrcyBpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1h dXRvc3BhY2U6bm9uZSc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFj ZTpub25lJz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+MS4gQ2xpZW50IG1ha2VzIGEgc2lnbmVkDQpyZXF1ZXN0IHRvIGRlbGl2ZXIgYSBt ZXNzYWdlIHRvIGEgdXNlciBvbiB0aGUgc2VydmVyLiBUaGUgcmVxdWVzdCBpcyBzaWduZWQNCnVz aW5nIHRoZSBjbGllbnQncyBwcml2YXRlIGtleSwgYW5kIGluY2x1ZGVzIHRoZSBhY2NvdW50IG9m IHRoZSBzZW5kZXIgd2hpY2ggaXMNCnVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBjbGllbnQgKGku ZS4gYWNjdDpqb2VAZXhhbXBsZS5jb20pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9z cGFjZTpub25lJz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Mi4gVGhlIHNlcnZlciByZWNlaXZlcyB0aGUNCm1lc3NhZ2UgYW5kIG9idGFp bnMgdGhlIGhvc3QtbWV0YSBkb2N1bWVudCBmb3IgZXhhbXBsZS5jb20gdXNpbmcgU1NML1RMUy4g VGhlDQpob3N0LW1ldGEgZG9jdW1lbnQgZWl0aGVyIGluY2x1ZGVzIHRoZSBjb3JyZXNwb25kaW5n IHB1YmxpYyBrZXkgZm9yIHRoZSBjbGllbnQNCihmb3IgdGhpcyBwdXJwb3NlKSBvciBsaW5rcyB0 byBvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuDQpz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4zLiBUaGUg c2VydmVyIHZlcmlmaWVzIHRoZQ0KcmVxdWVzdCBieSBjaGVja2luZyB0aGUgc2lnbmF0dXJlIHVz aW5nIHRoZSBwdWJsaWMga2V5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpu b25lJz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5U aGlzIGNhbiBiZSBtb2RpZmllZCB0bw0KaW5jbHVkZSBkZWxlZ2F0aW9uLCBpbiB3aGljaCB0aGUg Y2xpZW50IHVzZXMgYSBwcml2YXRlLWtleSBzaWduZWQgcmVxdWVzdCB0bw0Kb2J0YWluIGEgdG9r ZW4gd2l0aCB0aGUgdXN1YWwgZmxvd3MgaW52b2x2aW5nIGEgdXNlci4gVGhlIHB1cnBvc2Ugb2Yg dGhpcyBmbG93DQppcyB0byBhdm9pZCBjbGllbnQgcmVnaXN0cmF0aW9uIHdoaWxlIHN0aWxsIHZl cmlmeWluZyB0aGUgY2xpZW50J3MgaWRlbnRpdHkgYW5kDQpwb3RlbnRpYWxseSBhZ3JlZW1lbnQg dG8gdGVybXMgb2Ygc2VydmljZSAoYXNzdW1pbmcgdGhleSBjYW4gYmUgcmVwcmVzZW50ZWQgaW4N CmEgbWFjaGluZSByZWFkYWJsZSB3YXkgaW4gdGhlIGNsaWVudCdzIGhvc3QtbWV0YSBkb2N1bWVu dCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxheW91 dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4NCnN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlRoaXMgZmxvdyB1c2VzIFNT TC9UTFMgZm9yDQpvYnRhaW5pbmcgdGhlIGhvc3QtbWV0YSBkb2N1bWVudCAod2hpY2ggd2lsbCBs aWtlbHkgaW5jbHVkZSBtb3JlIHN0ZXBzIHRvDQp2ZXJpZnkgdHJ1c3QpLCBhcyB3ZWxsIGFzIGxp a2VseSB0byB1c2UgU1NML1RMUyBmb3IgbWFraW5nIEFQSSBjYWxscyB0bw0KbWFpbnRhaW4gbWVz c2FnZSBwcml2YWN5IGluIHRyYW5zaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3Nw YWNlOm5vbmUnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFj ZTpub25lJz48Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTpBcmlhbCc+MTAuIEENCnRva2VuIHVzZSBjYXNlIDxvOnA+ PC9vOnA+PC9zcGFuPjwvYj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxh eW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4NCnN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPihzdWJtaXR0ZWQgdG8g W09BVVRILVdHXQ0KbGlzdCBieSBHcmVnIEJyYWlsIG9uIDMvMjIvMjAxMCk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz5UaGVyZQ0KYXJlIEFQSXMgdGhhdCByZXF1aXJlIHRo YXQgdGhlICZxdW90O2FwcGxpY2F0aW9uJnF1b3Q7IG9yIGRldmljZSBiZQ0KYXV0aGVudGljYXRl ZCwgYnV0IG5vdCBuZWNlc3NhcmlseSB0aGUgaW5kaXZpZHVhbCB1c2VyLiBUaGlzIGhhcHBlbnMg aW4gbW9iaWxlDQphcHBzLCBmb3IgaW5zdGFuY2UgLS0gdGhlcmUgaXMgYSByZXF1aXJlbWVudCB0 byBpZGVudGlmeSB3aGljaCBtb2JpbGUgYXBwLA0KdmVyc2lvbiwgcGxhdGZvcm0sIGV0YywgaXMg bWFraW5nIEFQSSBjYWxscy4gSG93ZXZlciwgdGhlIGRhdGEgYmVpbmcgcmV0cmlldmVkDQppcyBu b3QgdGVycmlibHkgc2Vuc2l0aXZlIGFuZCBkb2VzIG5vdCByZXF1aXJlIHVzZXItbGV2ZWwgYXV0 aGVudGljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+VGhlDQpz dGFuZGFyZCB3YXkgdG8gaGFuZGxlIHRoaXMgaW4gdGhlIEFQSSB3b3JsZCB0b2RheSBpcyBieSB1 c2luZyB0aGUgJnF1b3Q7QVBJIGtleSZxdW90Ow0KcGF0dGVybiAtLSBhIHVuaXF1ZSBpZGVudGlm aWVyIGlzIGhhbmRlZCB0byBldmVyeSBhcHBsaWNhdGlvbiwgYnVyaWVkIGluIHRoZQ0KY29kZSBz b21ld2hlcmUsIGFuZCB1c2VkIG9uIGV2ZXJ5IEFQSSBjYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPlNvbWUNCnVzZXJzIG9mIEFQSXMgd2FudCBhIGxheWVyIG9mIHNl Y3VyaXR5IGluIGJldHdlZW4gYSBzaW1wbGUgQVBJIGtleSAoYSBiZWFyZXINCnRva2VuKSBhbmQg ZnVsbCBPQXV0aC1iYXNlZCB1c2VyIGF1dGhlbnRpY2F0aW9uLiBUaGV5IGRvIHRoaXMgdG9kYXkg dXNpbmcgdGhlDQpPQXV0aCAxLjAgJnF1b3Q7Y29uc3VtZXIga2V5JnF1b3Q7IC0tIHRoZXkgYnVy eSBhIGNvbnN1bWVyIGtleSBhbmQgc2VjcmV0DQppbnNpZGUgdGhlIG1vYmlsZSBkZXZpY2UsIGFu ZCB1c2UgdGhlIE9BdXRoIDEuMCBzaWduYXR1cmUgbWVjaGFuaXNtIHRvIHNpZ24NCmVhY2ggcmVx dWVzdCB1c2luZyB0aGUga2V5IGFuZCBzZWNyZXQuIFRoaXMgZ2l2ZXMgdGhlbSBhIHJlYXNvbmFi bGUgYW1vdW50IG9mDQphc3N1cmFuY2UgdGhhdCByZXF1ZXN0cyBhcmUgY29taW5nIGZyb20gYSBw YXJ0aWN1bGFyIHZlcnNpb24gb2YgdGhlIG1vYmlsZSBhcHAsDQp3aGlsZSBub3QgcmVxdWlyaW5n IGZ1bGwgdXNlciBhdXRoZW50aWNhdGlvbi4gKFNvbWUgcGVvcGxlIGNhbGwgdGhpcw0KJnF1b3Q7 b25lLWxlZ2dlZCBPQXV0aC4mcXVvdDspPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+RnVydGhlcm1vcmUsDQpzb21lIGV4aXN0aW5nIE9BdXRoIDEuMC1iYXNlZCBBUElzIC0t IG9yIGF0IGxlYXN0IHRoZSBOZXRmbGl4IEFQSSAtLSB1c2UNCmRpZmZlcmVudCBsZXZlbHMgb2Yg YXV0aGVudGljYXRpb24gZm9yIGRpZmZlcmVudCBjYWxscywgZGVwZW5kaW5nIG9uIHRoZQ0Kc2Vu c2l0aXZpdHkgb2YgdGhlIGRhdGEgaW52b2x2ZWQuIFRvIHVzZSBBdXRoIDEuMGEgdGVybWlub2xv Z3ksIGNlcnRhaW4gY2FsbHMNCnJlcXVpcmUgYSAmcXVvdDtjb25zdW1lciBrZXkgb25seSwmcXVv dDsgb3RoZXJzIG11c3QgYmUgc2lnbmVkIHVzaW5nIHRoZQ0KY29uc3VtZXIga2V5IGFuZCBzZWNy ZXQsIGFuZCBvdGhlcnMgbXVzdCBiZSBzaWduZWQgYnkgYSBjb25zdW1lciBrZXkgYW5kIGFjY2Vz cw0KdG9rZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdDt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4 My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAz LjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQnPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_004_5710F82C0E73B04FA559560098BF95B124F7A92BE6USNAVSXCHMBSA_-- From mscurtescu@google.com Fri Apr 2 09:35:16 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD613A6869 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.615 X-Spam-Level: X-Spam-Status: No, score=-100.615 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sffl5Wsj1q1U for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:35:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 5D7B53A6829 for <oauth@ietf.org>; Fri, 2 Apr 2010 09:35:15 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [10.3.21.11]) by smtp-out.google.com with ESMTP id o32GZmFX001715 for <oauth@ietf.org>; Fri, 2 Apr 2010 18:35:48 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270226148; bh=zecdQV0IsUC55cqQb0URes458Ds=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ujP1b/uupXsWe2QRbA/7b5NjMkgDYqvsJMNf99CaVLcdwJ6mqMcBfd3ztvxFvzL/E S5mpozUZ9tFaZ2Q6JGdvg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=OgdivX67mrLJhX6+eXWPBVDSMAfkZNady/YOyHvgN0iW5gCqWpEIExpMB1AS3rJbf TFVY9D9+HliXObC5+duYw== Received: from pwj3 (pwj3.prod.google.com [10.241.219.67]) by hpaq11.eem.corp.google.com with ESMTP id o32GZicv031750 for <oauth@ietf.org>; Fri, 2 Apr 2010 18:35:46 +0200 Received: by pwj3 with SMTP id 3so960957pwj.22 for <oauth@ietf.org>; Fri, 02 Apr 2010 09:35:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Fri, 2 Apr 2010 09:35:24 -0700 (PDT) In-Reply-To: <C7DACA48.31B81%eran@hueniverse.com> References: <p2k74caaad21004012200x8a118a1fq18096442f3cc6042@mail.gmail.com> <C7DACA48.31B81%eran@hueniverse.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 2 Apr 2010 09:35:24 -0700 Received: by 10.140.248.9 with SMTP id v9mr1687428rvh.101.1270226144125; Fri, 02 Apr 2010 09:35:44 -0700 (PDT) Message-ID: <i2m74caaad21004020935xe224523ep82b382db1258513c@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 16:35:16 -0000 On Thu, Apr 1, 2010 at 10:10 PM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: > The current draft allows the following characters: > > =A0=A0value-char =A0=3D ALPHA / DIGIT / "-" / "." / "_" / "~" / "%" > > Which means a utf-8 string will need to be encoded somehow. Should it be > percent-encoded? Something else? Why do we have this limitation (sorry if I missed a discussion around this)= ? Usernames and password, for example, are guaranteed to have problems. I think it is much better for the protocol/libraries to take care of encoding/decoding. Marius > > EHL > > > On 4/1/10 10:00 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: > > On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav <eran@hueniverse.com> > wrote: >> What is the assertion format? Binary? XML? Should the library encode it? >> Is >> the application using the library responsible for providing it with a >> URI-safe string? > > UTF-8 string I guess, the rest should not matter. > > Marius > > From cmortimore@salesforce.com Fri Apr 2 09:45:04 2010 Return-Path: <cmortimore@salesforce.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F913A692F for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-1.751, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FRT_PROFILE1=2.555, FRT_PROFILE2=1.981, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BvpAlXxMZ28 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 09:45:03 -0700 (PDT) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by core3.amsl.com (Postfix) with SMTP id 47A753A6829 for <oauth@ietf.org>; Fri, 2 Apr 2010 09:45:03 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKS7YfMRT8FhUvgPnvlHxfu9XYhOm6ojJ5@postini.com; Fri, 02 Apr 2010 09:45:37 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Fri, 2 Apr 2010 09:45:36 -0700 From: Chuck Mortimore <cmortimore@salesforce.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Date: Fri, 2 Apr 2010 09:45:36 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrSfgto5XGIZ8MUR6Gyxqxk8a9mDAABNm2Y Message-ID: <77AEC44D4DA08A46ADAA723286626BC12E2D43FABF@EXSFM-MB01.internal.salesforce.com> References: <l2i74caaad21004012145r7f789f8av76df4f14a2420139@mail.gmail.com>, <C7DAC67E.31B7C%eran@hueniverse.com> <77AEC44D4DA08A46ADAA723286626BC12E2D43FABA@EXSFM-MB01.internal.salesforce.com>, <2EF9AB07-95F6-41A2-BA05-43C2CF20D129@hueniverse.com> In-Reply-To: <2EF9AB07-95F6-41A2-BA05-43C2CF20D129@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 16:45:04 -0000 Agreed on Base64, however the SAML already specifies this at it's encoding = for web profiles, so we'll get the most reuse out of existing infrastructur= e by using it. =20 I will work on an example - we should be able to make some sound decisions = about how best to deal with it once we have something concrete. thanks=20 -cmort ________________________________________ From: Eran Hammer-Lahav [eran@hueniverse.com] Sent: Friday, April 02, 2010 9:03 AM To: Chuck Mortimore Cc: Marius Scurtescu; OAuth WG Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) The problem with base64 (even the uri safe flavor) is the paddind character (=3D) is not allowed without percent encoding. This gets messy without clear encoding process. The example below show that the profiles are likely to be much longer than the flow itself, raising my question of whether it is really all that useful to be included. If we are going to keep this in the core spec we need a list of what a profile must specify (just the items, not the actual details) and we need an example. I can live with that. Another option is to move it to a separate assertion flows spec which will include a few generally useful profiles. EHL On Apr 2, 2010, at 10:45, "Chuck Mortimore" <cmortimore@salesforce.com> wrote: > The format would be specified by a profilie. For instance, a SAML > profile might define: > > assertion_format=3Durn:oasis:names:tc:SAML:2.0:cm:bearer > assertion=3D{SAML 2 bearer assertion, optionally wrapped in a SAML > response, Signature must cover the assertion and can be inherited > from the Response signature, based64 encoded. Subject format and > attribute statement left undefined and implementation specific} > > Some other implementation may want a SAML1.1 profile, or an > Encrypted Assertion Profile, which would all be base64 encoded, but > the details of the expected assertion would change. Someone may want > to develop a Siteminder profile. In this case, a siteminder > session token would be exchanged for an Oauth token. This would > have a completely opaque format, and might be hex encode. Someone > else might want to develop an x.509 profile. Etc, etc. > > It really wouldn't be up to conformant Oauth2 clients to support > these profiles, or even the core assertion profile for that > matter. As Marius points out, the method for obtaining/validating > the assertions will be out of scope, and hence this is a specialized > Oauth client/server you're dealing with by definition. > > -cmort > > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of > Eran Hammer-Lahav [eran@hueniverse.com] > Sent: Thursday, April 01, 2010 9:54 PM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress > update) > > What is the assertion format? Binary? XML? Should the library encode > it? Is the application using the library responsible for providing > it with a URI-safe string? > > EHL > > > On 4/1/10 9:45 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: > > On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav > <eran@hueniverse.com> wrote: >> But providing a half baked flow that is short enough to just >> replicate where >> needed and cannot be fully implemented by generic libraries doesn=92 >> t really >> offer much. > > I think this is similar to the scope parameter argument, that > libraries cannot really > use an opaque scope. OAuth libraries will neither generate nor > consume the > assertions, the assertion itself can be opaque. The client > application needs to > obtain an assertion somehow, this is out of scope, then pass it to a > library and > the library can use it as is, pass it to the Authorization Server and > deal with the > response. Works perfectly fine IMO. > > Marius > From mscurtescu@google.com Fri Apr 2 10:30:07 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE05D3A6AE5 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 10:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.526 X-Spam-Level: X-Spam-Status: No, score=-104.526 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmjprVOY2Pv9 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 10:30:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 710DB3A6A44 for <oauth@ietf.org>; Fri, 2 Apr 2010 10:20:18 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [10.3.21.13]) by smtp-out.google.com with ESMTP id o32HKmPV013597 for <oauth@ietf.org>; Fri, 2 Apr 2010 10:20:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270228848; bh=ZCYggkcvb0MZ5lxeWJ6F+Vd6r0w=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=MPs4pR1MYg7RDad3/LKmTb2PWOAWUduwnplQRoNrwsA4OiXpBSvUXS51huPPrV0DN lL25k/X5LHRADnOZBIVbw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=qdXhUvxwgKaxcWYP+yXYJ4VZTc/jOUh/S+WGgL5GXDb6JtOS7cBE/A4FDbu5KuZun BPL4sSa7b3fIgvnjHsHog== Received: from pwi9 (pwi9.prod.google.com [10.241.219.9]) by hpaq13.eem.corp.google.com with ESMTP id o32HKkN6008511 for <oauth@ietf.org>; Fri, 2 Apr 2010 19:20:46 +0200 Received: by pwi9 with SMTP id 9so1975613pwi.13 for <oauth@ietf.org>; Fri, 02 Apr 2010 10:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Fri, 2 Apr 2010 10:20:25 -0700 (PDT) In-Reply-To: <u2vdaf5b9571004020853q2b527d1aw160c9105ec48eb84@mail.gmail.com> References: <710CC9A4-422B-424A-8FC2-AB190F41E87F@facebook.com> <C7DABE13.29882%atom@yahoo-inc.com> <u2vdaf5b9571004020853q2b527d1aw160c9105ec48eb84@mail.gmail.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 2 Apr 2010 10:20:25 -0700 Received: by 10.141.90.2 with SMTP id s2mr1697270rvl.273.1270228845093; Fri, 02 Apr 2010 10:20:45 -0700 (PDT) Message-ID: <l2v74caaad21004021020m93e48df7n619f0d8250f9302f@mail.gmail.com> To: Brian Eaton <beaton@google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Device Flow - Session Fixation? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 17:30:08 -0000 On Fri, Apr 2, 2010 at 8:53 AM, Brian Eaton <beaton@google.com> wrote: > On Thu, Apr 1, 2010 at 9:18 PM, Allen Tom <atom@yahoo-inc.com> wrote: >> The Auth server should also check for the presence of an HTTP Referrer. >> There should not be a referrer, since the user should not have clicked o= n >> anything to have landed on the screen > > I don't think this one is going to work in practice. =A0Manufacturers > may not point users directly at the OAuth approval page. =A0They are > going to end up pointing users to something shorter, e.g. > "http://google.samsung.com". =A0That web site will then redirect the > user to the right approval page. Then maybe the approval page can white list known referrers? With the device flow the user normally has to go to a page and then type in a code at that page. If the approval page accepts only HTTP POST and also prevents cross site posting then session fixation is not that easy anymore. Now the attacker has to convince the user to follow a link *and* type a code at that page. Marius From mscurtescu@google.com Fri Apr 2 11:49:57 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1953A6A8C for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 11:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.661 X-Spam-Level: X-Spam-Status: No, score=-100.661 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpiZmxOOQzyN for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 11:49:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 2D3C33A6C30 for <oauth@ietf.org>; Fri, 2 Apr 2010 11:21:28 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [10.3.21.14]) by smtp-out.google.com with ESMTP id o32ILwnC017744 for <oauth@ietf.org>; Fri, 2 Apr 2010 20:21:58 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270232518; bh=4LD4oOk1hdnpV7el8IbYRJlCYkY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GU2Vrj88b/6LpHB6jK1XQJL2o9DRwoIh6nrqxosLlVMl8pPV8kzqLSbKBbDWL8xFE Oksc58tYdJiWmF9bTgGzQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=EE4hWZcOei4PReL5nySpz9vz/YZFkaq9wRa3pP5VoGMZall7Ef4wOq5VTOHEMblAG /VbEyU/XNv/XQBFEZaK3g== Received: from pwi1 (pwi1.prod.google.com [10.241.219.1]) by hpaq14.eem.corp.google.com with ESMTP id o32ILu1f026296 for <oauth@ietf.org>; Fri, 2 Apr 2010 20:21:57 +0200 Received: by pwi1 with SMTP id 1so1828918pwi.25 for <oauth@ietf.org>; Fri, 02 Apr 2010 11:21:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Fri, 2 Apr 2010 11:21:36 -0700 (PDT) In-Reply-To: <C7D94365.31AB8%eran@hueniverse.com> References: <C7D94365.31AB8%eran@hueniverse.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 2 Apr 2010 11:21:36 -0700 Received: by 10.140.247.20 with SMTP id u20mr1804526rvh.122.1270232516107; Fri, 02 Apr 2010 11:21:56 -0700 (PDT) Message-ID: <h2j74caaad21004021121o69dfa9aejea36bef49b7adadb@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 18:49:57 -0000 Hi Eran, A few more comments: 1. Only one endpoint. While I think collapsing the access token and refresh token URLs into one URL was a good think, keeping the user authorization as a separate URL could be beneficial. I think there should be 2 endpoints defined: access token and user authorization. Calls to the access token endpoint are alway direct calls and restricted to HTTPS and POST, and with many frameworks this can be enforced through configuration. The user authorization endpoint is always accessed with a browser. 2. Section 2.1: "The authorization endpoint advertised by the server MUST NOT include a query or fragment components as defined by [RFC3986] section 3." Why do we disallow query parameters? If we want to enforce strict matching of callback URLs maybe we should just demand that. 3. Section 2.2: "The values of the request and response parameters defined in this section MUST only contain the following characters". I asked in another thread what is the reason behind this limitation. Why not any UTF-8 string? 4. Section 2.4.1.1: "The client directs the end user to the constructed URI using an HTTP redirection response, or by other means available to it via the end user's user-agent. The request MUST use the HTTP "GET" method." Why do we enforce GET? 5. Section 2.4.2. Web Client Flow combines both rich app and JavaScript flows. It think the two flows should be treated separately. For the rich apps the flow should include a verification code step, similar to Web Client Flow. Also, in this case the callback URL should be optional and if not present the authorization server must display a page with instructions and a special title. For the JavaScript flow, the presence of an empty fragment in the callback URL is a signal that the response should be put there? Can we make it mandatory that the response always goes to the fragment? It is not defined how is the response supposed to be encoded into the fragment. I assume that also URL encoded, but it should be specified. 6. Sections 4.1.2 and 4.1.3, the parameter name should probably be oauth_access_token. 7. Section 4.2, shouldn't we require a "version" parameter with value "2.0"? Thanks, Marius On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > I'm making good progress working off David's draft and bringing text from > WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far > it is largely in line with David's proposal and the majority of changes are > purely editorial. > > The only significant change I have made (which is of course open to debate) > is renaming all the authorization flows parameters. I dropped the oauth_ > prefix (no real need since these are purely OAuth endpoints, not protected > resources), and made most of the parameter names shorter. I am not done so > they are not consistent yet. > > You can follow my progress (changes every few hours) at: > > http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth > .txt > > Please feel free to comment on anything you like or dislike. I will publish > the whole thing as an I-D once it is feature complete for the WG to discuss > before we promote this to a WG draft. > > I hope to be done with the initial draft by middle of next week (I'll be > flying most of Fri-Sat so no progress over the weekend). > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Fri Apr 2 12:32:17 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF9F3A6BED for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 12:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKXpx3EBpoLM for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 12:32:16 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3EE623A6BEB for <oauth@ietf.org>; Fri, 2 Apr 2010 12:00:32 -0700 (PDT) Received: (qmail 22510 invoked from network); 2 Apr 2010 19:01:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Apr 2010 19:01:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 2 Apr 2010 12:01:01 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 2 Apr 2010 12:00:47 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrSltXoCOJT+s5MQV+n+hjfhsPpHw== Message-ID: <A082D385-AB28-4A9C-BB62-8787A931BB23@hueniverse.com> References: <p2k74caaad21004012200x8a118a1fq18096442f3cc6042@mail.gmail.com> <C7DACA48.31B81%eran@hueniverse.com> <i2m74caaad21004020935xe224523ep82b382db1258513c@mail.gmail.com> In-Reply-To: <i2m74caaad21004020935xe224523ep82b382db1258513c@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 19:32:17 -0000 Because of how we send parameters. Most of the problems we had with =20 1.0 involved encoding issues. We just need to find a good way of =20 explaining it. These are the characters allowed in Uris and form encoded bodies. EHL On Apr 2, 2010, at 12:35, "Marius Scurtescu" <mscurtescu@google.com> =20 wrote: > On Thu, Apr 1, 2010 at 10:10 PM, Eran Hammer-Lahav <eran@hueniverse.com=20 > > wrote: >> The current draft allows the following characters: >> >> value-char =3D ALPHA / DIGIT / "-" / "." / "_" / "~" / "%" >> >> Which means a utf-8 string will need to be encoded somehow. Should =20 >> it be >> percent-encoded? Something else? > > Why do we have this limitation (sorry if I missed a discussion =20 > around this)? > > Usernames and password, for example, are guaranteed to have problems. > I think it is much better for the protocol/libraries to take care of > encoding/decoding. > > Marius > >> >> EHL >> >> >> On 4/1/10 10:00 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: >> >> On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav <eran@hueniverse.com=20 >> > >> wrote: >>> What is the assertion format? Binary? XML? Should the library =20 >>> encode it? >>> Is >>> the application using the library responsible for providing it =20 >>> with a >>> URI-safe string? >> >> UTF-8 string I guess, the rest should not matter. >> >> Marius >> >> From stpeter@stpeter.im Fri Apr 2 12:59:47 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1515D3A6AC0 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 12:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT29kGasF++u for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 12:59:46 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8D83A3A6B5B for <oauth@ietf.org>; Fri, 2 Apr 2010 12:26:16 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E46E40E15 for <oauth@ietf.org>; Fri, 2 Apr 2010 13:26:50 -0600 (MDT) Message-ID: <4BB644F8.5030908@stpeter.im> Date: Fri, 02 Apr 2010 13:26:48 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <p2k74caaad21004012200x8a118a1fq18096442f3cc6042@mail.gmail.com> <C7DACA48.31B81%eran@hueniverse.com> <i2m74caaad21004020935xe224523ep82b382db1258513c@mail.gmail.com> In-Reply-To: <i2m74caaad21004020935xe224523ep82b382db1258513c@mail.gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070409010902070802030907" Subject: Re: [OAUTH-WG] SAML Assertion Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 19:59:47 -0000 This is a cryptographically signed message in MIME format. --------------ms070409010902070802030907 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/2/10 10:35 AM, Marius Scurtescu wrote: > On Thu, Apr 1, 2010 at 10:10 PM, Eran Hammer-Lahav <eran@hueniverse.com= > wrote: >> The current draft allows the following characters: >> >> value-char =3D ALPHA / DIGIT / "-" / "." / "_" / "~" / "%" >> >> Which means a utf-8 string will need to be encoded somehow. Should it = be >> percent-encoded? Something else? >=20 > Why do we have this limitation (sorry if I missed a discussion around t= his)? >=20 > Usernames and password, for example, are guaranteed to have problems. > I think it is much better for the protocol/libraries to take care of > encoding/decoding. /me watches in horror as a large can of worms is opened --------------ms070409010902070802030907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQwMjE5MjY0OFowIwYJKoZIhvcNAQkEMRYEFEQXReKW/aYRPjBhTssb 5DiFIrs9MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAYrCxbhNvWeOZ+k8gjH1Itu9YXWqJ3sYCdJjBfFGO sTPmO3EyeZWrD7UHAhnmDTyNHB9FrO+PnudSMLgCDHQaENZrM5YgaxDy1kOTh+1otF0tpolh Fx3Vygc3TVihBCHvvV0y1irfAA6Uz6zoMmC47AsDFWGSrpdjm19eOhYuyGWuUpjZdsA8Ms+Q P8XkAECh4FPl5sj6+ga8ycb6Op2y4bJEOetDdh2DHgntbOindTJvoKUqUuxDxNBIT0XvWPvy tf5P7A5LLelBau6FoXjC1zLtlfkNK/5mVof9UIkZgL6kp8qRKObQhi5ggsqs8kIrIHScFrnW 1Roo3wxgMh/0dwAAAAAAAA== --------------ms070409010902070802030907-- From mscurtescu@google.com Fri Apr 2 13:13:35 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83AD3A6C61 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 13:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.553 X-Spam-Level: X-Spam-Status: No, score=-104.553 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fNxs4sE9i+q for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 13:13:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 33C733A6C0E for <oauth@ietf.org>; Fri, 2 Apr 2010 12:48:16 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id o32Jmmeo011213 for <oauth@ietf.org>; Fri, 2 Apr 2010 12:48:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270237728; bh=f1WelWgpUcjZC8bcF84ykTRhnis=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=R+12R9SRTbKRWcoXelo5hiGa9W5kysnYl10DHpTrUHAK93x5G3id2LJCxok249dmE hWGplCzQfmZ79L8VTTRow== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=JTIxl7ODVK8Kks0WnfQdNLgFIaXMMYyrqI6o19ZmZaJM1nNDq7d4/iBJSB76ZQxUA +iQNoezRqrBeNum44TAMA== Received: from pwj5 (pwj5.prod.google.com [10.241.219.69]) by kpbe15.cbf.corp.google.com with ESMTP id o32JmlZK006256 for <oauth@ietf.org>; Fri, 2 Apr 2010 12:48:47 -0700 Received: by pwj5 with SMTP id 5so1749779pwj.34 for <oauth@ietf.org>; Fri, 02 Apr 2010 12:48:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Fri, 2 Apr 2010 12:48:27 -0700 (PDT) In-Reply-To: <A082D385-AB28-4A9C-BB62-8787A931BB23@hueniverse.com> References: <p2k74caaad21004012200x8a118a1fq18096442f3cc6042@mail.gmail.com> <C7DACA48.31B81%eran@hueniverse.com> <i2m74caaad21004020935xe224523ep82b382db1258513c@mail.gmail.com> <A082D385-AB28-4A9C-BB62-8787A931BB23@hueniverse.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 2 Apr 2010 12:48:27 -0700 Received: by 10.141.15.4 with SMTP id s4mr1809956rvi.112.1270237727123; Fri, 02 Apr 2010 12:48:47 -0700 (PDT) Message-ID: <y2l74caaad21004021248tdece26bemb0b83447aeb8a228@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 20:13:35 -0000 On Fri, Apr 2, 2010 at 12:00 PM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: > Because of how we send parameters. Most of the problems we had with > 1.0 involved encoding issues. We just need to find a good way of > explaining it. > > These are the characters allowed in Uris and form encoded bodies. Of course, but when you create the message you have to URL encode all the name/value pairs, a library would do that for you. But the value itself does not have to be restricted. Are we trying to allow for naive encodings where you just string together the names and values with some delimiters? I don't think that will help at all, you are just pushing the need to encode from the library out to the client code. And since the encoding now is not specified you have a real interop issue IMO. Marius > > EHL > > On Apr 2, 2010, at 12:35, "Marius Scurtescu" <mscurtescu@google.com> > wrote: > >> On Thu, Apr 1, 2010 at 10:10 PM, Eran Hammer-Lahav <eran@hueniverse.com >> > wrote: >>> The current draft allows the following characters: >>> >>> =A0 value-char =A0=3D ALPHA / DIGIT / "-" / "." / "_" / "~" / "%" >>> >>> Which means a utf-8 string will need to be encoded somehow. Should >>> it be >>> percent-encoded? Something else? >> >> Why do we have this limitation (sorry if I missed a discussion >> around this)? >> >> Usernames and password, for example, are guaranteed to have problems. >> I think it is much better for the protocol/libraries to take care of >> encoding/decoding. >> >> Marius >> >>> >>> EHL >>> >>> >>> On 4/1/10 10:00 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: >>> >>> On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav <eran@hueniverse.com >>> > >>> wrote: >>>> What is the assertion format? Binary? XML? Should the library >>>> encode it? >>>> Is >>>> the application using the library responsible for providing it >>>> with a >>>> URI-safe string? >>> >>> UTF-8 string I guess, the rest should not matter. >>> >>> Marius >>> >>> > From recordond@gmail.com Fri Apr 2 14:29:58 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E9A43A6A74 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 14:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.865 X-Spam-Level: X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmQEECcFh5cR for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 14:29:58 -0700 (PDT) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 7D23C3A6BFF for <oauth@ietf.org>; Fri, 2 Apr 2010 14:11:24 -0700 (PDT) Received: by iwn29 with SMTP id 29so1797687iwn.17 for <oauth@ietf.org>; Fri, 02 Apr 2010 14:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=49rIFx/p4l/J4nUDneDuIXBPMovmS0w6OHSr6l4hpGY=; b=O1iPPQ2UWNLXjlFygQa5isE+aPoTDrz2JbM6pGlEhOWLAARjd/CsdDT8PddAkj+FuS +B9DhlHlSAxDdW7ZHbmN356GWnw3mnB89Dr+MulDVWaeOjeHhqyXqZ1BHQ18m6fSt2fc XtMHFK+1vafqWCgYtr9aG/yNOO5a8GztJd+Yg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DVVIdiZtTxOxLO0iyWdJuRKCcD7/2MI3Bl9gBwHpVqDKQT/DXPOqnvyozczkgWvNeH 3QxLKf3qOGz5146w5WZHrL13/IgHWJiVokQ0B89Q7X7AYgp2f6iR2LV1Bi7OlwphpDNb v//yXSW5qICPXdGCcsOtnx/Q3PmrxXWLZ/x1o= MIME-Version: 1.0 Received: by 10.231.183.18 with HTTP; Fri, 2 Apr 2010 14:11:54 -0700 (PDT) In-Reply-To: <C7DB66EC.31BA0%eran@hueniverse.com> References: <C7DB66EC.31BA0%eran@hueniverse.com> Date: Fri, 2 Apr 2010 14:11:54 -0700 Received: by 10.231.153.1 with SMTP id i1mr1068802ibw.35.1270242714644; Fri, 02 Apr 2010 14:11:54 -0700 (PDT) Message-ID: <j2ufd6741651004021411y16f5e495j92c9111679724399@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 21:29:58 -0000 Assuming that this is mean to replace the scope parameter? On Fri, Apr 2, 2010 at 9:18 AM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te: > This is half baked but I wanted to get people's reaction: > > Clients tries accessing a resource with or without an access token: > > =A0GET /resource/1 HTTP/1.1 > =A0Host: server.example.com > > The server replies with: > > =A0HTTP/1.1 401 Unauthorized > =A0WWW-Authenticate: OAuth realm=3D'example' > > Clients requests an access token (using the client credentials flow) and > includes the requested realm (line breaks for display purposes): > > =A0POST /access_token HTTP/1.1 > =A0Host: server.example.com > > =A0client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpnqmM& > =A0mode=3Dflow_client&realm=3Dexample > > The server issues a access token capable of accessing the resource realm. > > This means one new parameter on the request side which is already baked i= nto > the 401 response in a standard way. > > Thoughts? > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From igor.faynberg@alcatel-lucent.com Fri Apr 2 14:46:02 2010 Return-Path: <igor.faynberg@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7643A6876 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 14:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzcy4IGfevSi for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 14:46:01 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 68C9F3A697D for <oauth@ietf.org>; Fri, 2 Apr 2010 14:45:21 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o32LjrkD013067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Apr 2010 16:45:53 -0500 (CDT) Received: from [135.244.34.55] (faynberg.lra.lucent.com [135.244.34.55]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o32LjqLn001603; Fri, 2 Apr 2010 16:45:52 -0500 (CDT) Message-ID: <4BB66590.1080205@alcatel-lucent.com> Date: Fri, 02 Apr 2010 17:45:52 -0400 From: Igor Faynberg <igor.faynberg@alcatel-lucent.com> Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: David Recordon <recordond@gmail.com> References: <C7DB66EC.31BA0%eran@hueniverse.com> <j2ufd6741651004021411y16f5e495j92c9111679724399@mail.gmail.com> In-Reply-To: <j2ufd6741651004021411y16f5e495j92c9111679724399@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 21:46:02 -0000 I don't see any problem at all. Igor David Recordon wrote: > Assuming that this is mean to replace the scope parameter? > > On Fri, Apr 2, 2010 at 9:18 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > >> This is half baked but I wanted to get people's reaction: >> >> Clients tries accessing a resource with or without an access token: >> >> GET /resource/1 HTTP/1.1 >> Host: server.example.com >> >> The server replies with: >> >> HTTP/1.1 401 Unauthorized >> WWW-Authenticate: OAuth realm='example' >> >> Clients requests an access token (using the client credentials flow) and >> includes the requested realm (line breaks for display purposes): >> >> POST /access_token HTTP/1.1 >> Host: server.example.com >> >> client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM& >> mode=flow_client&realm=example >> >> The server issues a access token capable of accessing the resource realm. >> >> This means one new parameter on the request side which is already baked into >> the 401 response in a standard way. >> >> Thoughts? >> >> EHL >> >> _______________________________________________ >> OAuth mailing 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 dick.hardt@gmail.com Fri Apr 2 15:27:24 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE693A67B0 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 15:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl7RkJ7-R9OU for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 15:27:24 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id E7F5D3A68C8 for <oauth@ietf.org>; Fri, 2 Apr 2010 15:27:15 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so776298qwb.31 for <oauth@ietf.org>; Fri, 02 Apr 2010 15:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=hKhX5e7V3r1zxS8WBpyMIuPrfI7c63T87Sd3W52Pi5s=; b=rUk4I0J2wiA/mJ8MCFUg2FltcoGVtIsoND7AuNwjmmPS+uz4ZITWzrKoXeFZXza6wM /+F8yfu39GYks/DcsQacl6kdYJsVGPcLpDAMQpCOjMIJx7uo0b/wJStR9maY9FSB+klM P90fatQDkxZTvSQJbJ2Jxtv/cPz7s2puOX6bA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=qhhUhIW02QalmFhU7stAOV2FNsz/SA4hH0N3by20yzKv7NAENhMNW0HXVp4q1vvH0H BRT1AVk77wJrmRzwDAOW+U7nJ8IXFoRIhPPARnuTYarHDsPeK2p/reE89w4kaweGCLpc sAvtWP93gor9NyIruF+aHXv9wKXMXY2cEErB0= Received: by 10.229.213.133 with SMTP id gw5mr4620422qcb.13.1270247264265; Fri, 02 Apr 2010 15:27:44 -0700 (PDT) Received: from [10.0.1.4] (c-67-180-195-167.hsd1.ca.comcast.net [67.180.195.167]) by mx.google.com with ESMTPS id w30sm1557941qce.4.2010.04.02.15.27.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 15:27:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <4BB66590.1080205@alcatel-lucent.com> Date: Fri, 2 Apr 2010 15:27:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <ECC37DF4-F9C3-4C04-BD4A-86655F45A23C@gmail.com> References: <C7DB66EC.31BA0%eran@hueniverse.com> <j2ufd6741651004021411y16f5e495j92c9111679724399@mail.gmail.com> <4BB66590.1080205@alcatel-lucent.com> To: igor.faynberg@alcatel-lucent.com X-Mailer: Apple Mail (2.1077) Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 22:27:24 -0000 There are times when a resource may have different scope for different = kinds of access. realm !=3D scope On 2010-04-02, at 2:45 PM, Igor Faynberg wrote: >=20 >=20 > I don't see any problem at all. >=20 > Igor >=20 > David Recordon wrote: >> Assuming that this is mean to replace the scope parameter? >>=20 >> On Fri, Apr 2, 2010 at 9:18 AM, Eran Hammer-Lahav = <eran@hueniverse.com> wrote: >> =20 >>> This is half baked but I wanted to get people's reaction: >>>=20 >>> Clients tries accessing a resource with or without an access token: >>>=20 >>> GET /resource/1 HTTP/1.1 >>> Host: server.example.com >>>=20 >>> The server replies with: >>>=20 >>> HTTP/1.1 401 Unauthorized >>> WWW-Authenticate: OAuth realm=3D'example' >>>=20 >>> Clients requests an access token (using the client credentials flow) = and >>> includes the requested realm (line breaks for display purposes): >>>=20 >>> POST /access_token HTTP/1.1 >>> Host: server.example.com >>>=20 >>> client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpnqmM& >>> mode=3Dflow_client&realm=3Dexample >>>=20 >>> The server issues a access token capable of accessing the resource = realm. >>>=20 >>> This means one new parameter on the request side which is already = baked into >>> the 401 response in a standard way. >>>=20 >>> Thoughts? >>>=20 >>> EHL >>>=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 From brent@facebook.com Fri Apr 2 16:52:13 2010 Return-Path: <brent@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200C53A68EE for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 16:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIh2JS4XTJQs for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 16:52:12 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 0F93F3A6889 for <oauth@ietf.org>; Fri, 2 Apr 2010 16:52:11 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o32Nq3I0006011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 2 Apr 2010 16:52:09 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.682.1; Fri, 2 Apr 2010 16:52:35 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Fri, 2 Apr 2010 16:52:35 -0700 From: Brent Goldman <brent@facebook.com> To: Brian Eaton <beaton@google.com> Date: Fri, 2 Apr 2010 16:51:52 -0700 Thread-Topic: [OAUTH-WG] Device Flow - Session Fixation? Thread-Index: AcrSv5Eja4Qcvu82She37MbXVyQjlg== Message-ID: <30427BA0-6C97-49FE-895F-C9115DC61D54@facebook.com> References: <710CC9A4-422B-424A-8FC2-AB190F41E87F@facebook.com> <C7DABE13.29882%atom@yahoo-inc.com> <u2vdaf5b9571004020853q2b527d1aw160c9105ec48eb84@mail.gmail.com> In-Reply-To: <u2vdaf5b9571004020853q2b527d1aw160c9105ec48eb84@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_13:2010-02-06, 2010-04-02, 2010-04-02 signatures=0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Device Flow - Session Fixation? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 23:52:13 -0000 Even if the auth server is using redirects for user simplicity, it can stil= l comply with the referer-checking requirement by having the simple URL (ht= tp://google.samsung.com) pass its referer as a GET param to the actual comp= lex URL (https://www.google.com/accounts/OAuthAuthorize?client_id=3D1238979= ). The actual server should first verify that the simple URL which redirect= ed to id (the proxy referer) is trusted, and if so, additionally check the = original referer from the GET param. Otherwise, the authorization should fa= il. Should this be added to the spec, or is this just an implementation detail? -Brent On Apr 2, 2010, at 8:53 AM, Brian Eaton wrote: > On Thu, Apr 1, 2010 at 9:18 PM, Allen Tom <atom@yahoo-inc.com> wrote: >> The Auth server should also check for the presence of an HTTP Referrer. >> There should not be a referrer, since the user should not have clicked o= n >> anything to have landed on the screen >=20 > I don't think this one is going to work in practice. Manufacturers > may not point users directly at the OAuth approval page. They are > going to end up pointing users to something shorter, e.g. > "http://google.samsung.com". That web site will then redirect the > user to the right approval page. >=20 > Otherwise we end up needing to tell users to manually type-in long, > complex urls like > https://www.google.com/accounts/OAuthAuthorize?client_id=3D1238979. >=20 > Cheers, > Brian From brent@facebook.com Fri Apr 2 16:53:17 2010 Return-Path: <brent@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C003A68EE for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 16:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBMtmmo1E4wL for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 16:53:17 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 0E2113A6889 for <oauth@ietf.org>; Fri, 2 Apr 2010 16:53:17 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o32Nr6R9022950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 2 Apr 2010 16:53:10 -0700 Received: from sc-hub01.TheFacebook.com (192.168.18.104) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.682.1; Fri, 2 Apr 2010 16:53:20 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Fri, 2 Apr 2010 16:53:20 -0700 From: Brent Goldman <brent@facebook.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 2 Apr 2010 16:52:37 -0700 Thread-Topic: [OAUTH-WG] Device Flow - Session Fixation? Thread-Index: AcrSv6wlzmfHsdyeQOme9CzYf8YPQA== Message-ID: <D2C8E2E3-4ABF-4BA3-A8D9-D4E69E991C40@facebook.com> References: <710CC9A4-422B-424A-8FC2-AB190F41E87F@facebook.com> <C7DABE13.29882%atom@yahoo-inc.com> <u2vdaf5b9571004020853q2b527d1aw160c9105ec48eb84@mail.gmail.com> <l2v74caaad21004021020m93e48df7n619f0d8250f9302f@mail.gmail.com> In-Reply-To: <l2v74caaad21004021020m93e48df7n619f0d8250f9302f@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_13:2010-02-06, 2010-04-02, 2010-04-02 signatures=0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Device Flow - Session Fixation? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 02 Apr 2010 23:53:17 -0000 +1 to accepting only HTTP POST and preventing cross-site posting. On Apr 2, 2010, at 10:20 AM, Marius Scurtescu wrote: > On Fri, Apr 2, 2010 at 8:53 AM, Brian Eaton <beaton@google.com> wrote: >> On Thu, Apr 1, 2010 at 9:18 PM, Allen Tom <atom@yahoo-inc.com> wrote: >>> The Auth server should also check for the presence of an HTTP Referrer. >>> There should not be a referrer, since the user should not have clicked = on >>> anything to have landed on the screen >>=20 >> I don't think this one is going to work in practice. Manufacturers >> may not point users directly at the OAuth approval page. They are >> going to end up pointing users to something shorter, e.g. >> "http://google.samsung.com". That web site will then redirect the >> user to the right approval page. >=20 > Then maybe the approval page can white list known referrers? >=20 >=20 > With the device flow the user normally has to go to a page and then > type in a code at that page. If the approval page accepts only HTTP POST > and also prevents cross site posting then session fixation is not that > easy anymore. Now the attacker has to convince the user to follow > a link *and* type a code at that page. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Fri Apr 2 18:16:39 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8808F3A6942 for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 18:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.429 X-Spam-Level: X-Spam-Status: No, score=-100.429 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8SouBUPI0zg for <oauth@core3.amsl.com>; Fri, 2 Apr 2010 18:16:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id AE8B23A68EC for <oauth@ietf.org>; Fri, 2 Apr 2010 18:14:07 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o331E1xh014739 for <oauth@ietf.org>; Sat, 3 Apr 2010 03:14:02 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270257242; bh=B0PZcsXCLGXXe7WTb+b3e+uPwSc=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=lVjWeGikmfgM388SBULbDE2XAYB1auWrrTJcgK5HsINpkC4cwQosxtbVG3kgQpd09 fpkgfERHNRCBigf+u7EyA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=khajIJZDIWlIEXqCHAPiW3wD8wWaNacrsus7uDZ0XIousz3f66VVc5l2JjfGVRD5T +FTMM66hBbZwP85IM99xg== Received: from vws8 (vws8.prod.google.com [10.241.21.136]) by wpaz21.hot.corp.google.com with ESMTP id o331E0YU017468 for <oauth@ietf.org>; Fri, 2 Apr 2010 18:14:00 -0700 Received: by vws8 with SMTP id 8so705170vws.1 for <oauth@ietf.org>; Fri, 02 Apr 2010 18:14:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.2 with HTTP; Fri, 2 Apr 2010 18:14:00 -0700 (PDT) Date: Fri, 2 Apr 2010 18:14:00 -0700 Received: by 10.220.108.79 with SMTP id e15mr1412164vcp.21.1270257240328; Fri, 02 Apr 2010 18:14:00 -0700 (PDT) Message-ID: <w2sdaf5b9571004021814of6ed420fm80725ac13e3599c2@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] security considerations early draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 03 Apr 2010 01:16:39 -0000 http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/ Cheers, Brian From torsten@lodderstedt.net Sat Apr 3 01:00:01 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4986E3A691F for <oauth@core3.amsl.com>; Sat, 3 Apr 2010 01:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.345 X-Spam-Level: X-Spam-Status: No, score=0.345 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgjQlbCgfczr for <oauth@core3.amsl.com>; Sat, 3 Apr 2010 01:00:00 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id 1D2D63A68DC for <oauth@ietf.org>; Sat, 3 Apr 2010 00:59:59 -0700 (PDT) Received: from p4fff1f5c.dip.t-dialin.net ([79.255.31.92] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1NxyGr-0003NR-4E; Sat, 03 Apr 2010 09:59:57 +0200 Message-ID: <4BB6F579.1000502@lodderstedt.net> Date: Sat, 03 Apr 2010 09:59:53 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Paul C. Bryan" <email@pbryan.net>, Eran Hammer-Lahav <eran@hueniverse.com> References: <C7DB66EC.31BA0%eran@hueniverse.com> <1270225468.14570.2.camel@Dynamo> In-Reply-To: <1270225468.14570.2.camel@Dynamo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 03 Apr 2010 08:00:01 -0000 I don't think the example implies discovery. As far as I understood, it just uses the same addresses for both protected resource and authorization server. This might work for some deployments, it won't work for installation with a single authorization server authorizing access to multiple resources with different adresses. I like the idea of using the protected resources realm as resource specification in the authorization server requests. To enhance the idea we need some kind of endpoint discovery. The simplest way would be to include another parameter in the WWW-Authenticate response indicating the authorization servers endpoint, e.g. HTTP/1.1 401 Unauthorized WWW-Authenticate: OAuth realm='example', endpoint='authorization.example.com' According to http://www.ietf.org/rfc/rfc2617.txt (Basic/Digest Authn Spec) this should be a legal usage of the WW-Authenticate header. An example of a WWW-Authenticate header for Digest authentication is: WWW-Authenticate: Digest realm="testrealm@host.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" regards, Torsten. > Presumably, the realm was used to discover the token issuance endpoints. > Why wouldn't the discovered URL of the access token endpoint dictate > realm, and why can't the realm then be implicit beyond discovery? > > -----Original Message----- > From: Eran Hammer-Lahav<eran@hueniverse.com> > To: OAuth WG<oauth@ietf.org> > Subject: [OAUTH-WG] Scope using Realm idea > Date: Fri, 2 Apr 2010 09:18:36 -0700 > > This is half baked but I wanted to get people's reaction: > > Clients tries accessing a resource with or without an access token: > > GET /resource/1 HTTP/1.1 > Host: server.example.com > > The server replies with: > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: OAuth realm='example' > > Clients requests an access token (using the client credentials flow) and > includes the requested realm (line breaks for display purposes): > > POST /access_token HTTP/1.1 > Host: server.example.com > > client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM& > mode=flow_client&realm=example > > The server issues a access token capable of accessing the resource realm. > > This means one new parameter on the request side which is already baked into > the 401 response in a standard way. > > Thoughts? > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Sat Apr 3 01:39:11 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFDB53A69EC for <oauth@core3.amsl.com>; Sat, 3 Apr 2010 01:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD2+0b1RNuYT for <oauth@core3.amsl.com>; Sat, 3 Apr 2010 01:39:11 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id 70C343A6A25 for <oauth@ietf.org>; Sat, 3 Apr 2010 01:25:16 -0700 (PDT) Received: from p4fff1f5c.dip.t-dialin.net ([79.255.31.92] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1NxyfJ-0005C9-Kp; Sat, 03 Apr 2010 10:25:13 +0200 Message-ID: <4BB6FB68.8060301@lodderstedt.net> Date: Sat, 03 Apr 2010 10:25:12 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav <eran@hueniverse.com> References: <C7DABD4B.31B69%eran@hueniverse.com> In-Reply-To: <C7DABD4B.31B69%eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 03 Apr 2010 08:39:12 -0000 You are right, there are different aspects of scope. Why not define one optional parameter per scope aspect? Based on our experiences with implementing OAuth 1.0a at Deutsche Telekom, I see the need for the following parameters - resource: specification of the protected resource to be accessed (type: URI or opaque string) - requested permissions: permissions on this resource the client want to get authorized by the user (comma-separated list of opaque strings). The range of permissions is defined by the resource as part of its API design. This could be something like "upload", "download", "sent", or "establish connection". The set of available permissions might be advertised by way of a WWW-Authenticate parameter (status code 401), as part of a 403 response, or in a XRDS discovery process. - requested duration: specification of the token duration the client asks for regards, Torsten. > ... > There isn't one - its service specific. > > The easy ones are: > > Duration > List of protected resources, URI wildcard, or name of protected segment > Read/write access or HTTP methods > > 3 years ago when we dropped the scope/token_attributes parameter from the > spec we decided to bring it back when we have enough deployment experience. > I strongly believe this rule still holds. > > It would be great if those with OAuth 1.0a deployments can share how they > specify scope. > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Sat Apr 3 03:35:34 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369403A6985 for <oauth@core3.amsl.com>; Sat, 3 Apr 2010 03:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.412 X-Spam-Level: X-Spam-Status: No, score=0.412 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rRg0cDeCs4f for <oauth@core3.amsl.com>; Sat, 3 Apr 2010 03:35:33 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id E05593A67F9 for <oauth@ietf.org>; Sat, 3 Apr 2010 03:35:32 -0700 (PDT) Received: from p4fff1f5c.dip.t-dialin.net ([79.255.31.92] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1Ny0hO-0004jf-1A; Sat, 03 Apr 2010 12:35:30 +0200 Message-ID: <4BB719F0.70807@lodderstedt.net> Date: Sat, 03 Apr 2010 12:35:28 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Paul C. Bryan" <email@pbryan.net>, Eran Hammer-Lahav <eran@hueniverse.com> References: <C7DB66EC.31BA0%eran@hueniverse.com> <1270225468.14570.2.camel@Dynamo> <4BB6F579.1000502@lodderstedt.net> In-Reply-To: <4BB6F579.1000502@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 03 Apr 2010 10:35:34 -0000 I've just seen, the current draft already specifies an attribute "authorization-uri" for the WWW-Authenticate header. Is this attribute intended for announcing the authorization servers endpoint? > I don't think the example implies discovery. As far as I understood, > it just uses the same addresses for both protected resource and > authorization server. This might work for some deployments, it won't > work for installation with a single authorization server authorizing > access to multiple resources with different adresses. > > I like the idea of using the protected resources realm as resource > specification in the authorization server requests. To enhance the > idea we need some kind of endpoint discovery. The simplest way would > be to include another parameter in the WWW-Authenticate response > indicating the authorization servers endpoint, e.g. > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: OAuth realm='example', > endpoint='authorization.example.com' > > According to http://www.ietf.org/rfc/rfc2617.txt (Basic/Digest Authn > Spec) this should be a legal usage of the WW-Authenticate header. An > example of a WWW-Authenticate header for Digest authentication is: > > WWW-Authenticate: Digest realm="testrealm@host.com", > qop="auth,auth-int", > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", > opaque="5ccc069c403ebaf9f0171e9517f40e41" > > regards, > Torsten. >> Presumably, the realm was used to discover the token issuance endpoints. >> Why wouldn't the discovered URL of the access token endpoint dictate >> realm, and why can't the realm then be implicit beyond discovery? >> >> -----Original Message----- >> From: Eran Hammer-Lahav<eran@hueniverse.com> >> To: OAuth WG<oauth@ietf.org> >> Subject: [OAUTH-WG] Scope using Realm idea >> Date: Fri, 2 Apr 2010 09:18:36 -0700 >> >> This is half baked but I wanted to get people's reaction: >> >> Clients tries accessing a resource with or without an access token: >> >> GET /resource/1 HTTP/1.1 >> Host: server.example.com >> >> The server replies with: >> >> HTTP/1.1 401 Unauthorized >> WWW-Authenticate: OAuth realm='example' >> >> Clients requests an access token (using the client credentials flow) and >> includes the requested realm (line breaks for display purposes): >> >> POST /access_token HTTP/1.1 >> Host: server.example.com >> >> client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM& >> mode=flow_client&realm=example >> >> The server issues a access token capable of accessing the resource >> realm. >> >> This means one new parameter on the request side which is already >> baked into >> the 401 response in a standard way. >> >> Thoughts? >> >> EHL >> >> _______________________________________________ >> OAuth mailing 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 eran@hueniverse.com Sat Apr 3 13:08:57 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CF228C10E for <oauth@core3.amsl.com>; Sat, 3 Apr 2010 13:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_60=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJcsOHfWGQ4X for <oauth@core3.amsl.com>; Sat, 3 Apr 2010 13:08:51 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 400EF3A6A0A for <oauth@ietf.org>; Sat, 3 Apr 2010 13:08:48 -0700 (PDT) Received: (qmail 8614 invoked from network); 3 Apr 2010 20:08:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Apr 2010 20:08:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 3 Apr 2010 13:08:47 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Sat, 3 Apr 2010 13:08:39 -0700 Thread-Topic: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) Thread-Index: AcrSnYVSDx3VZSANTU+L66uaIlifSAAy+3OR Message-ID: <C7DCEE57.31C62%eran@hueniverse.com> In-Reply-To: <y2l74caaad21004021248tdece26bemb0b83447aeb8a228@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7DCEE5731C62eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 03 Apr 2010 20:08:57 -0000 --_000_C7DCEE5731C62eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm waiting to see what Brian has in mind for signatures. If we keep the OA= uth 1.0a signature flow, we will need to deal with string encoding of some = sorts. The current limitation has signature in mind, not transmitting reque= sts. But either way, since assertions have unique structures, it is important to= note how they should be encoded into the request. EHL On 4/2/10 12:48 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: On Fri, Apr 2, 2010 at 12:00 PM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: > Because of how we send parameters. Most of the problems we had with > 1.0 involved encoding issues. We just need to find a good way of > explaining it. > > These are the characters allowed in Uris and form encoded bodies. Of course, but when you create the message you have to URL encode all the name/value pairs, a library would do that for you. But the value itself does not have to be restricted. Are we trying to allow for naive encodings where you just string together the names and values with some delimiters? I don't think that will help at all, you are just pushing the need to encode from the library out to the client code. And since the encoding now is not specified you have a real interop issue IMO. Marius > > EHL > > On Apr 2, 2010, at 12:35, "Marius Scurtescu" <mscurtescu@google.com> > wrote: > >> On Thu, Apr 1, 2010 at 10:10 PM, Eran Hammer-Lahav <eran@hueniverse.com >> > wrote: >>> The current draft allows the following characters: >>> >>> value-char =3D ALPHA / DIGIT / "-" / "." / "_" / "~" / "%" >>> >>> Which means a utf-8 string will need to be encoded somehow. Should >>> it be >>> percent-encoded? Something else? >> >> Why do we have this limitation (sorry if I missed a discussion >> around this)? >> >> Usernames and password, for example, are guaranteed to have problems. >> I think it is much better for the protocol/libraries to take care of >> encoding/decoding. >> >> Marius >> >>> >>> EHL >>> >>> >>> On 4/1/10 10:00 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: >>> >>> On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav <eran@hueniverse.com >>> > >>> wrote: >>>> What is the assertion format? Binary? XML? Should the library >>>> encode it? >>>> Is >>>> the application using the library responsible for providing it >>>> with a >>>> URI-safe string? >>> >>> UTF-8 string I guess, the rest should not matter. >>> >>> Marius >>> >>> > --_000_C7DCEE5731C62eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>I’m waiting to see what Brian has in mind for signatures. If we= keep the OAuth 1.0a signature flow, we will need to deal with string encod= ing of some sorts. The current limitation has signature in mind, not transm= itting requests.<BR> <BR> But either way, since assertions have unique structures, it is important to= note how they should be encoded into the request.<BR> <BR> EHL<BR> <BR> <BR> On 4/2/10 12:48 PM, "Marius Scurtescu" <<a href=3D"mscurtescu@= google.com">mscurtescu@google.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>On Fri, Apr 2, 2010 at 12:00 PM, Eran Hamme= r-Lahav <<a href=3D"eran@hueniverse.com">eran@hueniverse.com</a>> wro= te:<BR> > Because of how we send parameters. Most of the problems we had with<BR= > > 1.0 involved encoding issues. We just need to find a good way of<BR> > explaining it.<BR> ><BR> > These are the characters allowed in Uris and form encoded bodies.<BR> <BR> Of course, but when you create the message you have to URL encode all<BR> the name/value pairs, a library would do that for you. But the value<BR> itself does not have to be restricted.<BR> <BR> Are we trying to allow for naive encodings where you just string<BR> together the names and values with some delimiters?<BR> <BR> I don't think that will help at all, you are just pushing the need to<BR> encode from the library out to the client code. And since the encoding<BR> now is not specified you have a real interop issue IMO.<BR> <BR> <BR> Marius<BR> <BR> ><BR> > EHL<BR> ><BR> > On Apr 2, 2010, at 12:35, "Marius Scurtescu" <<a href=3D"= mscurtescu@google.com">mscurtescu@google.com</a>><BR> > wrote:<BR> ><BR> >> On Thu, Apr 1, 2010 at 10:10 PM, Eran Hammer-Lahav <<a href=3D"= eran@hueniverse.com">eran@hueniverse.com</a><BR> >> > wrote:<BR> >>> The current draft allows the following characters:<BR> >>><BR> >>> =A0 value-char =A0=3D ALPHA / DIGIT / "-" / ".&= quot; / "_" / "~" / "%"<BR> >>><BR> >>> Which means a utf-8 string will need to be encoded somehow. Sh= ould<BR> >>> it be<BR> >>> percent-encoded? Something else?<BR> >><BR> >> Why do we have this limitation (sorry if I missed a discussion<BR> >> around this)?<BR> >><BR> >> Usernames and password, for example, are guaranteed to have proble= ms.<BR> >> I think it is much better for the protocol/libraries to take care = of<BR> >> encoding/decoding.<BR> >><BR> >> Marius<BR> >><BR> >>><BR> >>> EHL<BR> >>><BR> >>><BR> >>> On 4/1/10 10:00 PM, "Marius Scurtescu" <<a href= =3D"mscurtescu@google.com">mscurtescu@google.com</a>> wrote:<BR> >>><BR> >>> On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav <<a href= =3D"eran@hueniverse.com">eran@hueniverse.com</a><BR> >>> ><BR> >>> wrote:<BR> >>>> What is the assertion format? Binary? XML? Should the libr= ary<BR> >>>> encode it?<BR> >>>> Is<BR> >>>> the application using the library responsible for providin= g it<BR> >>>> with a<BR> >>>> URI-safe string?<BR> >>><BR> >>> UTF-8 string I guess, the rest should not matter.<BR> >>><BR> >>> Marius<BR> >>><BR> >>><BR> ><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C7DCEE5731C62eranhueniversecom_-- From john@jkemp.net Sun Apr 4 14:34:17 2010 Return-Path: <john@jkemp.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906FC3A67F7 for <oauth@core3.amsl.com>; Sun, 4 Apr 2010 14:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXx55F8Sw+Bb for <oauth@core3.amsl.com>; Sun, 4 Apr 2010 14:34:16 -0700 (PDT) Received: from outbound-mail-313.bluehost.com (outbound-mail-313.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 50C523A67B1 for <oauth@ietf.org>; Sun, 4 Apr 2010 14:34:16 -0700 (PDT) Received: (qmail 16021 invoked by uid 0); 4 Apr 2010 21:34:14 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy3.bluehost.com with SMTP; 4 Apr 2010 21:34:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=AZ7rEzAfPT9BhrVMKVf4NS77b2gWwsDdm9dUp3C6g17RltTNukcluyhPQlFxORGXOsRY/31ec4RIVq+tEYVziCOgNbVa2W4ZzJ7/GSGgxJ7b5Z6Edrd2xSAeyjCZJQcN; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.103]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <john@jkemp.net>) id 1NyXSQ-0003h3-Hp; Sun, 04 Apr 2010 15:34:14 -0600 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: John Kemp <john@jkemp.net> In-Reply-To: <C7DB66EC.31BA0%eran@hueniverse.com> Date: Sun, 4 Apr 2010 17:34:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <C26EABB0-1BCB-42CD-A081-9405AAE90854@jkemp.net> References: <C7DB66EC.31BA0%eran@hueniverse.com> To: Eran Hammer-Lahav <eran@hueniverse.com> X-Mailer: Apple Mail (2.1077) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 04 Apr 2010 21:34:17 -0000 Hi Eran, On Apr 2, 2010, at 12:18 PM, Eran Hammer-Lahav wrote: > This is half baked but I wanted to get people's reaction: >=20 > Clients tries accessing a resource with or without an access token: >=20 > GET /resource/1 HTTP/1.1 > Host: server.example.com >=20 > The server replies with: >=20 > HTTP/1.1 401 Unauthorized > WWW-Authenticate: OAuth realm=3D'example' =46rom RFC 2617 (http://www.ietf.org/rfc/rfc2617.txt): "The realm value (case-sensitive), in combination with the canonical = root URL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realms." and: realm A string to be displayed to users so they know which username and password to use. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be "registered_users@gotham.news.com". Leading me to conclude: i) Realm is supposed to contain a hint for users as to which = username/password to use (ie. a client cannot by default assume it to be = machine-readable) ii) The "protection space" defined by a realm may be as small as one = resource, or as big as an entire site. RFC2617 tells clients what they = can assume if they receive a challenge: "A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server." >=20 > Clients requests an access token (using the client credentials flow) = and > includes the requested realm (line breaks for display purposes): >=20 > POST /access_token HTTP/1.1 > Host: server.example.com >=20 > client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpnqmM& > mode=3Dflow_client&realm=3Dexample >=20 > The server issues a access token capable of accessing the resource = realm. >=20 > This means one new parameter on the request side which is already = baked into > the 401 response in a standard way. >=20 > Thoughts? I think that RFC2617 realms are similar in concept to the 'scope' you're = looking for, but have some differences in use for the HTTP basic/digest = protocol. In order to be sure you don't confuse clients which already = know HTTP Basic/Digest, you may want to place some further restrictions = on the values that can be in the realm parameter when a WWW-Authenticate = challenge is issued (it's just a string in RFC2617). If a client = receives an OAuth WWW-Authenticate challenge, I would assume that OAuth = should anyway tell the client whether/what to present the user in order = to have the client get an appropriate token to access the protected = resource. Some care is needed to specify this in a way that is compatible with the = expected behaviour of user agents already familiar with RFC2617. Regards, - johnk From davidrecordon@facebook.com Mon Apr 5 09:09:22 2010 Return-Path: <davidrecordon@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA69A3A6A2A for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 09:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6mOzBN6MgAu for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 09:09:21 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 097B63A6A2D for <oauth@ietf.org>; Mon, 5 Apr 2010 09:09:20 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o35G8i7g001772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <oauth@ietf.org>; Mon, 5 Apr 2010 09:08:44 -0700 Received: from sc-hub01.TheFacebook.com (192.168.18.104) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.682.1; Mon, 5 Apr 2010 09:09:17 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Mon, 5 Apr 2010 09:09:17 -0700 From: David Recordon <davidrecordon@facebook.com> To: "oauth@ietf.org" <oauth@ietf.org> Date: Mon, 5 Apr 2010 09:09:41 -0700 Thread-Topic: Renaming expires to expires_in? Thread-Index: AcrU2le50B2lGSFlSOqXtk7O948e6Q== Message-ID: <CF406249-38AD-429F-8652-BDF508D87489@facebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-05_08:2010-02-06, 2010-04-05, 2010-04-05 signatures=0 Subject: [OAUTH-WG] Renaming expires to expires_in? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 05 Apr 2010 16:09:22 -0000 As one of our engineers was implementing a client, they got confused about = what was being returned by the expires parameter. Anyone object to renaming= it to expires_in so that it's clear that it isn't an absolute timestamp? Thanks, --David= From lindner@inuus.com Mon Apr 5 09:47:02 2010 Return-Path: <lindner@inuus.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCF63A67FC for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 09:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lmRrTWhS+cS for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 09:47:01 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id D6E723A6825 for <oauth@ietf.org>; Mon, 5 Apr 2010 09:47:00 -0700 (PDT) Received: by pvd12 with SMTP id 12so1523914pvd.31 for <oauth@ietf.org>; Mon, 05 Apr 2010 09:46:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.3.20 with HTTP; Mon, 5 Apr 2010 09:46:55 -0700 (PDT) In-Reply-To: <CF406249-38AD-429F-8652-BDF508D87489@facebook.com> References: <CF406249-38AD-429F-8652-BDF508D87489@facebook.com> Date: Mon, 5 Apr 2010 09:46:55 -0700 Received: by 10.142.120.3 with SMTP id s3mr1910291wfc.349.1270486015785; Mon, 05 Apr 2010 09:46:55 -0700 (PDT) Message-ID: <o2mb71cdca91004050946yc4d7bbddua1009844a37fc269@mail.gmail.com> From: Paul Lindner <lindner@inuus.com> To: David Recordon <davidrecordon@facebook.com> Content-Type: multipart/alternative; boundary=001636e0b9c5a9bae30483801377 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Renaming expires to expires_in? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 05 Apr 2010 16:47:02 -0000 --001636e0b9c5a9bae30483801377 Content-Type: text/plain; charset=ISO-8859-1 +1 This would more closely match the nomenclature used by the oauth session extension<http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html> . On Mon, Apr 5, 2010 at 9:09 AM, David Recordon <davidrecordon@facebook.com>wrote: > As one of our engineers was implementing a client, they got confused about > what was being returned by the expires parameter. Anyone object to renaming > it to expires_in so that it's clear that it isn't an absolute timestamp? > > Thanks, > --David > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001636e0b9c5a9bae30483801377 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1<div><br></div><div>This would more closely match the nomenclature used b= y the <a href=3D"http://oauth.googlecode.com/svn/spec/ext/session/1.0/draft= s/1/spec.html">oauth session extension</a>.<div><br><br><div class=3D"gmail= _quote"> On Mon, Apr 5, 2010 at 9:09 AM, David Recordon <span dir=3D"ltr"><<a hre= f=3D"mailto:davidrecordon@facebook.com">davidrecordon@facebook.com</a>><= /span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex;"> As one of our engineers was implementing a client, they got confused about = what was being returned by the expires parameter. Anyone object to renaming= it to expires_in so that it's clear that it isn't an absolute time= stamp?<br> <br> Thanks,<br> --David<br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </blockquote></div><br></div></div> --001636e0b9c5a9bae30483801377-- From rbarnes@bbn.com Mon Apr 5 10:28:39 2010 Return-Path: <rbarnes@bbn.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0443A6821 for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 10:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJHvXF2Y8c2u for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 10:28:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 952A03A679C for <oauth@ietf.org>; Mon, 5 Apr 2010 10:28:38 -0700 (PDT) Received: from [192.1.255.171] (port=53722 helo=col-dhcp-192-1-255-171.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Nyq6G-000A2O-4h; Mon, 05 Apr 2010 13:28:36 -0400 Message-Id: <EAFF3EB0-F324-4DF5-A4DB-C87B22CC5AB6@bbn.com> From: Richard Barnes <rbarnes@bbn.com> To: Paul Lindner <lindner@inuus.com> In-Reply-To: <o2mb71cdca91004050946yc4d7bbddua1009844a37fc269@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 13:28:35 -0400 References: <CF406249-38AD-429F-8652-BDF508D87489@facebook.com> <o2mb71cdca91004050946yc4d7bbddua1009844a37fc269@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Renaming expires to expires_in? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 05 Apr 2010 17:28:39 -0000 Ok, maybe something like "lifetime"? On Apr 5, 2010, at 12:46 PM, Paul Lindner wrote: > +1 > > This would more closely match the nomenclature used by the oauth > session extension. > > > On Mon, Apr 5, 2010 at 9:09 AM, David Recordon <davidrecordon@facebook.com > > wrote: > As one of our engineers was implementing a client, they got confused > about what was being returned by the expires parameter. Anyone > object to renaming it to expires_in so that it's clear that it isn't > an absolute timestamp? > > Thanks, > --David > _______________________________________________ > OAuth mailing 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 leifj@mnt.se Mon Apr 5 12:06:01 2010 Return-Path: <leifj@mnt.se> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CEB3A6953 for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 12:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_50=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04ywu5lZXnWB for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 12:06:00 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 1B17E3A67A4 for <oauth@ietf.org>; Mon, 5 Apr 2010 12:05:59 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o35J5qKa017191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 21:05:55 +0200 (CEST) Message-ID: <4BBA3490.3020802@mnt.se> Date: Mon, 05 Apr 2010 21:05:52 +0200 From: Leif Johansson <leifj@mnt.se> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: oauth@ietf.org, Thomas Hardjono <hardjono@mit.edu> References: <0E4475A4-8014-419B-A20E-15DDF04300FD@xmlgrrl.com> <4BAA4CBC.905@mnt.se> <4BB532FF.5040307@stpeter.im> In-Reply-To: <4BB532FF.5040307@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 193.10.252.66 Cc: =?UTF-8?B?TG92ZSBIw7ZybnF1aXN0IMOFc3RyYW5k?= <lha@kth.se> Subject: Re: [OAUTH-WG] What are the OAuth design principles? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 05 Apr 2010 19:06:01 -0000 On 04/02/2010 01:57 AM, Peter Saint-Andre wrote: > On 3/24/10 11:32 AM, Leif Johansson wrote: >> On 03/23/2010 12:00 AM, Eve Maler wrote: >>> Since the discussion in the "OAuth after-party" seemed to warrant >>> bringing it up, I mentioned the UMA design principles/requirements >>> document. You can find it here: >>> >>> http://kantarainitiative.org/confluence/display/uma/UMA+Requirements >>> >>> The discussion is around "Why can't Kerberos just be used for your use >>> cases?" The UMA principles might be able to inform how the OAuth WG >>> makes its case for why Kerberos doesn't suffice. (If we discover it >>> does, hey, our work here is done. :-) >> >> There are two threads here >> >> - why Kerberos _as such_ does or does not work for the use-cases >> - what experiences from 3rd party schemes such as Kerberos or STS are >> valuable for OAuth. >> >> Being long-time Kerberos-fanboy I still say that one of those threads >> are interesting and the other isn't. >> >> I think its much more valuable to talk about how to distill experience >> from Kerberos (etc) which are applicable to the design of OAuth. > > Agreed. Do you know if anyone has written up the design principles > behind (or lessons learned) from Kerberos and STS? If not, we'll need to > start prodding people into sharing their wisdom... Thomas, does the mitkc has something written on the subject of Kerberos from 10k feet that might be useful in this context? I'm cc:ing lha who also has tons of implementation experience. Cheers Leif From leifj@mnt.se Mon Apr 5 12:29:27 2010 Return-Path: <leifj@mnt.se> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024003A67A1 for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 12:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnYYKrKIX9M5 for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 12:29:26 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 7ADA53A67B7 for <oauth@ietf.org>; Mon, 5 Apr 2010 12:29:23 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o35JTH8T009933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <oauth@ietf.org>; Mon, 5 Apr 2010 21:29:20 +0200 (CEST) Message-ID: <4BBA3A0D.5040906@mnt.se> Date: Mon, 05 Apr 2010 21:29:17 +0200 From: Leif Johansson <leifj@mnt.se> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: oauth@ietf.org References: <191F411E00E19F4E943ECDB6D65C6085168FCFE8@TK5EX14MBXC115.redmond.corp.microsoft.com> <C7DA40B8.31B0F%eran@hueniverse.com> <o2x74caaad21004011321w7414318ai6f52ea84dea0862e@mail.gmail.com> <191F411E00E19F4E943ECDB6D65C60851690A880@TK5EX14MBXC115.redmond.corp.microsoft.com> <4BB54F92.1060201@stpeter.im> <AFE1F948-AAE1-49C4-89E3-C03348317087@facebook.com> In-Reply-To: <AFE1F948-AAE1-49C4-89E3-C03348317087@facebook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 193.10.252.66 Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 05 Apr 2010 19:29:27 -0000 On 04/02/2010 06:07 AM, Luke Shepard wrote: > > On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote: > > If that's true, then how does the Authorization Server know what scope > is appropriate at the Protected Resource? Does inclusion of the scope > parameter require a 1:1 mapping between AS and PR, or at least > communication between AS and PR? > > My preferred way of handling this is to have the Protected Resource throw a 403 Forbidden error, with an error message that specifies the scope needed - e.g., "oauth_scope_required=photo_read". > Here is a bit of Kerberos-lore: it is sometimes important to protect your error messages too! When you pass critical parameters ("you need this scope for access"), the error message suddenly becomes something you may have to protect. Cheers Leif From uidude@google.com Mon Apr 5 16:29:26 2010 Return-Path: <uidude@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD0E3A67B1 for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 16:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.376 X-Spam-Level: X-Spam-Status: No, score=-99.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoOHzlnEP1nL for <oauth@core3.amsl.com>; Mon, 5 Apr 2010 16:29:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 32A513A66B4 for <oauth@ietf.org>; Mon, 5 Apr 2010 16:29:25 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o35NTJYd002041 for <oauth@ietf.org>; Tue, 6 Apr 2010 01:29:19 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270510160; bh=f1Rp17pexSAkuHgZH6odr+aimZE=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=k8poe60wAWXAldRZjtRXzdBbwg+B4vPLBQR4dyHZCLfJeaFwbQdRukEktc7q/vx4Y L4gcweTrce+JeRTTuf8HA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type:x-system-of-record; b=EDIO7aBWumleyfp3JHubhu6MQ/0HCrW4zfLbZMDYQXY3k7zy1OjfCzJXF7CW7S2P5 mOvGPzegcblpwZtGmEC9A== Received: from qw-out-1920.google.com (qwk4.prod.google.com [10.241.195.132]) by kpbe18.cbf.corp.google.com with ESMTP id o35NSrQf005729 for <oauth@ietf.org>; Mon, 5 Apr 2010 16:28:54 -0700 Received: by qw-out-1920.google.com with SMTP id 4so1401990qwk.48 for <oauth@ietf.org>; Mon, 05 Apr 2010 16:28:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.194 with HTTP; Mon, 5 Apr 2010 16:28:33 -0700 (PDT) From: Evan Gilbert <uidude@google.com> Date: Mon, 5 Apr 2010 16:28:33 -0700 Received: by 10.229.10.132 with SMTP id p4mr4341703qcp.86.1270510133568; Mon, 05 Apr 2010 16:28:53 -0700 (PDT) Message-ID: <w2rc8689b661004051628q729ca3a8s4855be6d7af14a82@mail.gmail.com> To: oauth@ietf.org, Eran Hammer-Lahav <blade@yahoo-inc.com> Content-Type: multipart/alternative; boundary=0015175771ca31e59f048385b1cb X-System-Of-Record: true Subject: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 05 Apr 2010 23:29:26 -0000 --0015175771ca31e59f048385b1cb Content-Type: text/plain; charset=ISO-8859-1 A few comments on the Web Server and Web Client flow from the draft 2.0 spec<http://github.com/theRazorBlade/draft-ietf-oauth/> . Evan ---- 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow In both flows, the authorization server should be able redirect back to the callback URI without interacting directly with the resource owner if access has already been approved. This is not ruled out in the current language but it could be made cleaner. Suggested rewording - change "After receiving an authorization decision from the resource owner, the server redirects the resource owner to the callback URI." to "If the client is already approved or denied for access to the protected resource, the authorization service MAY redirect the resource owner to the callback URI immediately. If not, the authorization service SHOULD ask the resource owner for an authorization decision and after receiving the decision redirect the resource owner to the callback URI." ---- 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow We should have an OPTIONAL username parameter: username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for this user. This is useful for clients where a user is already logged into a 3rd party web site with a specific account, and the client wants the authorization to match the specific user. ---- 2.4.2 Web Client Flow Sending an access token as a query parameter is dangerous from a security perspective - these tokens are leaked via referrers and server logs. In previous WRAP discussions, it was felt that we should have a strong recommendation to use the URL fragment. Suggested wording: Client SHOULD send a callback URI with a query fragment, and authorization server MAY reject callback URLs without a fragment for security reasons. --0015175771ca31e59f048385b1cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A few comments on the Web Server and Web Client flow from the <a href=3D"ht= tp://github.com/theRazorBlade/draft-ietf-oauth/">draft 2.0 spec</a>.<div><b= r>Evan<br><div><font class=3D"Apple-style-span" face=3D"arial, sans-serif">= <span class=3D"Apple-style-span" style=3D"border-collapse: collapse;"><span= class=3D"Apple-style-span" style=3D"border-collapse: separate;"><br> </span></span></font></div><div><font class=3D"Apple-style-span" face=3D"ar= ial, sans-serif"><span class=3D"Apple-style-span" style=3D"border-collapse:= collapse;"><span class=3D"Apple-style-span" style=3D"border-collapse: sepa= rate;">----</span></span></font></div> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><span class=3D"= Apple-style-span" style=3D"border-collapse: separate;"><br></span></span></= font></div> <div><div><div>2.4.1 Web Callback Flow & 2.4.2 Web Client Flow</div><di= v><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif;= font-size: 13px; border-collapse: collapse; "><span class=3D"Apple-style-s= pan" style=3D"border-collapse: separate; font-family: arial; font-size: sma= ll; ">In both flows,=A0the authorization server should be able redirect bac= k to the callback URI without interacting directly with the resource owner = if access has already been approved. =A0This is not ruled out in the curren= t language but it could be made cleaner.=A0</span></span></div> <div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser= if; font-size: 13px; border-collapse: collapse; "><span class=3D"Apple-styl= e-span" style=3D"border-collapse: separate; font-family: arial; font-size: = small; "><br> </span></span></div><div><span class=3D"Apple-style-span" style=3D"font-fam= ily: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><span= class=3D"Apple-style-span" style=3D"border-collapse: separate; font-family= : arial; font-size: small; ">Suggested rewording - change</span></span></di= v> <div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser= if; font-size: 13px; border-collapse: collapse; "><span class=3D"Apple-styl= e-span" style=3D"border-collapse: separate; font-family: arial; font-size: = small; "><br> </span></span></div><div><span class=3D"Apple-style-span" style=3D"font-fam= ily: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><span= class=3D"Apple-style-span" style=3D"border-collapse: separate; font-family= : arial; font-size: small; ">"After receiving an authorization decisio= n from the resource owner, the server redirects the resource owner to the c= allback URI."</span></span></div> <div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser= if; font-size: 13px; border-collapse: collapse; "><span class=3D"Apple-styl= e-span" style=3D"border-collapse: separate; font-family: arial; font-size: = small; "><br> =A0=A0to</span></span></div><div><span class=3D"Apple-style-span" style=3D"= font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse;= "><span class=3D"Apple-style-span" style=3D"border-collapse: separate; fon= t-family: arial; font-size: small; "><br> "If the client is already approved or denied for access to the protect= ed resource, the authorization service MAY redirect the resource owner to t= he callback URI immediately. If not, the authorization service SHOULD ask t= he resource owner for an authorization decision and after receiving the dec= ision=A0redirect the resource owner to the callback URI."</span></span= ></div> <div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser= if; font-size: 13px; border-collapse: collapse; "><br></span></div><div><sp= an class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif; font= -size: 13px; border-collapse: collapse; ">----</span></div> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><span class=3D"= Apple-style-span" style=3D"border-collapse: separate; font-family: arial; "= ><br class=3D"Apple-interchange-newline"> 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow</span></span></font></d= iv><div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span c= lass=3D"Apple-style-span" style=3D"border-collapse: collapse;"><span class= =3D"Apple-style-span" style=3D"border-collapse: separate; font-family: aria= l; ">We should have an OPTIONAL username parameter:<br> username</span></span></font></div><div><font class=3D"Apple-style-span" fa= ce=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=3D"border-c= ollapse: collapse;"><span class=3D"Apple-style-span" style=3D"border-collap= se: separate; font-family: arial; ">=A0=A0The resource owner's username= . The authorization server MUST only send back refresh tokens or access tok= ens for this user.</span></span></font></div> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><span class=3D"= Apple-style-span" style=3D"border-collapse: separate; font-family: arial; "= ><br></span></span></font></div> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><span class=3D"= Apple-style-span" style=3D"border-collapse: separate; font-family: arial; "= >This is useful for clients where a user is already logged into a 3rd party= web site with a specific account, and the client wants the authorization t= o match the specific user.</span></span></font></div> <div><br></div><div>----</div><div><br>2.4.2 Web Client Flow</div><div>Send= ing an access token as a query parameter is dangerous from a security persp= ective - these tokens are leaked via referrers and server logs. In previous= WRAP discussions, it was felt that we should have a strong recommendation = to use the URL fragment.</div> <div><br>Suggested wording:<br>Client SHOULD send a callback URI with a que= ry fragment, and authorization server MAY reject callback URLs without a fr= agment for security reasons.</div></div></div><div><br></div></div> --0015175771ca31e59f048385b1cb-- From eran@hueniverse.com Tue Apr 6 00:11:30 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84723A67D9 for <oauth@core3.amsl.com>; Tue, 6 Apr 2010 00:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=1.799, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiyUdphwVVMG for <oauth@core3.amsl.com>; Tue, 6 Apr 2010 00:11:27 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D5AFE3A67A2 for <oauth@ietf.org>; Tue, 6 Apr 2010 00:11:26 -0700 (PDT) Received: (qmail 28713 invoked from network); 6 Apr 2010 07:11:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 07:11:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Apr 2010 00:11:22 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: David Recordon <davidrecordon@facebook.com>, OAuth WG <oauth@ietf.org> Date: Tue, 6 Apr 2010 00:11:18 -0700 Thread-Topic: [OAUTH-WG] Renaming expires to expires_in? Thread-Index: AcrU2le50B2lGSFlSOqXtk7O948e6QAfgJwy Message-ID: <C7E02CA6.31D47%eran@hueniverse.com> In-Reply-To: <CF406249-38AD-429F-8652-BDF508D87489@facebook.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E02CA631D47eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Renaming expires to expires_in? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 06 Apr 2010 07:11:31 -0000 --_000_C7E02CA631D47eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Changed to 'duration'. EHL On 4/5/10 9:09 AM, "David Recordon" <davidrecordon@facebook.com> wrote: As one of our engineers was implementing a client, they got confused about = what was being returned by the expires parameter. Anyone object to renaming= it to expires_in so that it's clear that it isn't an absolute timestamp? Thanks, --David _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C7E02CA631D47eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] Renaming expires to expires_in? Changed to ‘duration’.

EHL


On 4/5/10 9:09 AM, "David Recordon" <davidrecordon@facebook.com> wrote:

As one of our engineers was implementing a = client, they got confused about what was being returned by the expires para= meter. Anyone object to renaming it to expires_in so that it's clear that i= t isn't an absolute timestamp?

Thanks,
--David
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C7E02CA631D47eranhueniversecom_-- From eran@hueniverse.com Tue Apr 6 00:13:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366C23A67D9 for ; Tue, 6 Apr 2010 00:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhWKsF1dT2VD for ; Tue, 6 Apr 2010 00:13:45 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 80E233A67A2 for ; Tue, 6 Apr 2010 00:13:45 -0700 (PDT) Received: (qmail 14447 invoked from network); 6 Apr 2010 07:13:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 07:13:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Apr 2010 00:13:42 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , Paul Bryan Date: Tue, 6 Apr 2010 00:13:39 -0700 Thread-Topic: [OAUTH-WG] Scope using Realm idea Thread-Index: AcrTGWTvcWxerGxTSjec5bP/0+pnTgCP0lE0 Message-ID: In-Reply-To: <4BB719F0.70807@lodderstedt.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 07:13:48 -0000 Yep. I'm trying to remove the need for a more complex discovery. EHL On 4/3/10 3:35 AM, "Torsten Lodderstedt" wrote: > I've just seen, the current draft already specifies an attribute > "authorization-uri" for the WWW-Authenticate header. Is this attribute > intended for announcing the authorization servers endpoint? >=20 >> I don't think the example implies discovery. As far as I understood, >> it just uses the same addresses for both protected resource and >> authorization server. This might work for some deployments, it won't >> work for installation with a single authorization server authorizing >> access to multiple resources with different adresses. >>=20 >> I like the idea of using the protected resources realm as resource >> specification in the authorization server requests. To enhance the >> idea we need some kind of endpoint discovery. The simplest way would >> be to include another parameter in the WWW-Authenticate response >> indicating the authorization servers endpoint, e.g. >>=20 >> HTTP/1.1 401 Unauthorized >> WWW-Authenticate: OAuth realm=3D'example', >> endpoint=3D'authorization.example.com' >>=20 >> According to http://www.ietf.org/rfc/rfc2617.txt (Basic/Digest Authn >> Spec) this should be a legal usage of the WW-Authenticate header. An >> example of a WWW-Authenticate header for Digest authentication is: >>=20 >> WWW-Authenticate: Digest realm=3D"testrealm@host.com", >> qop=3D"auth,auth-int", >> nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", >> opaque=3D"5ccc069c403ebaf9f0171e9517f40e41" >>=20 >> regards, >> Torsten. >>> Presumably, the realm was used to discover the token issuance endpoints= . >>> Why wouldn't the discovered URL of the access token endpoint dictate >>> realm, and why can't the realm then be implicit beyond discovery? >>>=20 >>> -----Original Message----- >>> From: Eran Hammer-Lahav >>> To: OAuth WG >>> Subject: [OAUTH-WG] Scope using Realm idea >>> Date: Fri, 2 Apr 2010 09:18:36 -0700 >>>=20 >>> This is half baked but I wanted to get people's reaction: >>>=20 >>> Clients tries accessing a resource with or without an access token: >>>=20 >>> GET /resource/1 HTTP/1.1 >>> Host: server.example.com >>>=20 >>> The server replies with: >>>=20 >>> HTTP/1.1 401 Unauthorized >>> WWW-Authenticate: OAuth realm=3D'example' >>>=20 >>> Clients requests an access token (using the client credentials flow) an= d >>> includes the requested realm (line breaks for display purposes): >>>=20 >>> POST /access_token HTTP/1.1 >>> Host: server.example.com >>>=20 >>> client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpnqmM& >>> mode=3Dflow_client&realm=3Dexample >>>=20 >>> The server issues a access token capable of accessing the resource >>> realm. >>>=20 >>> This means one new parameter on the request side which is already >>> baked into >>> the 401 response in a standard way. >>>=20 >>> Thoughts? >>>=20 >>> EHL >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 From eran@hueniverse.com Tue Apr 6 00:15:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655153A6812 for ; Tue, 6 Apr 2010 00:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qX3m5v0C3y7 for ; Tue, 6 Apr 2010 00:15:03 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 779A53A67A2 for ; Tue, 6 Apr 2010 00:15:03 -0700 (PDT) Received: (qmail 29065 invoked from network); 6 Apr 2010 07:15:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 07:15:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Apr 2010 00:15:01 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Tue, 6 Apr 2010 00:14:58 -0700 Thread-Topic: [OAUTH-WG] Scope Thread-Index: AcrTBzFTWFREj4qLQAib4nrptehxrQCUav6u Message-ID: In-Reply-To: <4BB6FB68.8060301@lodderstedt.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 07:15:04 -0000 I agree that this is the right approach (separate parameters to well define= d scope attributes). However, so far the only well-defined attribute is a protected segment name (aka realm). EHL On 4/3/10 1:25 AM, "Torsten Lodderstedt" wrote: > You are right, there are different aspects of scope. Why not define one > optional parameter per scope aspect? >=20 > Based on our experiences with implementing OAuth 1.0a at Deutsche > Telekom, I see the need for the following parameters > - resource: specification of the protected resource to be accessed > (type: URI or opaque string) > - requested permissions: permissions on this resource the client want > to get authorized by the user (comma-separated list of opaque strings). > The range of permissions is defined by the resource as part of its API > design. This could be something like "upload", "download", "sent", or > "establish connection". The set of available permissions might be > advertised by way of a WWW-Authenticate parameter (status code 401), as > part of a 403 response, or in a XRDS discovery process. > - requested duration: specification of the token duration the client > asks for >=20 > regards, > Torsten. >> ... >> There isn't one - its service specific. >>=20 >> The easy ones are: >>=20 >> Duration >> List of protected resources, URI wildcard, or name of protected segment >> Read/write access or HTTP methods >>=20 >> 3 years ago when we dropped the scope/token_attributes parameter from th= e >> spec we decided to bring it back when we have enough deployment experien= ce. >> I strongly believe this rule still holds. >>=20 >> It would be great if those with OAuth 1.0a deployments can share how the= y >> specify scope. >>=20 >> EHL >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >=20 >=20 >=20 From eran@hueniverse.com Tue Apr 6 00:17:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7C63A681A for ; Tue, 6 Apr 2010 00:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtBMzUZLo7Dh for ; Tue, 6 Apr 2010 00:17:39 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 0591B3A67DB for ; Tue, 6 Apr 2010 00:17:37 -0700 (PDT) Received: (qmail 29394 invoked from network); 6 Apr 2010 07:17:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 07:17:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Apr 2010 00:16:31 -0700 From: Eran Hammer-Lahav To: Dick Hardt , "igor.faynberg@alcatel-lucent.com" Date: Tue, 6 Apr 2010 00:16:29 -0700 Thread-Topic: [OAUTH-WG] Scope using Realm idea Thread-Index: AcrSs8GPpJHnns8IR++hOcal6U8XKwCpVH7p Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 07:17:44 -0000 On 4/2/10 3:27 PM, "Dick Hardt" wrote: > There are times when a resource may have different scope for different ki= nds > of access. realm !=3D scope No. Realm is a subset. It is what people define as the protected segment name. For any other scope attribute we need to first define it. EHL > On 2010-04-02, at 2:45 PM, Igor Faynberg wrote: >=20 >>=20 >>=20 >> I don't see any problem at all. >>=20 >> Igor >>=20 >> David Recordon wrote: >>> Assuming that this is mean to replace the scope parameter? >>>=20 >>> On Fri, Apr 2, 2010 at 9:18 AM, Eran Hammer-Lahav >>> wrote: >>>=20 >>>> This is half baked but I wanted to get people's reaction: >>>>=20 >>>> Clients tries accessing a resource with or without an access token: >>>>=20 >>>> GET /resource/1 HTTP/1.1 >>>> Host: server.example.com >>>>=20 >>>> The server replies with: >>>>=20 >>>> HTTP/1.1 401 Unauthorized >>>> WWW-Authenticate: OAuth realm=3D'example' >>>>=20 >>>> Clients requests an access token (using the client credentials flow) a= nd >>>> includes the requested realm (line breaks for display purposes): >>>>=20 >>>> POST /access_token HTTP/1.1 >>>> Host: server.example.com >>>>=20 >>>> client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpnqmM& >>>> mode=3Dflow_client&realm=3Dexample >>>>=20 >>>> The server issues a access token capable of accessing the resource rea= lm. >>>>=20 >>>> This means one new parameter on the request side which is already bake= d >>>> into >>>> the 401 response in a standard way. >>>>=20 >>>> Thoughts? >>>>=20 >>>> EHL >>>>=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Tue Apr 6 00:21:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150AA3A67CF for ; Tue, 6 Apr 2010 00:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJbjNlrCPrEb for ; Tue, 6 Apr 2010 00:21:30 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 576A13A67C0 for ; Tue, 6 Apr 2010 00:21:28 -0700 (PDT) Received: (qmail 29849 invoked from network); 6 Apr 2010 07:21:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 07:21:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 6 Apr 2010 00:21:26 -0700 From: Eran Hammer-Lahav To: Evan Gilbert , OAuth WG , Eran Hammer-Lahav Date: Tue, 6 Apr 2010 00:21:23 -0700 Thread-Topic: [OAUTH-WG] Comments on Web Callback & Client Flow Thread-Index: AcrVF9j6HPVIzb4TSxGcuYCBZqHJJQAQenLV Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 07:21:32 -0000 Hi Evan, On 4/5/10 4:28 PM, "Evan Gilbert" wrote: > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > In both flows,=A0the authorization server should be able redirect back to= the > callback URI without interacting directly with the resource owner if acce= ss > has already been approved. =A0This is not ruled out in the current langua= ge but > it could be made cleaner.=A0 >=20 > Suggested rewording - change >=20 > "After receiving an authorization decision from the resource owner, the s= erver > redirects the resource owner to the callback URI." >=20 > =A0=A0to >=20 > "If the client is already approved or denied for access to the protected > resource, the authorization service MAY redirect the resource owner to th= e > callback URI immediately. If not, the authorization service SHOULD ask th= e > resource owner for an authorization decision and after receiving the > decision=A0redirect the resource owner to the callback URI." I opted for a simpler change: 'After receiving (or establishing via other means) an authorization decision' > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > We should have an OPTIONAL username parameter: > username > =A0=A0The resource owner's username. The authorization server MUST only s= end back > refresh tokens or access tokens for this user. >=20 > This is useful for clients where a user is already logged into a 3rd part= y web > site with a specific account, and the client wants the authorization to m= atch > the specific user. I think introducing the concept of user identity is more complex than just = a username parameter. I agree that it can be useful but we need a more detailed discussion about this before we add it. > 2.4.2 Web Client Flow > Sending an access token as a query parameter is dangerous from a security > perspective - these tokens are leaked via referrers and server logs. In > previous WRAP discussions, it was felt that we should have a strong > recommendation to use the URL fragment. >=20 > Suggested wording: > Client SHOULD send a callback URI with a query fragment, and authorizatio= n > server MAY reject callback URLs without a fragment for security reasons. Why not require it? EHL From beaton@google.com Tue Apr 6 00:37:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E5D3A68E5 for ; Tue, 6 Apr 2010 00:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8AxLZqVw2AH for ; Tue, 6 Apr 2010 00:37:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1395A3A68B0 for ; Tue, 6 Apr 2010 00:37:55 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o367bpl7002242 for ; Tue, 6 Apr 2010 00:37:51 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270539471; bh=w5E4YZdEFuRCkW25rIxdrjuoJNs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=q57S2Ts5MA3cCZitMUwG8HSMH/72jaxeVHUm6/IZMQ36IRvCdv7oMEAUzRx6Fzv81 Sx1W6UYVS6iv4zy4NHryQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=bmrXgFf4pm4EwDPFeJHn6AnZwg++Yx4LucT0YE9nQ826DqV2u3fOdOSb8+3f1kH/H qyo/vd8sJQAF4WszwHs7w== Received: from vws3 (vws3.prod.google.com [10.241.21.131]) by wpaz9.hot.corp.google.com with ESMTP id o367bmLH031022 for ; Tue, 6 Apr 2010 00:37:50 -0700 Received: by vws3 with SMTP id 3so2209992vws.11 for ; Tue, 06 Apr 2010 00:37:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.2 with HTTP; Tue, 6 Apr 2010 00:37:50 -0700 (PDT) In-Reply-To: References: <4BB719F0.70807@lodderstedt.net> Date: Tue, 6 Apr 2010 00:37:50 -0700 Received: by 10.220.48.22 with SMTP id p22mr3173815vcf.213.1270539470589; Tue, 06 Apr 2010 00:37:50 -0700 (PDT) Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 07:37:57 -0000 On Tue, Apr 6, 2010 at 12:13 AM, Eran Hammer-Lahav wrote: > Yep. I'm trying to remove the need for a more complex discovery. Not sure we need to do anything, discovery is pretty simple already. We've been talking a bit about how to enable OAuth for IMAP: http://tech.groups.yahoo.com/group/sasl_oauth/. Here's the rough flow: 1) The hostname of the IMAP server to talk to magically appears. Maybe the user enters it. 2) Client queries the IMAP server. 3) IMAP server points at the OAuth WRAP endpoints. 4) Client opens a browser to get user approval using the rich client flow. 5) Client saves the refresh token instead of the user's password. Ideally the same SASL mechanism would work for XMPP. Cheers, Brian From eran@hueniverse.com Tue Apr 6 00:49:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691EC3A67B5 for ; Tue, 6 Apr 2010 00:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qbUVOQp7liL for ; Tue, 6 Apr 2010 00:48:56 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2EDAB3A6407 for ; Tue, 6 Apr 2010 00:48:56 -0700 (PDT) Received: (qmail 522 invoked from network); 6 Apr 2010 07:48:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 07:48:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Apr 2010 00:47:35 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Tue, 6 Apr 2010 00:47:31 -0700 Thread-Topic: [OAUTH-WG] Scope using Realm idea Thread-Index: AcrVXBLm9gLdOX1mT9KNY2n8+NiAAgAAVZ5u Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E0352331D53eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 07:49:00 -0000 --_000_C7E0352331D53eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That's the same as what I have in the draft, only with a single endpoint in= stead of two. Since we already have a 'mode' parameter (which I am renaming= to 'type'), that single endpoint can speak more than one flow. EHL On 4/6/10 12:37 AM, "Brian Eaton" wrote: On Tue, Apr 6, 2010 at 12:13 AM, Eran Hammer-Lahav wr= ote: > Yep. I'm trying to remove the need for a more complex discovery. Not sure we need to do anything, discovery is pretty simple already. We've been talking a bit about how to enable OAuth for IMAP: http://tech.groups.yahoo.com/group/sasl_oauth/. Here's the rough flow: 1) The hostname of the IMAP server to talk to magically appears. Maybe the user enters it. 2) Client queries the IMAP server. 3) IMAP server points at the OAuth WRAP endpoints. 4) Client opens a browser to get user approval using the rich client flow. 5) Client saves the refresh token instead of the user's password. Ideally the same SASL mechanism would work for XMPP. Cheers, Brian --_000_C7E0352331D53eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Scope using Realm idea That’s the same as what I have in the draft, only with a single= endpoint instead of two. Since we already have a ‘mode’ parame= ter (which I am renaming to ‘type’), that single endpoint can s= peak more than one flow.

EHL


On 4/6/10 12:37 AM, "Brian Eaton" <beaton@google.com> wrote:

On Tue, Apr 6, 2010 at 12:13 AM, Eran Hamme= r-Lahav <eran@hueniverse.com> wro= te:
> Yep. I'm trying to remove the need for a more complex discovery.

Not sure we need to do anything, discovery is pretty simple already.

We've been talking a bit about how to enable OAuth for IMAP:
http://tech.grou= ps.yahoo.com/group/sasl_oauth/.

Here's the rough flow:
1) The hostname of the IMAP server to talk to magically appears.
Maybe the user enters it.
2) Client queries the IMAP server.
3) IMAP server points at the OAuth WRAP endpoints.
4) Client opens a browser to get user approval using the rich client flow.<= BR> 5) Client saves the refresh token instead of the user's password.

Ideally the same SASL mechanism would work for XMPP.

Cheers,
Brian

--_000_C7E0352331D53eranhueniversecom_-- From beaton@google.com Tue Apr 6 00:58:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7977E3A67C0 for ; Tue, 6 Apr 2010 00:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UoHiKnyBiYG for ; Tue, 6 Apr 2010 00:58:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A59703A67A2 for ; Tue, 6 Apr 2010 00:58:11 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o367w9KK021758 for ; Tue, 6 Apr 2010 00:58:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270540689; bh=nslrzHEPOSH250ZLtWFOPgaEEqw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=q7BLiu5VOxo0mA04jhIN0gKKEux0MOeb7R6HIN4Li9ffZn+jcXLFtwsfnzl+W3yGO IIWYUlsxo9xpOOyQMOR1w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=hTSmAINPIWT5pTjDIhdpERUFdKPR2lJqt4fUMRSFpNzY0R8iHzpAOMcyv3aOMe518 Z3QNxSDkwg6zaqBoZkrAA== Received: from vws11 (vws11.prod.google.com [10.241.21.139]) by wpaz1.hot.corp.google.com with ESMTP id o367w7mF010634 for ; Tue, 6 Apr 2010 00:58:08 -0700 Received: by vws11 with SMTP id 11so693224vws.6 for ; Tue, 06 Apr 2010 00:58:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.2 with HTTP; Tue, 6 Apr 2010 00:58:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Apr 2010 00:58:07 -0700 Received: by 10.220.123.214 with SMTP id q22mr3142817vcr.114.1270540687517; Tue, 06 Apr 2010 00:58:07 -0700 (PDT) Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 07:58:12 -0000 On Tue, Apr 6, 2010 at 12:47 AM, Eran Hammer-Lahav wr= ote: > That=92s the same as what I have in the draft, only with a single endpoin= t > instead of two. Since we already have a =91mode=92 parameter (which I am > renaming to =91type=92), that single endpoint can speak more than one flo= w. Note that the discovery flow I outlined only works for rich clients, and is completely insecure for other types of clients. In another thread Leif mentioned similar concerns. I think they are justif= ied. Cheers, Brian From eran@hueniverse.com Tue Apr 6 01:23:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F4E3A6835 for ; Tue, 6 Apr 2010 01:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q0h4jKnktlu for ; Tue, 6 Apr 2010 01:23:57 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E64013A67C0 for ; Tue, 6 Apr 2010 01:23:56 -0700 (PDT) Received: (qmail 4332 invoked from network); 6 Apr 2010 08:23:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 08:23:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 6 Apr 2010 01:23:54 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Tue, 6 Apr 2010 01:23:50 -0700 Thread-Topic: [OAUTH-WG] Scope using Realm idea Thread-Index: AcrVXuacszan0+ysS/CA5NMUp5HougAA5WMz Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E03DA731D57eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 08:23:59 -0000 --_000_C7E03DA731D57eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why? On 4/6/10 12:58 AM, "Brian Eaton" wrote: On Tue, Apr 6, 2010 at 12:47 AM, Eran Hammer-Lahav wr= ote: > That's the same as what I have in the draft, only with a single endpoint > instead of two. Since we already have a 'mode' parameter (which I am > renaming to 'type'), that single endpoint can speak more than one flow. Note that the discovery flow I outlined only works for rich clients, and is completely insecure for other types of clients. In another thread Leif mentioned similar concerns. I think they are justif= ied. Cheers, Brian --_000_C7E03DA731D57eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Scope using Realm idea Why?


On 4/6/10 12:58 AM, "Brian Eaton" <beaton@google.com> wrote:

On Tue, Apr 6, 2010 at 12:47 AM, Eran Hamme= r-Lahav <eran@hueniverse.com> wro= te:
> That’s the same as what I have in the draft, only with a single = endpoint
> instead of two. Since we already have a ‘mode’ parameter (= which I am
> renaming to ‘type’), that single endpoint can speak more t= han one flow.

Note that the discovery flow I outlined only works for rich clients,
and is completely insecure for other types of clients.

In another thread Leif mentioned similar concerns.  I think they are j= ustified.

Cheers,
Brian

--_000_C7E03DA731D57eranhueniversecom_-- From torsten@lodderstedt.net Tue Apr 6 03:24:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9684B3A6ACC for ; Tue, 6 Apr 2010 03:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLe8lBUa8-wO for ; Tue, 6 Apr 2010 03:24:16 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id 19FE93A6ADF for ; Tue, 6 Apr 2010 03:23:33 -0700 (PDT) Received: from [80.187.153.53] (helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Nz5wP-0003yG-QC; Tue, 06 Apr 2010 12:23:30 +0200 Message-ID: <4BBB0B97.6090704@lodderstedt.net> Date: Tue, 06 Apr 2010 12:23:19 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 10:24:17 -0000 Hi Eran, > I agree that this is the right approach (separate parameters to well defined > scope attributes). However, so far the only well-defined attribute is a > protected segment name (aka realm). > how shall we proceed in order to come to more well-defined attributes? I already proposed some, can we discuss them? regards, Torsten. > EHL > > > On 4/3/10 1:25 AM, "Torsten Lodderstedt" wrote: > > >> You are right, there are different aspects of scope. Why not define one >> optional parameter per scope aspect? >> >> Based on our experiences with implementing OAuth 1.0a at Deutsche >> Telekom, I see the need for the following parameters >> - resource: specification of the protected resource to be accessed >> (type: URI or opaque string) >> - requested permissions: permissions on this resource the client want >> to get authorized by the user (comma-separated list of opaque strings). >> The range of permissions is defined by the resource as part of its API >> design. This could be something like "upload", "download", "sent", or >> "establish connection". The set of available permissions might be >> advertised by way of a WWW-Authenticate parameter (status code 401), as >> part of a 403 response, or in a XRDS discovery process. >> - requested duration: specification of the token duration the client >> asks for >> >> regards, >> Torsten. >> >>> ... >>> There isn't one - its service specific. >>> >>> The easy ones are: >>> >>> Duration >>> List of protected resources, URI wildcard, or name of protected segment >>> Read/write access or HTTP methods >>> >>> 3 years ago when we dropped the scope/token_attributes parameter from the >>> spec we decided to bring it back when we have enough deployment experience. >>> I strongly believe this rule still holds. >>> >>> It would be great if those with OAuth 1.0a deployments can share how they >>> specify scope. >>> >>> EHL >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> > From beaton@google.com Tue Apr 6 06:59:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9863A68AC for ; Tue, 6 Apr 2010 06:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHz-zjGB-xPn for ; Tue, 6 Apr 2010 06:59:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id ACC493A685D for ; Tue, 6 Apr 2010 06:59:06 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [10.3.21.3]) by smtp-out.google.com with ESMTP id o36Dx1Un010463 for ; Tue, 6 Apr 2010 15:59:02 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270562342; bh=KUYN+HlGZ0fLWi5HF3PK9kulqjg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=sOMfvw0TPOOYcSWHCDI+GSf2OHl21nlmIWtnPj5AR1J5lfOWgf/xu1VUlwPkZzUMZ 7GHWX29XkdtTc5fuI8LLw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=HXjdueEC6kAqvXseKv5mhuslojc01Vhl+7T3H6U9a7ocHmGz86TtGfNDVvP59fEr+ Ej3EF2DKalIVF3Sdvd5nQ== Received: from vws16 (vws16.prod.google.com [10.241.21.144]) by hpaq3.eem.corp.google.com with ESMTP id o36DwV4N009703 for ; Tue, 6 Apr 2010 15:59:00 +0200 Received: by vws16 with SMTP id 16so388629vws.23 for ; Tue, 06 Apr 2010 06:59:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.2 with HTTP; Tue, 6 Apr 2010 06:58:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Apr 2010 06:58:59 -0700 Received: by 10.220.48.22 with SMTP id p22mr3410338vcf.213.1270562340060; Tue, 06 Apr 2010 06:59:00 -0700 (PDT) Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 13:59:11 -0000 Web clients are expected to have secrets or to have otherwise registered with the AS. In order for them to use those secrets, they need to know the AS URL. Cheers, Brian On Tue, Apr 6, 2010 at 1:23 AM, Eran Hammer-Lahav wro= te: > Why? > > > On 4/6/10 12:58 AM, "Brian Eaton" wrote: > > On Tue, Apr 6, 2010 at 12:47 AM, Eran Hammer-Lahav > wrote: >> That=92s the same as what I have in the draft, only with a single endpoi= nt >> instead of two. Since we already have a =91mode=92 parameter (which I am >> renaming to =91type=92), that single endpoint can speak more than one fl= ow. > > Note that the discovery flow I outlined only works for rich clients, > and is completely insecure for other types of clients. > > In another thread Leif mentioned similar concerns. =A0I think they are > justified. > > Cheers, > Brian > > From uidude@google.com Tue Apr 6 07:05:15 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49EBE3A67B4 for ; Tue, 6 Apr 2010 07:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.676 X-Spam-Level: X-Spam-Status: No, score=-100.676 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1oaxGe0Ds8W for ; Tue, 6 Apr 2010 07:05:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id F30DB3A67F6 for ; Tue, 6 Apr 2010 07:05:10 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o36E568R019381 for ; Tue, 6 Apr 2010 16:05:06 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270562706; bh=xEcGOtrp0EiDqR/TCJnvGFtoVsY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=G5nIE7gJ01LNO0MawRF+dL2iCQUvXry/j4veKylvLe5anWUiMAXaGwW5fYKE99PGD WK9S7MfFclM8ObVwu4rLA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=BXty8iH86sGjeVJpAHZr6LTVu+Z8R/H5wPZlMpKoXLloy8+XcqKEtSRKEUU3TcboO L9Py1TgKCVNiXOBXS3E4Q== Received: from qw-out-2122.google.com (qwh8.prod.google.com [10.241.194.200]) by kpbe17.cbf.corp.google.com with ESMTP id o36E54Sl024433 for ; Tue, 6 Apr 2010 07:05:04 -0700 Received: by qw-out-2122.google.com with SMTP id 8so1964490qwh.59 for ; Tue, 06 Apr 2010 07:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.194 with HTTP; Tue, 6 Apr 2010 07:04:44 -0700 (PDT) In-Reply-To: References: From: Evan Gilbert Date: Tue, 6 Apr 2010 07:04:44 -0700 Received: by 10.229.212.213 with SMTP id gt21mr7399941qcb.2.1270562704282; Tue, 06 Apr 2010 07:05:04 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00163630ebbfa753ef048391ee6f X-System-Of-Record: true Cc: Eran Hammer-Lahav , OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:05:15 -0000 --00163630ebbfa753ef048391ee6f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav wrote: > Hi Evan, > > On 4/5/10 4:28 PM, "Evan Gilbert" wrote: > > > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > > In both flows, the authorization server should be able redirect back to > the > > callback URI without interacting directly with the resource owner if > access > > has already been approved. This is not ruled out in the current language > but > > it could be made cleaner. > > > > Suggested rewording - change > > > > "After receiving an authorization decision from the resource owner, the > server > > redirects the resource owner to the callback URI." > > > > to > > > > "If the client is already approved or denied for access to the protected > > resource, the authorization service MAY redirect the resource owner to > the > > callback URI immediately. If not, the authorization service SHOULD ask > the > > resource owner for an authorization decision and after receiving the > > decision redirect the resource owner to the callback URI." > > I opted for a simpler change: > > 'After receiving (or establishing via other means) an authorization > decision' > Sounds great > > > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > > We should have an OPTIONAL username parameter: > > username > > The resource owner's username. The authorization server MUST only send > back > > refresh tokens or access tokens for this user. > > > > This is useful for clients where a user is already logged into a 3rd > party web > > site with a specific account, and the client wants the authorization to > match > > the specific user. > > I think introducing the concept of user identity is more complex than just > a > username parameter. I agree that it can be useful but we need a more > detailed discussion about this before we add it. > I agree issues around user identity are complex. Would it help to spin up a separate discussion thread on this one issue? > > 2.4.2 Web Client Flow > > Sending an access token as a query parameter is dangerous from a security > > perspective - these tokens are leaked via referrers and server logs. In > > previous WRAP discussions, it was felt that we should have a strong > > recommendation to use the URL fragment. > > > > Suggested wording: > > Client SHOULD send a callback URI with a query fragment, and > authorization > > server MAY reject callback URLs without a fragment for security reasons. > > Why not require it? I made the assumption that someone had use cases that drove the examples in the spec. I would be OK with requiring it. > EHL > > --00163630ebbfa753ef048391ee6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 6, 2010 at 12:21 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
Hi Evan,

On 4/5/10 4:28 PM, "Evan Gilbert" <uidude@google.com> wrote:

> 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
> In both flows,=A0the authorization server should be able redirect back= to the
> callback URI without interacting directly with the resource owner if a= ccess
> has already been approved. =A0This is not ruled out in the current lan= guage but
> it could be made cleaner.=A0
>
> Suggested rewording - change
>
> "After receiving an authorization decision from the resource owne= r, the server
> redirects the resource owner to the callback URI."
>
> =A0=A0to
>
> "If the client is already approved or denied for access to the pr= otected
> resource, the authorization service MAY redirect the resource owner to= the
> callback URI immediately. If not, the authorization service SHOULD ask= the
> resource owner for an authorization decision and after receiving the > decision=A0redirect the resource owner to the callback URI."

I opted for a simpler change:

'After receiving (or establishing via other means) an authorization
decision'

Sounds great
= =A0

> 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
> We should have an OPTIONAL username parameter:
> username
> =A0=A0The resource owner's username. The authorization server MUST= only send back
> refresh tokens or access tokens for this user.
>
> This is useful for clients where a user is already logged into a 3rd p= arty web
> site with a specific account, and the client wants the authorization t= o match
> the specific user.

I think introducing the concept of user identity is more complex than= just a
username parameter. I agree that it can be useful but we need a more
detailed discussion about this before we add it.

<= /div>
I agree issues around user identity are complex.

Would it help to spin up a separate discussion thread on this one = issue?


> 2.4.2 Web Client Flow
> Sending an access token as a query parameter is dangerous from a secur= ity
> perspective - these tokens are leaked via referrers and server logs. I= n
> previous WRAP discussions, it was felt that we should have a strong > recommendation to use the URL fragment.
>
> Suggested wording:
> Client SHOULD send a callback URI with a query fragment, and authoriza= tion
> server MAY reject callback URLs without a fragment for security reason= s.

Why not require it?=A0

I made the assumption tha= t someone had use cases that drove the examples in the spec.

=
I would be OK with requiring it.


EHL


--00163630ebbfa753ef048391ee6f-- From recordond@gmail.com Tue Apr 6 07:53:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C09F3A6962 for ; Tue, 6 Apr 2010 07:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oud0WpT4ehf for ; Tue, 6 Apr 2010 07:53:30 -0700 (PDT) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id 7A06C3A6838 for ; Tue, 6 Apr 2010 07:53:30 -0700 (PDT) Received: by pzk29 with SMTP id 29so261037pzk.29 for ; Tue, 06 Apr 2010 07:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zcXpKZsk4EabtY2qbYFrxxcwRo2b3ZEjOMRM318P0fA=; b=ausVprBlWPlJRniEz1lxEt5BhHwzfI94dPt9aC/i6256/YcAhCd2+bl67YGZ9cuGr0 S55Z7PZitlQftoYpNJvvL2y+f+3n0SznM4wsMIbmSWt4cw/IKNii2K1Yglj7QKTNhijF dUjtK1ptGYDhp2awo51p21yJLs94ivdVZnNco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a8sj5I3f7wDQDd6eTsCcZROY8uTGUBDc4SGuJP5HkuNQU8lkXeaMTajRwPBQlt4f6Y bxx0BUXZObZtj22F9HnlXMb5Jn9mtygTQoai70reKBhQ1sfTT3S/OX3FA03PRra/NQ7t Vrna1kgI+uEHpB5wBJDlszznjV7P8MkM1z5+M= MIME-Version: 1.0 Received: by 10.231.183.18 with HTTP; Tue, 6 Apr 2010 07:53:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Apr 2010 07:53:22 -0700 Received: by 10.141.91.19 with SMTP id t19mr5369369rvl.104.1270565603174; Tue, 06 Apr 2010 07:53:23 -0700 (PDT) Message-ID: From: David Recordon To: Evan Gilbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Eran Hammer-Lahav , OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:53:31 -0000 The web client flow was intended to require either a fragment or SSL (or optionally both). On Tue, Apr 6, 2010 at 7:04 AM, Evan Gilbert wrote: > > > On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav > wrote: >> >> Hi Evan, >> >> On 4/5/10 4:28 PM, "Evan Gilbert" wrote: >> >> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow >> > In both flows,=A0the authorization server should be able redirect back= to >> > the >> > callback URI without interacting directly with the resource owner if >> > access >> > has already been approved. =A0This is not ruled out in the current >> > language but >> > it could be made cleaner. >> > >> > Suggested rewording - change >> > >> > "After receiving an authorization decision from the resource owner, th= e >> > server >> > redirects the resource owner to the callback URI." >> > >> > =A0=A0to >> > >> > "If the client is already approved or denied for access to the protect= ed >> > resource, the authorization service MAY redirect the resource owner to >> > the >> > callback URI immediately. If not, the authorization service SHOULD ask >> > the >> > resource owner for an authorization decision and after receiving the >> > decision=A0redirect the resource owner to the callback URI." >> >> I opted for a simpler change: >> >> 'After receiving (or establishing via other means) an authorization >> decision' > > Sounds great > >> >> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow >> > We should have an OPTIONAL username parameter: >> > username >> > =A0=A0The resource owner's username. The authorization server MUST onl= y send >> > back >> > refresh tokens or access tokens for this user. >> > >> > This is useful for clients where a user is already logged into a 3rd >> > party web >> > site with a specific account, and the client wants the authorization t= o >> > match >> > the specific user. >> >> I think introducing the concept of user identity is more complex than ju= st >> a >> username parameter. I agree that it can be useful but we need a more >> detailed discussion about this before we add it. > > I agree issues around user identity are complex. > Would it help to spin up a separate discussion thread on this one issue? >> >> > 2.4.2 Web Client Flow >> > Sending an access token as a query parameter is dangerous from a >> > security >> > perspective - these tokens are leaked via referrers and server logs. I= n >> > previous WRAP discussions, it was felt that we should have a strong >> > recommendation to use the URL fragment. >> > >> > Suggested wording: >> > Client SHOULD send a callback URI with a query fragment, and >> > authorization >> > server MAY reject callback URLs without a fragment for security reason= s. >> >> Why not require it? > > I made the assumption that someone had use cases that drove the examples = in > the spec. > I would be OK with requiring it. >> >> EHL >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From dick.hardt@gmail.com Tue Apr 6 08:03:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A4B3A6946 for ; Tue, 6 Apr 2010 08:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaMoTZROiCnK for ; Tue, 6 Apr 2010 08:03:53 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 781BE3A685D for ; Tue, 6 Apr 2010 08:03:53 -0700 (PDT) Received: by fxm5 with SMTP id 5so4160021fxm.29 for ; Tue, 06 Apr 2010 08:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Uk6v8UeKY84ZwKaljAKA9Sy/wzj/o7qHnTSyYE6siYc=; b=uarbgqoibfrJCsFvi/ZOGrbQAifeFYerseR6CfXkfZGpNDlEbeIQmhVMfdgn18KS5Q yKysKwvqqpr35DaEa8mLWB0hHNOglfx8Wui366/zr/CgfKQIAxB3ksyz8KNpnpqNkgmM NrA31DaTlTujvdKNfl9FiKiNOsUb6imZRLEq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=cMYvYqz/wUpF8myC5pq89uiOCtkXgyhTrWUxKoJrtIymuPu8uEJApebhFzibKQo77P KlKuQQ/fYIOChhS89izrCzYE1/uLHM0/hs316/lK4Aj/54+9PuCFaINwggeYEokS3650 h9SzCB2jR9GqcQnmIeZ0BSRqDGjPOApRwPVZ0= Received: by 10.87.13.6 with SMTP id q6mr10302922fgi.19.1270566226958; Tue, 06 Apr 2010 08:03:46 -0700 (PDT) Received: from [10.10.1.129] (ip67-152-86-163.z86-152-67.customer.algx.net [67.152.86.163]) by mx.google.com with ESMTPS id 4sm15525678fge.23.2010.04.06.08.03.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Apr 2010 08:03:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Tue, 6 Apr 2010 08:03:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0E777AD1-500D-4FEA-BBAB-069060A40D73@gmail.com> References: To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:03:54 -0000 On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote: >=20 >=20 >=20 > On 4/2/10 3:27 PM, "Dick Hardt" wrote: >=20 >> There are times when a resource may have different scope for = different kinds >> of access. realm !=3D scope >=20 > No. Realm is a subset. It is what people define as the protected = segment > name. Different Protected Resources could require the same scope, so I see = realm and scope as being orthogonal. > For any other scope attribute we need to first define it. Why? Scope will often be application specific. From lshepard@facebook.com Tue Apr 6 08:27:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99CA43A693C for ; Tue, 6 Apr 2010 08:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4tX+Tf92Hqv for ; Tue, 6 Apr 2010 08:27:27 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id D65263A6921 for ; Tue, 6 Apr 2010 08:27:27 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.212]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o36FR64P015198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 6 Apr 2010 08:27:06 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.682.1; Tue, 6 Apr 2010 08:26:16 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Tue, 6 Apr 2010 08:24:32 -0700 From: Luke Shepard To: Eran Hammer-Lahav Date: Tue, 6 Apr 2010 08:24:30 -0700 Thread-Topic: [OAUTH-WG] Renaming expires to expires_in? Thread-Index: AcrVnUFHfbQyCkOXQVChAWIe6+ALOQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DD9BF2EB06264FD4B721D31898D854AAfacebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-06_11:2010-02-06, 2010-04-06, 2010-04-06 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Renaming expires to expires_in? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:27:28 -0000 --_000_DD9BF2EB06264FD4B721D31898D854AAfacebookcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just curious, where did "duration" come from? I hate to be picky, but I feel like "expires_in" is more clear than "durati= on" ... if only because other protocols (OAuth 1.0a, OpenID, Facebook auth)= use "expires". On Apr 6, 2010, at 12:11 AM, Eran Hammer-Lahav wrote: Changed to =91duration=92. EHL On 4/5/10 9:09 AM, "David Recordon" > wrote: As one of our engineers was implementing a client, they got confused about = what was being returned by the expires parameter. Anyone object to renaming= it to expires_in so that it's clear that it isn't an absolute timestamp? Thanks, --David _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_DD9BF2EB06264FD4B721D31898D854AAfacebookcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just curious, where did "d= uration" come from?

I hate to be picky, but I feel like = "expires_in" is more clear than "duration" ... if only because other protoc= ols (OAuth 1.0a, OpenID, Facebook auth) use "expires".

<= div>On Apr 6, 2010, at 12:11 AM, Eran Hammer-Lahav wrote:

Changed to =91duration=92.

EHL


On 4/5/10 9:09 AM, "David Recordon" <davidrecordon@facebook.com> wrote:

As one of our engineers was implementing a = client, they got confused about what was being returned by the expires para= meter. Anyone object to renaming it to expires_in so that it's clear that i= t isn't an absolute timestamp?

Thanks,
--David
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

<ATT00001..txt>

= --_000_DD9BF2EB06264FD4B721D31898D854AAfacebookcom_-- From lshepard@facebook.com Tue Apr 6 08:32:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D023A6765 for ; Tue, 6 Apr 2010 08:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk6vPqYPr7l4 for ; Tue, 6 Apr 2010 08:32:37 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 9F8133A6838 for ; Tue, 6 Apr 2010 08:32:34 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.212]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o36FVdei008068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 6 Apr 2010 08:31:45 -0700 Received: from sc-hub02.TheFacebook.com (192.168.18.105) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.682.1; Tue, 6 Apr 2010 08:31:32 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Tue, 6 Apr 2010 08:29:32 -0700 From: Luke Shepard To: Dick Hardt Date: Tue, 6 Apr 2010 08:29:30 -0700 Thread-Topic: [OAUTH-WG] Scope using Realm idea Thread-Index: AcrVnfQ34LAmIKgqTI2e0H2/hyNDyA== Message-ID: <27B54FC8-6C50-4283-89AF-6EB44A6FD006@facebook.com> References: <0E777AD1-500D-4FEA-BBAB-069060A40D73@gmail.com> In-Reply-To: <0E777AD1-500D-4FEA-BBAB-069060A40D73@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-06_11:2010-02-06, 2010-04-06, 2010-04-06 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:32:38 -0000 For Facebook at least, we are currently planning to use scope as a comma-se= parated list of permissions from this set: http://wiki.developers.facebook.= com/index.php/Extended_permissions For instance: oauth_scope=3Dread_stream,email,photo_upload I'm not sure if that maps to realm exactly. On Apr 6, 2010, at 8:03 AM, Dick Hardt wrote: >=20 > On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote: >=20 >>=20 >>=20 >>=20 >> On 4/2/10 3:27 PM, "Dick Hardt" wrote: >>=20 >>> There are times when a resource may have different scope for different = kinds >>> of access. realm !=3D scope >>=20 >> No. Realm is a subset. It is what people define as the protected segment >> name. >=20 > Different Protected Resources could require the same scope, so I see real= m and scope as being orthogonal. >=20 >> For any other scope attribute we need to first define it. >=20 > Why? Scope will often be application specific. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From uidude@google.com Tue Apr 6 08:46:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE5A3A68AA for ; Tue, 6 Apr 2010 08:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03yPV0eiR0QQ for ; Tue, 6 Apr 2010 08:46:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C1C843A686A for ; Tue, 6 Apr 2010 08:46:22 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o36FkHNx013188 for ; Tue, 6 Apr 2010 08:46:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270568777; bh=3r4R+9E+CkvDkY7eNv6zASCpSsQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZckSIzTWER6fSAqHfSSv4Qis7PCNhDE3zo69iBtHOA70Sg2u5QVMtRdcoV4DpbHfw U8iU08pgcz63y329oUP0A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=mBNvyxs2u14YNKkjrrZ3i/dGxc4iaaas+Jtc4r76kSoDist2mckwrks80Lnk7Mg58 sWxesoYVMu5dFq0mX3+cg== Received: from qw-out-1920.google.com (qwk4.prod.google.com [10.241.195.132]) by wpaz29.hot.corp.google.com with ESMTP id o36FkFto010500 for ; Tue, 6 Apr 2010 08:46:16 -0700 Received: by qw-out-1920.google.com with SMTP id 4so3332qwk.6 for ; Tue, 06 Apr 2010 08:46:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.194 with HTTP; Tue, 6 Apr 2010 08:45:53 -0700 (PDT) In-Reply-To: References: From: Evan Gilbert Date: Tue, 6 Apr 2010 08:45:53 -0700 Received: by 10.229.222.12 with SMTP id ie12mr406854qcb.77.1270568775559; Tue, 06 Apr 2010 08:46:15 -0700 (PDT) Message-ID: To: David Recordon Content-Type: multipart/alternative; boundary=00163630fd5b87ac970483935876 X-System-Of-Record: true Cc: Eran Hammer-Lahav , OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:46:25 -0000 --00163630fd5b87ac970483935876 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 6, 2010 at 7:53 AM, David Recordon wrote: > The web client flow was intended to require either a fragment or SSL > (or optionally both). > Even with SSL, referrer leaks seem to be a danger (I think https referrers are still sent). Are we worried about this? > > > On Tue, Apr 6, 2010 at 7:04 AM, Evan Gilbert wrote: > > > > > > On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav > > wrote: > >> > >> Hi Evan, > >> > >> On 4/5/10 4:28 PM, "Evan Gilbert" wrote: > >> > >> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > >> > In both flows, the authorization server should be able redirect back > to > >> > the > >> > callback URI without interacting directly with the resource owner if > >> > access > >> > has already been approved. This is not ruled out in the current > >> > language but > >> > it could be made cleaner. > >> > > >> > Suggested rewording - change > >> > > >> > "After receiving an authorization decision from the resource owner, > the > >> > server > >> > redirects the resource owner to the callback URI." > >> > > >> > to > >> > > >> > "If the client is already approved or denied for access to the > protected > >> > resource, the authorization service MAY redirect the resource owner to > >> > the > >> > callback URI immediately. If not, the authorization service SHOULD ask > >> > the > >> > resource owner for an authorization decision and after receiving the > >> > decision redirect the resource owner to the callback URI." > >> > >> I opted for a simpler change: > >> > >> 'After receiving (or establishing via other means) an authorization > >> decision' > > > > Sounds great > > > >> > >> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > >> > We should have an OPTIONAL username parameter: > >> > username > >> > The resource owner's username. The authorization server MUST only > send > >> > back > >> > refresh tokens or access tokens for this user. > >> > > >> > This is useful for clients where a user is already logged into a 3rd > >> > party web > >> > site with a specific account, and the client wants the authorization > to > >> > match > >> > the specific user. > >> > >> I think introducing the concept of user identity is more complex than > just > >> a > >> username parameter. I agree that it can be useful but we need a more > >> detailed discussion about this before we add it. > > > > I agree issues around user identity are complex. > > Would it help to spin up a separate discussion thread on this one issue? > >> > >> > 2.4.2 Web Client Flow > >> > Sending an access token as a query parameter is dangerous from a > >> > security > >> > perspective - these tokens are leaked via referrers and server logs. > In > >> > previous WRAP discussions, it was felt that we should have a strong > >> > recommendation to use the URL fragment. > >> > > >> > Suggested wording: > >> > Client SHOULD send a callback URI with a query fragment, and > >> > authorization > >> > server MAY reject callback URLs without a fragment for security > reasons. > >> > >> Why not require it? > > > > I made the assumption that someone had use cases that drove the examples > in > > the spec. > > I would be OK with requiring it. > >> > >> EHL > >> > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > --00163630fd5b87ac970483935876 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 6, 2010 at 7:53 AM, David Re= cordon <recordond@gmail.com> wrote:
The web client flow was intended to require either a fragment or SSL
(or optionally both).

Even with SSL, re= ferrer leaks seem to be a danger (I think https referrers are still sent). = Are we worried about this?
=A0
uidude@google.com> wrote:
>
>
> On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>>
>> Hi Evan,
>>
>> On 4/5/10 4:28 PM, "Evan Gilbert" <uidude@google.com> wrote:
>>
>> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
>> > In both flows,=A0the authorization server should be able redi= rect back to
>> > the
>> > callback URI without interacting directly with the resource o= wner if
>> > access
>> > has already been approved. =A0This is not ruled out in the cu= rrent
>> > language but
>> > it could be made cleaner.
>> >
>> > Suggested rewording - change
>> >
>> > "After receiving an authorization decision from the reso= urce owner, the
>> > server
>> > redirects the resource owner to the callback URI."
>> >
>> > =A0=A0to
>> >
>> > "If the client is already approved or denied for access = to the protected
>> > resource, the authorization service MAY redirect the resource= owner to
>> > the
>> > callback URI immediately. If not, the authorization service S= HOULD ask
>> > the
>> > resource owner for an authorization decision and after receiv= ing the
>> > decision=A0redirect the resource owner to the callback URI.&q= uot;
>>
>> I opted for a simpler change:
>>
>> 'After receiving (or establishing via other means) an authoriz= ation
>> decision'
>
> Sounds great
>
>>
>> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
>> > We should have an OPTIONAL username parameter:
>> > username
>> > =A0=A0The resource owner's username. The authorization se= rver MUST only send
>> > back
>> > refresh tokens or access tokens for this user.
>> >
>> > This is useful for clients where a user is already logged int= o a 3rd
>> > party web
>> > site with a specific account, and the client wants the author= ization to
>> > match
>> > the specific user.
>>
>> I think introducing the concept of user identity is more complex t= han just
>> a
>> username parameter. I agree that it can be useful but we need a mo= re
>> detailed discussion about this before we add it.
>
> I agree issues around user identity are complex.
> Would it help to spin up a separate discussion thread on this one issu= e?
>>
>> > 2.4.2 Web Client Flow
>> > Sending an access token as a query parameter is dangerous fro= m a
>> > security
>> > perspective - these tokens are leaked via referrers and serve= r logs. In
>> > previous WRAP discussions, it was felt that we should have a = strong
>> > recommendation to use the URL fragment.
>> >
>> > Suggested wording:
>> > Client SHOULD send a callback URI with a query fragment, and<= br> >> > authorization
>> > server MAY reject callback URLs without a fragment for securi= ty reasons.
>>
>> Why not require it?
>
> I made the assumption that someone had use cases that drove the exampl= es in
> the spec.
> I would be OK with requiring it.
>>
>> EHL
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--00163630fd5b87ac970483935876-- From torsten@lodderstedt.net Tue Apr 6 10:00:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD0F28C0DB for ; Tue, 6 Apr 2010 10:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b4sVnDHF-9i for ; Tue, 6 Apr 2010 10:00:49 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by core3.amsl.com (Postfix) with ESMTP id 8A4EE3A67E7 for ; Tue, 6 Apr 2010 10:00:49 -0700 (PDT) Received: from p4fff04d5.dip.t-dialin.net ([79.255.4.213] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1NzC8r-0003fw-Sh for oauth@ietf.org; Tue, 06 Apr 2010 19:00:46 +0200 Message-ID: <4BBB68BB.4010206@lodderstedt.net> Date: Tue, 06 Apr 2010 19:00:43 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: [OAUTH-WG] Access Token Exchange Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:00:50 -0000 Hi all, here at Deutsche Telekom, we see the need for a flow supporting the exchange of access tokens for one service into access tokens for another service. The scenarios is as follows: In the context of mobile applications, we employ multi-layered architectures of personalized web services. The first layer typically exposes an API optimized for the flows of a particular application. This layer's business logic is built on top of other web services and so on. We use self-contained bearer tokens carrying id's, attributes and permissions. Each of the web services involed has a trust relationship with our authorization server based on shared secrets. Every web service requires a different token with different claims (id, permissions, attributes) and signature (HMAC). The flow is as follows: 1) The client acquires a token for the first service eather by username/password authentication or web-based authorization flow. 2) The client sends a request (including the access token) to the first web service. 3) Access control and some business logic is executed based on the token contents. Afterwards, the first service determines that it needs to call another services (second web service) on behalf of the user. 4) It requests the issuance of a new token for the second service from the authorization server based on the original token sent by the client. 5) The authorization server issues a new token carrying the claims need by the second web service and digitally signs the token with the respective shared secret. It also encrypts the token content in order to prevent the first web service from eavesdropping the users data intended for the second service only. 6) The first web service uses the token to invoke the second web service. ... Does anyone else see the need for such a flow? regards, Torsten. From recordond@gmail.com Tue Apr 6 11:17:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E89E28C168 for ; Tue, 6 Apr 2010 11:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0Ru5tLEkfBc for ; Tue, 6 Apr 2010 11:17:49 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id F1ADB28C10F for ; Tue, 6 Apr 2010 11:14:41 -0700 (PDT) Received: by pvd12 with SMTP id 12so133580pvd.31 for ; Tue, 06 Apr 2010 11:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=SiNkKfaDdFvi98TJAOoMZKBB5DDitYRcRADzwwpl630=; b=t2RVCdzWOGeD24uK4R8oVmk1Okt5JcllzOT9LsbS9R5Ec7KTts/fTrqrKq2CUAu2yd csG1Fjs3z/20Wt2v0XRmKUW2oJ7XqW9fxGr/LKPNWXR4jQRA6JHhon8ItfzK5W18szOm aXFmbwlmV6uChC+UwMxGKXnjXJRmvQg8qQvgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=GhfRY9pvCDivwVDInHWF+sUGq5aoHlvkxHI4RTMF67jUDzh3UnTkAB7905GyyY+Itw OgWt0EA4JkO1C8HpwLCmqCcaIGS9p5uWDedg/aH5m9BtHzYMK80uPBL2g/t5G4FKNj51 yJEtTs7pDDHXOIoAO/vFQaedesOY8AuB7AMQc= Received: by 10.141.13.6 with SMTP id q6mr5837613rvi.196.1270577676534; Tue, 06 Apr 2010 11:14:36 -0700 (PDT) Received: from [10.39.142.115] ([205.248.100.252]) by mx.google.com with ESMTPS id 22sm707306pzk.13.2010.04.06.11.14.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Apr 2010 11:14:35 -0700 (PDT) References: Message-Id: <2EB1540C-6B2C-4053-8153-545E80A90968@gmail.com> From: David Recordon To: Evan Gilbert In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-27-212729298 Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (7B367) Mime-Version: 1.0 (iPad Mail 7B367) Date: Tue, 6 Apr 2010 11:15:04 -0700 Cc: Eran Hammer-Lahav , OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:17:51 -0000 --Apple-Mail-27-212729298 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable There is potential for leakage if the client then redirects the user to = another SSL URL. This doesn't feel like a common pattern and the client = would generally be redirecting to a page which they control after = receiving the access token. =46rom 15.1.3 of RFC 2616: Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP = request if the referring page was transferred with a secure protocol. On Apr 6, 2010, at 8:45 AM, Evan Gilbert wrote: >=20 >=20 > On Tue, Apr 6, 2010 at 7:53 AM, David Recordon = wrote: > The web client flow was intended to require either a fragment or SSL > (or optionally both). >=20 > Even with SSL, referrer leaks seem to be a danger (I think https = referrers are still sent). Are we worried about this? > =20 >=20 >=20 > On Tue, Apr 6, 2010 at 7:04 AM, Evan Gilbert = wrote: > > > > > > On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav = > > wrote: > >> > >> Hi Evan, > >> > >> On 4/5/10 4:28 PM, "Evan Gilbert" wrote: > >> > >> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > >> > In both flows, the authorization server should be able redirect = back to > >> > the > >> > callback URI without interacting directly with the resource owner = if > >> > access > >> > has already been approved. This is not ruled out in the current > >> > language but > >> > it could be made cleaner. > >> > > >> > Suggested rewording - change > >> > > >> > "After receiving an authorization decision from the resource = owner, the > >> > server > >> > redirects the resource owner to the callback URI." > >> > > >> > to > >> > > >> > "If the client is already approved or denied for access to the = protected > >> > resource, the authorization service MAY redirect the resource = owner to > >> > the > >> > callback URI immediately. If not, the authorization service = SHOULD ask > >> > the > >> > resource owner for an authorization decision and after receiving = the > >> > decision redirect the resource owner to the callback URI." > >> > >> I opted for a simpler change: > >> > >> 'After receiving (or establishing via other means) an authorization > >> decision' > > > > Sounds great > > > >> > >> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > >> > We should have an OPTIONAL username parameter: > >> > username > >> > The resource owner's username. The authorization server MUST = only send > >> > back > >> > refresh tokens or access tokens for this user. > >> > > >> > This is useful for clients where a user is already logged into a = 3rd > >> > party web > >> > site with a specific account, and the client wants the = authorization to > >> > match > >> > the specific user. > >> > >> I think introducing the concept of user identity is more complex = than just > >> a > >> username parameter. I agree that it can be useful but we need a = more > >> detailed discussion about this before we add it. > > > > I agree issues around user identity are complex. > > Would it help to spin up a separate discussion thread on this one = issue? > >> > >> > 2.4.2 Web Client Flow > >> > Sending an access token as a query parameter is dangerous from a > >> > security > >> > perspective - these tokens are leaked via referrers and server = logs. In > >> > previous WRAP discussions, it was felt that we should have a = strong > >> > recommendation to use the URL fragment. > >> > > >> > Suggested wording: > >> > Client SHOULD send a callback URI with a query fragment, and > >> > authorization > >> > server MAY reject callback URLs without a fragment for security = reasons. > >> > >> Why not require it? > > > > I made the assumption that someone had use cases that drove the = examples in > > the spec. > > I would be OK with requiring it. > >> > >> EHL > >> > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > >=20 --Apple-Mail-27-212729298 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There is potential for leakage if = the client then redirects the user to another SSL URL. This doesn't feel = like a common pattern and the client would generally be redirecting to a = page which they control after receiving the access = token.

=46rom 15.1.3 of RFC = 2616:
Clients SHOULD NOT include a Referer header field in a = (non-secure) HTTP request if the referring page was transferred with a = secure protocol.


On Apr 6, 2010, at = 8:45 AM, Evan Gilbert <uidude@google.com> = wrote:



On Tue, Apr 6, 2010 at 7:53 AM, David Recordon = <recordond@gmail.com>= wrote:
The web client flow was intended to require either a fragment or SSL
(or optionally both).

Even with SSL, = referrer leaks seem to be a danger (I think https referrers are still = sent). Are we worried about this?
 


On Tue, Apr 6, 2010 at 7:04 AM, Evan Gilbert <uidude@google.com> = wrote:
>
>
> On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>>
>> Hi Evan,
>>
>> On 4/5/10 4:28 PM, "Evan Gilbert" <uidude@google.com> = wrote:
>>
>> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
>> > In both flows, the authorization server should be = able redirect back to
>> > the
>> > callback URI without interacting directly with the = resource owner if
>> > access
>> > has already been approved.  This is not ruled out in = the current
>> > language but
>> > it could be made cleaner.
>> >
>> > Suggested rewording - change
>> >
>> > "After receiving an authorization decision from the = resource owner, the
>> > server
>> > redirects the resource owner to the callback URI."
>> >
>> >   to
>> >
>> > "If the client is already approved or denied for access to = the protected
>> > resource, the authorization service MAY redirect the = resource owner to
>> > the
>> > callback URI immediately. If not, the authorization = service SHOULD ask
>> > the
>> > resource owner for an authorization decision and after = receiving the
>> > decision redirect the resource owner to the callback = URI."
>>
>> I opted for a simpler change:
>>
>> 'After receiving (or establishing via other means) an = authorization
>> decision'
>
> Sounds great
>
>>
>> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
>> > We should have an OPTIONAL username parameter:
>> > username
>> >   The resource owner's username. The = authorization server MUST only send
>> > back
>> > refresh tokens or access tokens for this user.
>> >
>> > This is useful for clients where a user is already logged = into a 3rd
>> > party web
>> > site with a specific account, and the client wants the = authorization to
>> > match
>> > the specific user.
>>
>> I think introducing the concept of user identity is more = complex than just
>> a
>> username parameter. I agree that it can be useful but we need a = more
>> detailed discussion about this before we add it.
>
> I agree issues around user identity are complex.
> Would it help to spin up a separate discussion thread on this one = issue?
>>
>> > 2.4.2 Web Client Flow
>> > Sending an access token as a query parameter is dangerous = from a
>> > security
>> > perspective - these tokens are leaked via referrers and = server logs. In
>> > previous WRAP discussions, it was felt that we should have = a strong
>> > recommendation to use the URL fragment.
>> >
>> > Suggested wording:
>> > Client SHOULD send a callback URI with a query fragment, = and
>> > authorization
>> > server MAY reject callback URLs without a fragment for = security reasons.
>>
>> Why not require it?
>
> I made the assumption that someone had use cases that drove the = examples in
> the spec.
> I would be OK with requiring it.
>>
>> EHL
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/= mailman/listinfo/oauth
>
>

= --Apple-Mail-27-212729298-- From atom@yahoo-inc.com Tue Apr 6 11:34:15 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1088228C151 for ; Tue, 6 Apr 2010 11:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.602 X-Spam-Level: X-Spam-Status: No, score=-13.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nNRXTjeBXY6 for ; Tue, 6 Apr 2010 11:34:10 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 356F93A6976 for ; Tue, 6 Apr 2010 11:27:50 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o36IRQ44009417 for ; Tue, 6 Apr 2010 11:27:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:mime-version:content-type:x-originalarrivaltime; b=YKc+z2hqusOFBsBtDGtJwu8Dz32O1BGOC8zGr7p64o7gAj/wMzTKkQUPV8dwekde Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 11:27:26 -0700 Received: from 10.72.244.202 ([10.72.244.202]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Tue, 6 Apr 2010 18:26:40 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 06 Apr 2010 11:26:39 -0700 From: Allen Tom To: "oauth@ietf.org" Message-ID: Thread-Topic: HTTPS requirement for using an Access Token without signatures Thread-Index: AcrVtrKPc2+a+5PkjUWcdom/sx3EFA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3353398000_386279" X-OriginalArrivalTime: 06 Apr 2010 18:27:26.0328 (UTC) FILETIME=[CEC54780:01CAD5B6] Subject: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:34:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3353398000_386279 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable One of the biggest differences between OAuth2 and WRAP is that OAuth2 requires that Protected Resources be accessed using HTTPS if no signature i= s being used. Bullet Point #2 in Section 1.2 says: =A0=A0=A04. Don't allow bearer tokens without either SSL and/or signatures. =A0=A0=A0=A0=A0=A0=A0While some providers may offer this ability, they should be out =A0=A0=A0=A0=A0=A0=A0of spec for doing so though technically it won't break the flows. While I personally think that requiring SSL is a fantastic idea, and it=B9s very hard for me to argue against it, however.... One of the goals for WRAP was to define a standard AuthZ interface for APIs which matched what we currently have on the Web. WRAP protected APIs are intended to be a replacement for screen scraping. On the web, almost all websites implement Cookie Auth. Specifically, when you log into a website, the browser is issued a bearer token, called a Cookie, and the browser is able to access Protected Resources by using the Cookie as the credential. The WRAP access token is intended to be a direct replacement for the HTTP Cookie. A client should be able to present its bearer token (a WRAP Access Token or an HTTP Cookie) without having to sign the request. While I certainly think that requiring SSL would be a huge improvement in internet security, HTTP does not require SSL, and since WRAP was intended t= o be a replacement for HTTP Cookie Auth, then OAuth2 should also not require HTTPS. Yes, dropping the SSL requirement isn=B9t optimal, but again the intent with WRAP was to replace HTTP Cookie auth, and it should be up to the service provider to require HTTPS when applicable. Allen --B_3353398000_386279 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable HTTPS requirement for using an Access Token without signatures</TITL= E> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>One of the biggest differences between OAuth2 and WRAP is that OAuth2 requ= ires that Protected Resources be accessed using HTTPS if no signature is bei= ng used. Bullet Point #2 in Section 1.2 says:<BR> <BR> =A0=A0=A04.  Don't allow bearer tokens without either SSL and/or signatures.= <BR> =A0=A0=A0=A0=A0=A0=A0While some providers may offer this ability, they should be out<BR> =A0=A0=A0=A0=A0=A0=A0of spec for doing so though technically it won't break the flows.<BR= > <BR> While I personally think that requiring SSL is a fantastic idea, and itR= 17;s very hard for me to argue against it, however....<BR> <BR> One of the goals for WRAP was to define a standard AuthZ interface for APIs= which matched what we currently have on the Web. WRAP protected APIs are in= tended to be a replacement for screen scraping.<BR> <BR> On the web, almost all websites implement Cookie Auth. Specifically, when y= ou log into a website, the browser is issued a bearer token, called a Cookie= , and the browser is able to access Protected Resources by using the Cookie = as the credential. <BR> <BR> The WRAP access token is intended to be a direct replacement for the HTTP C= ookie. A client should be able to present its bearer token (a WRAP Access To= ken or an HTTP Cookie) without having to sign the request.<BR> <BR> While I certainly think that requiring SSL would be a huge improvement in i= nternet security, HTTP does not require SSL, and since WRAP was intended to = be a replacement for HTTP Cookie Auth, then OAuth2 should also not require H= TTPS.<BR> <BR> Yes, dropping the SSL requirement isn’t optimal, but again the intent= with WRAP was to replace HTTP Cookie auth, and it should be up to the servi= ce provider to require HTTPS when applicable. <BR> <BR> Allen<BR> </SPAN></FONT> </BODY> </HTML> --B_3353398000_386279-- From uidude@google.com Tue Apr 6 11:44:22 2010 Return-Path: <uidude@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5F928C0D6 for <oauth@core3.amsl.com>; Tue, 6 Apr 2010 11:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.046 X-Spam-Level: X-Spam-Status: No, score=-105.046 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGgKWtFdATuX for <oauth@core3.amsl.com>; Tue, 6 Apr 2010 11:44:21 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id AE2AA3A69EC for <oauth@ietf.org>; Tue, 6 Apr 2010 11:42:55 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [10.3.21.14]) by smtp-out.google.com with ESMTP id o36IgpCI031553 for <oauth@ietf.org>; Tue, 6 Apr 2010 11:42:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270579372; bh=4/xGyX4kuIzk0M1ivWwAyWcsCFY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=YQB5RhOKNU072lZxptu/7Ln8r2yv+UDjQg5NZS3B9uhbH86hb9qHKChJ06MTFhXvR JTtnQ3CoxZ0Qj0qe8+PQg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=JOPUNBjiJ30tJ3iE54THtl0dybFSjwJdtYg0E56+HXRpvB8TXMJcQru5zFfEkSX6N Jzdi7mzV5nWz1S8CjIrSA== Received: from qw-out-2122.google.com (qwb9.prod.google.com [10.241.193.73]) by hpaq14.eem.corp.google.com with ESMTP id o36IgoVH002657 for <oauth@ietf.org>; Tue, 6 Apr 2010 20:42:50 +0200 Received: by qw-out-2122.google.com with SMTP id 9so68197qwb.57 for <oauth@ietf.org>; Tue, 06 Apr 2010 11:42:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.194 with HTTP; Tue, 6 Apr 2010 11:42:29 -0700 (PDT) In-Reply-To: <C7E0CAEF.29FA4%atom@yahoo-inc.com> References: <C7E0CAEF.29FA4%atom@yahoo-inc.com> From: Evan Gilbert <uidude@google.com> Date: Tue, 6 Apr 2010 11:42:29 -0700 Received: by 10.229.189.212 with SMTP id df20mr5347815qcb.21.1270579369335; Tue, 06 Apr 2010 11:42:49 -0700 (PDT) Message-ID: <q2ic8689b661004061142n506903b9r620c73d1b3ddf651@mail.gmail.com> To: Allen Tom <atom@yahoo-inc.com> Content-Type: multipart/alternative; boundary=0016362849bef7dba4048395cfa3 X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 06 Apr 2010 18:44:22 -0000 --0016362849bef7dba4048395cfa3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Apr 6, 2010 at 11:26 AM, Allen Tom <atom@yahoo-inc.com> wrote: > One of the biggest differences between OAuth2 and WRAP is that OAuth2 > requires that Protected Resources be accessed using HTTPS if no signature= is > being used. Bullet Point #2 in Section 1.2 says: > > 4. Don't allow bearer tokens without either SSL and/or signatures. > While some providers may offer this ability, they should be out > of spec for doing so though technically it won't break the flows. > > While I personally think that requiring SSL is a fantastic idea, and it= =92s > very hard for me to argue against it, however.... > > One of the goals for WRAP was to define a standard AuthZ interface for AP= Is > which matched what we currently have on the Web. WRAP protected APIs are > intended to be a replacement for screen scraping. > > On the web, almost all websites implement Cookie Auth. Specifically, when > you log into a website, the browser is issued a bearer token, called a > Cookie, and the browser is able to access Protected Resources by using th= e > Cookie as the credential. > > The WRAP access token is intended to be a direct replacement for the HTTP > Cookie. A client should be able to present its bearer token (a WRAP Acces= s > Token or an HTTP Cookie) without having to sign the request. > > While I certainly think that requiring SSL would be a huge improvement in > internet security, HTTP does not require SSL, and since WRAP was intended= to > be a replacement for HTTP Cookie Auth, then OAuth2 should also not requir= e > HTTPS. > > Yes, dropping the SSL requirement isn=92t optimal, but again the intent w= ith > WRAP was to replace HTTP Cookie auth, and it should be up to the service > provider to require HTTPS when applicable. > I tend to agree that this is a SHOULD and not a MUST. There is a wide range of types of protected resources, and many of these resources are already available over HTTP connections. It probably should be a choice by the authorization endpoint whether to allow non-HTTPS access. > Allen > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0016362849bef7dba4048395cfa3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Tue, Apr 6, 2010 at 11:26 AM, Allen T= om <span dir=3D"ltr"><<a href=3D"mailto:atom@yahoo-inc.com" target=3D"_b= lank">atom@yahoo-inc.com</a>></span> wrote:<br><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex"> <div> <font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:= 11pt">One of the biggest differences between OAuth2 and WRAP is that OAuth2= requires that Protected Resources be accessed using HTTPS if no signature = is being used. Bullet Point #2 in Section 1.2 says:<br> <br> =A0=A0=A04. =A0Don't allow bearer tokens without either SSL and/or sign= atures.<br> =A0=A0=A0=A0=A0=A0=A0While some providers may offer this ability, they shou= ld be out<br> =A0=A0=A0=A0=A0=A0=A0of spec for doing so though technically it won't b= reak the flows.<br> <br> While I personally think that requiring SSL is a fantastic idea, and it=92s= very hard for me to argue against it, however....<br> <br> One of the goals for WRAP was to define a standard AuthZ interface for APIs= which matched what we currently have on the Web. WRAP protected APIs are i= ntended to be a replacement for screen scraping.<br> <br> On the web, almost all websites implement Cookie Auth. Specifically, when y= ou log into a website, the browser is issued a bearer token, called a Cooki= e, and the browser is able to access Protected Resources by using the Cooki= e as the credential. <br> <br> The WRAP access token is intended to be a direct replacement for the HTTP C= ookie. A client should be able to present its bearer token (a WRAP Access T= oken or an HTTP Cookie) without having to sign the request.<br> <br> While I certainly think that requiring SSL would be a huge improvement in i= nternet security, HTTP does not require SSL, and since WRAP was intended to= be a replacement for HTTP Cookie Auth, then OAuth2 should also not require= HTTPS.<br> <br> Yes, dropping the SSL requirement isn=92t optimal, but again the intent wit= h WRAP was to replace HTTP Cookie auth, and it should be up to the service = provider to require HTTPS when applicable. <br></span></font></div></blockq= uote> <div><br></div><div>I tend to agree that this is a SHOULD and not a MUST. T= here is a wide range of types of protected resources, and many of these res= ources are already available over HTTP connections. It probably should be a= choice by the authorization endpoint whether to allow non-HTTPS access.</d= iv> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"><div><font face=3D"Calibri, V= erdana, Helvetica, Arial"><span style=3D"font-size:11pt"> <br> Allen<br> </span></font> </div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br> --0016362849bef7dba4048395cfa3-- From torsten@lodderstedt.net Tue Apr 6 11:50:08 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B413A6A00 for <oauth@core3.amsl.com>; Tue, 6 Apr 2010 11:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnXHA5trtny6 for <oauth@core3.amsl.com>; Tue, 6 Apr 2010 11:50:03 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id 20A483A6A10 for <oauth@ietf.org>; Tue, 6 Apr 2010 11:49:00 -0700 (PDT) Received: from p4fff04d5.dip.t-dialin.net ([79.255.4.213] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1NzDpY-0001ae-AP; Tue, 06 Apr 2010 20:48:56 +0200 Message-ID: <4BBB8214.6060100@lodderstedt.net> Date: Tue, 06 Apr 2010 20:48:52 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Allen Tom <atom@yahoo-inc.com> References: <C7E0CAEF.29FA4%atom@yahoo-inc.com> In-Reply-To: <C7E0CAEF.29FA4%atom@yahoo-inc.com> Content-Type: multipart/alternative; boundary="------------040804020301010803040400" X-Df-Sender: 141509 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 06 Apr 2010 18:50:08 -0000 This is a multi-part message in MIME format. --------------040804020301010803040400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 for the standard should recommand HTTPS or comparable means of transport protection but not require it. This requirement does not result in any benefit for the specification by itself (e.g. simplification). Therefore, the decision to use HTTPS or any other means should be up to the service providers based on its security considerations. > One of the biggest differences between OAuth2 and WRAP is that OAuth2 > requires that Protected Resources be accessed using HTTPS if no > signature is being used. Bullet Point #2 in Section 1.2 says: > > 4. Don't allow bearer tokens without either SSL and/or signatures. > While some providers may offer this ability, they should be out > of spec for doing so though technically it won't break the flows. > > While I personally think that requiring SSL is a fantastic idea, and > it's very hard for me to argue against it, however.... > > One of the goals for WRAP was to define a standard AuthZ interface for > APIs which matched what we currently have on the Web. WRAP protected > APIs are intended to be a replacement for screen scraping. > > On the web, almost all websites implement Cookie Auth. Specifically, > when you log into a website, the browser is issued a bearer token, > called a Cookie, and the browser is able to access Protected Resources > by using the Cookie as the credential. > > The WRAP access token is intended to be a direct replacement for the > HTTP Cookie. A client should be able to present its bearer token (a > WRAP Access Token or an HTTP Cookie) without having to sign the request. > > While I certainly think that requiring SSL would be a huge improvement > in internet security, HTTP does not require SSL, and since WRAP was > intended to be a replacement for HTTP Cookie Auth, then OAuth2 should > also not require HTTPS. > > Yes, dropping the SSL requirement isn't optimal, but again the intent > with WRAP was to replace HTTP Cookie auth, and it should be up to the > service provider to require HTTPS when applicable. > > Allen > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------040804020301010803040400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> +1  for the standard should recommand HTTPS or comparable means of transport protection but not require it. <br> <br> This requirement does not result in any benefit for the specification by itself (e.g. simplification). Therefore, the decision to use HTTPS or any other means should be up to the service providers based on its security considerations.  <br> <blockquote cite="mid:C7E0CAEF.29FA4%25atom@yahoo-inc.com" type="cite"> <title>HTTPS requirement for using an Access Token without signatures One of the biggest differences between OAuth2 and WRAP is that OAuth2 requires that Protected Resources be accessed using HTTPS if no signature is being used. Bullet Point #2 in Section 1.2 says:

   4.  Don't allow bearer tokens without either SSL and/or signatures.
       While some providers may offer this ability, they should be out
       of spec for doing so though technically it won't break the flows.

While I personally think that requiring SSL is a fantastic idea, and it’s very hard for me to argue against it, however....

One of the goals for WRAP was to define a standard AuthZ interface for APIs which matched what we currently have on the Web. WRAP protected APIs are intended to be a replacement for screen scraping.

On the web, almost all websites implement Cookie Auth. Specifically, when you log into a website, the browser is issued a bearer token, called a Cookie, and the browser is able to access Protected Resources by using the Cookie as the credential.

The WRAP access token is intended to be a direct replacement for the HTTP Cookie. A client should be able to present its bearer token (a WRAP Access Token or an HTTP Cookie) without having to sign the request.

While I certainly think that requiring SSL would be a huge improvement in internet security, HTTP does not require SSL, and since WRAP was intended to be a replacement for HTTP Cookie Auth, then OAuth2 should also not require HTTPS.

Yes, dropping the SSL requirement isn’t optimal, but again the intent with WRAP was to replace HTTP Cookie auth, and it should be up to the service provider to require HTTPS when applicable.

Allen
 

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

--------------040804020301010803040400-- From raffi@twitter.com Tue Apr 6 11:52:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D14B3A6A1D for ; Tue, 6 Apr 2010 11:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH5TvLDD--VE for ; Tue, 6 Apr 2010 11:52:48 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 2E7763A694D for ; Tue, 6 Apr 2010 11:52:03 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so69367qwb.31 for ; Tue, 06 Apr 2010 11:51:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.3 with HTTP; Tue, 6 Apr 2010 11:51:38 -0700 (PDT) In-Reply-To: <4BBB8214.6060100@lodderstedt.net> References: <4BBB8214.6060100@lodderstedt.net> From: Raffi Krikorian Date: Tue, 6 Apr 2010 11:51:38 -0700 Received: by 10.229.215.72 with SMTP id hd8mr699800qcb.43.1270579918668; Tue, 06 Apr 2010 11:51:58 -0700 (PDT) Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001636310205b60466048395f02e Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:52:50 -0000 --001636310205b60466048395f02e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable even though i was one who advocated for HTTPS for these tokens, i think i agree it should be a SHOULD and not a MUST. over the public internet, twitter would require HTTPS, but inside our data center we would probably just allow HTTP. On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > +1 for the standard should recommand HTTPS or comparable means of > transport protection but not require it. > > This requirement does not result in any benefit for the specification by > itself (e.g. simplification). Therefore, the decision to use HTTPS or any > other means should be up to the service providers based on its security > considerations. > > One of the biggest differences between OAuth2 and WRAP is that OAuth2 > requires that Protected Resources be accessed using HTTPS if no signature= is > being used. Bullet Point #2 in Section 1.2 says: > > 4. Don't allow bearer tokens without either SSL and/or signatures. > While some providers may offer this ability, they should be out > of spec for doing so though technically it won't break the flows. > > While I personally think that requiring SSL is a fantastic idea, and it= =92s > very hard for me to argue against it, however.... > > One of the goals for WRAP was to define a standard AuthZ interface for AP= Is > which matched what we currently have on the Web. WRAP protected APIs are > intended to be a replacement for screen scraping. > > On the web, almost all websites implement Cookie Auth. Specifically, when > you log into a website, the browser is issued a bearer token, called a > Cookie, and the browser is able to access Protected Resources by using th= e > Cookie as the credential. > > The WRAP access token is intended to be a direct replacement for the HTTP > Cookie. A client should be able to present its bearer token (a WRAP Acces= s > Token or an HTTP Cookie) without having to sign the request. > > While I certainly think that requiring SSL would be a huge improvement in > internet security, HTTP does not require SSL, and since WRAP was intended= to > be a replacement for HTTP Cookie Auth, then OAuth2 should also not requir= e > HTTPS. > > Yes, dropping the SSL requirement isn=92t optimal, but again the intent w= ith > WRAP was to replace HTTP Cookie auth, and it should be up to the service > provider to require HTTPS when applicable. > > Allen > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Raffi Krikorian Twitter Platform Team http://twitter.com/raffi --001636310205b60466048395f02e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable even though i was one who advocated for HTTPS for these tokens, i think i a= gree it should be a SHOULD and not a MUST. =A0over the public internet, twi= tter would require HTTPS, but inside our data center we would probably just= allow HTTP.

On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lod= derstedt <t= orsten@lodderstedt.net> wrote:
=20
+1=A0 for the standard should recommand HTTPS or comparable means of transport protection but not require it.

This requirement does not result in any benefit for the specification by itself (e.g. simplification). Therefore, the decision to use HTTPS or any other means should be up to the service providers based on its security considerations.=A0
=20 One of the biggest differences between OAuth2 and WRAP is that OAuth2 requires that Protected Resources be accessed using HTTPS if no signature is being used. Bullet Point #2 in Section 1.2 says:

=A0=A0=A04. =A0Don't allow bearer tokens without either SSL and/or sign= atures.
=A0=A0=A0=A0=A0=A0=A0While some providers may offer this ability, they shou= ld be out
=A0=A0=A0=A0=A0=A0=A0of spec for doing so though technically it won't b= reak the flows.

While I personally think that requiring SSL is a fantastic idea, and it=92s very hard for me to argue against it, however....

One of the goals for WRAP was to define a standard AuthZ interface for APIs which matched what we currently have on the Web. WRAP protected APIs are intended to be a replacement for screen scraping.

On the web, almost all websites implement Cookie Auth. Specifically, when you log into a website, the browser is issued a bearer token, called a Cookie, and the browser is able to access Protected Resources by using the Cookie as the credential.

The WRAP access token is intended to be a direct replacement for the HTTP Cookie. A client should be able to present its bearer token (a WRAP Access Token or an HTTP Cookie) without having to sign the request.
While I certainly think that requiring SSL would be a huge improvement in internet security, HTTP does not require SSL, and since WRAP was intended to be a replacement for HTTP Cookie Auth, then OAuth2 should also not require HTTPS.

Yes, dropping the SSL requirement isn=92t optimal, but again the intent with WRAP was to replace HTTP Cookie auth, and it should be up to the service provider to require HTTPS when applicable.

Allen
 

_______________________________________________
OAuth mailing list

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


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




--
Raffi Krikorian
= Twitter Platform Team
http://twitte= r.com/raffi
--001636310205b60466048395f02e-- From jpanzer@google.com Tue Apr 6 11:55:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2553A69B1 for ; Tue, 6 Apr 2010 11:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE6huKzZzjAy for ; Tue, 6 Apr 2010 11:55:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 809CA3A6994 for ; Tue, 6 Apr 2010 11:54:51 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o36IskFI031334 for ; Tue, 6 Apr 2010 20:54:46 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270580087; bh=DP75lFVKXDxmFOH7pa+uLFrGWvQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=HD/pxfnjbEHDiBKMYBdrQzlS6nFkNo5NaC7KnWWOFYehUx7p72egAGTqo3jWdiyAk bg7RDX7p+X8aCPSac8nng== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=HzTpPnDtL6vLHKX8tflIv0Wfj4ef9D4Hk3ds6TPoQVCZ9ZSL1Vc09cwklIuU3xZcu JZ24Q4G+c+/p7eiK/sXqQ== Received: from pzk36 (pzk36.prod.google.com [10.243.19.164]) by kpbe11.cbf.corp.google.com with ESMTP id o36IsjnV021727 for ; Tue, 6 Apr 2010 13:54:45 -0500 Received: by pzk36 with SMTP id 36so210593pzk.24 for ; Tue, 06 Apr 2010 11:54:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.14 with HTTP; Tue, 6 Apr 2010 11:54:24 -0700 (PDT) In-Reply-To: <4BBB8214.6060100@lodderstedt.net> References: <4BBB8214.6060100@lodderstedt.net> From: John Panzer Date: Tue, 6 Apr 2010 11:54:24 -0700 Received: by 10.141.90.2 with SMTP id s2mr5850780rvl.273.1270580084334; Tue, 06 Apr 2010 11:54:44 -0700 (PDT) Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=000e0cd1196895e07d048395fa9d X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:55:26 -0000 --000e0cd1196895e07d048395fa9d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My $.02: SHOULD is okay, as long as all clients MUST support HTTPS. E.g., SHOULD for service providers, MUST support for clients. Otherwise, you will end up with clients that don't support https or don't d= o it properly. (E.g., don't bother to check certificates.) Which hurts security for service providers that do want SSL. On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > +1 for the standard should recommand HTTPS or comparable means of > transport protection but not require it. > > This requirement does not result in any benefit for the specification by > itself (e.g. simplification). Therefore, the decision to use HTTPS or any > other means should be up to the service providers based on its security > considerations. > > One of the biggest differences between OAuth2 and WRAP is that OAuth2 > requires that Protected Resources be accessed using HTTPS if no signature= is > being used. Bullet Point #2 in Section 1.2 says: > > 4. Don't allow bearer tokens without either SSL and/or signatures. > While some providers may offer this ability, they should be out > of spec for doing so though technically it won't break the flows. > > While I personally think that requiring SSL is a fantastic idea, and it= =92s > very hard for me to argue against it, however.... > > One of the goals for WRAP was to define a standard AuthZ interface for AP= Is > which matched what we currently have on the Web. WRAP protected APIs are > intended to be a replacement for screen scraping. > > On the web, almost all websites implement Cookie Auth. Specifically, when > you log into a website, the browser is issued a bearer token, called a > Cookie, and the browser is able to access Protected Resources by using th= e > Cookie as the credential. > > The WRAP access token is intended to be a direct replacement for the HTTP > Cookie. A client should be able to present its bearer token (a WRAP Acces= s > Token or an HTTP Cookie) without having to sign the request. > > While I certainly think that requiring SSL would be a huge improvement in > internet security, HTTP does not require SSL, and since WRAP was intended= to > be a replacement for HTTP Cookie Auth, then OAuth2 should also not requir= e > HTTPS. > > Yes, dropping the SSL requirement isn=92t optimal, but again the intent w= ith > WRAP was to replace HTTP Cookie auth, and it should be up to the service > provider to require HTTPS when applicable. > > Allen > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000e0cd1196895e07d048395fa9d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My $.02: =A0SHOULD is okay, as long as all clients MUST support HTTPS. =A0E= .g., SHOULD for service providers, MUST support for clients.

=
Otherwise, you will end up with clients that don't support https o= r don't do it properly. =A0(E.g., don't bother to check certificate= s.) =A0Which hurts security for service providers that do want SSL.

On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lod= derstedt <t= orsten@lodderstedt.net> wrote:
=20
+1=A0 for the standard should recommand HTTPS or comparable means of transport protection but not require it.

This requirement does not result in any benefit for the specification by itself (e.g. simplification). Therefore, the decision to use HTTPS or any other means should be up to the service providers based on its security considerations.=A0
=20 One of the biggest differences between OAuth2 and WRAP is that OAuth2 requires that Protected Resources be accessed using HTTPS if no signature is being used. Bullet Point #2 in Section 1.2 says:

=A0=A0=A04. =A0Don't allow bearer tokens without either SSL and/or sign= atures.
=A0=A0=A0=A0=A0=A0=A0While some providers may offer this ability, they shou= ld be out
=A0=A0=A0=A0=A0=A0=A0of spec for doing so though technically it won't b= reak the flows.

While I personally think that requiring SSL is a fantastic idea, and it=92s very hard for me to argue against it, however....

One of the goals for WRAP was to define a standard AuthZ interface for APIs which matched what we currently have on the Web. WRAP protected APIs are intended to be a replacement for screen scraping.

On the web, almost all websites implement Cookie Auth. Specifically, when you log into a website, the browser is issued a bearer token, called a Cookie, and the browser is able to access Protected Resources by using the Cookie as the credential.

The WRAP access token is intended to be a direct replacement for the HTTP Cookie. A client should be able to present its bearer token (a WRAP Access Token or an HTTP Cookie) without having to sign the request.
While I certainly think that requiring SSL would be a huge improvement in internet security, HTTP does not require SSL, and since WRAP was intended to be a replacement for HTTP Cookie Auth, then OAuth2 should also not require HTTPS.

Yes, dropping the SSL requirement isn=92t optimal, but again the intent with WRAP was to replace HTTP Cookie auth, and it should be up to the service provider to require HTTPS when applicable.

Allen
 

_______________________________________________
OAuth mailing list

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


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


--000e0cd1196895e07d048395fa9d-- From romeda@gmail.com Tue Apr 6 12:07:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897B53A6803 for ; Tue, 6 Apr 2010 12:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EZuimTU5f2v for ; Tue, 6 Apr 2010 12:07:17 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 67EDF3A6B10 for ; Tue, 6 Apr 2010 12:05:14 -0700 (PDT) Received: by ewy24 with SMTP id 24so129434ewy.13 for ; Tue, 06 Apr 2010 12:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:content-type :content-transfer-encoding; bh=o10TpSgMSq8EoxhbhWE4G1C1FjPESf4fWTP9dqrYi+I=; b=YGM4XYs/HGY41h/Q04VQP2kp3CoTb+tk9PpMDLDSRS1fQdgAJxEj4EMPxojj0a8GLx zVfdsdj9iEsyZW5NUS1Zdj1o29Gw2KfPnZzyd7E35qaaSXQJtTnZkicNhCTQJ62oH1XT jX1/VU25CXRkGmYObpKRTTDmeNPUle+8X7P3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=WB9sR/3neR+QiyhmBFZkOofBzKsMzy+gotoTjXzyb4uNr6YGbxr33BodKgp5LJV/Q5 UYlXYoWaT0jOoXSg9xI2CwmZoitw6dpovQZAnyQ40PwnwscKEWJcyuk+Mek9So1Ag6W1 vDyJW2ZPzRwB0qk08FdfOLALjjqvDwsMyR740= MIME-Version: 1.0 Received: by 10.213.19.19 with HTTP; Tue, 6 Apr 2010 12:04:44 -0700 (PDT) In-Reply-To: References: <4BBB8214.6060100@lodderstedt.net> From: Blaine Cook Date: Tue, 6 Apr 2010 12:04:44 -0700 Received: by 10.213.44.73 with SMTP id z9mr1086470ebe.2.1270580705873; Tue, 06 Apr 2010 12:05:05 -0700 (PDT) Message-ID: To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 19:07:18 -0000 My take on this is that MUSTs MAY be ignored. ;-) To echo John's concerns here, the worst-case scenario is that client libraries implement "no SSL present" as a gentle reminder warning with a flag (possibly the default) to disable those HTTPS warnings. Clients that behave in that way should be flagged as non-compliant and publicly humiliated. If we just write SHOULD for HTTPS/secure channel support, then those clients are acting "properly." If WRAP is aiming to just be a replacement for Cookie auth, then why don't we just add a redirection profile for issuing cookies? They work now, refreshing them is built-in, etc, etc. Instead, what we're trying to do is build something better, more secure, and more aligned with the sorts of behaviours we see and want to encourage on the web. b. On 6 April 2010 11:54, John Panzer wrote: > My $.02: =C2=A0SHOULD is okay, as long as all clients MUST support HTTPS.= =C2=A0E.g., > SHOULD for service providers, MUST support for clients. > Otherwise, you will end up with clients that don't support https or don't= do > it properly. =C2=A0(E.g., don't bother to check certificates.) =C2=A0Whic= h hurts > security for service providers that do want SSL. > > On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt > wrote: >> >> +1=C2=A0 for the standard should recommand HTTPS or comparable means of >> transport protection but not require it. >> >> This requirement does not result in any benefit for the specification by >> itself (e.g. simplification). Therefore, the decision to use HTTPS or an= y >> other means should be up to the service providers based on its security >> considerations. >> >> One of the biggest differences between OAuth2 and WRAP is that OAuth2 >> requires that Protected Resources be accessed using HTTPS if no signatur= e is >> being used. Bullet Point #2 in Section 1.2 says: >> >> =C2=A0=C2=A0=C2=A04. =C2=A0Don't allow bearer tokens without either SSL = and/or signatures. >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0While some providers may offer= this ability, they should be out >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0of spec for doing so though te= chnically it won't break the flows. >> >> While I personally think that requiring SSL is a fantastic idea, and it= =E2=80=99s >> very hard for me to argue against it, however.... >> >> One of the goals for WRAP was to define a standard AuthZ interface for >> APIs which matched what we currently have on the Web. WRAP protected API= s >> are intended to be a replacement for screen scraping. >> >> On the web, almost all websites implement Cookie Auth. Specifically, whe= n >> you log into a website, the browser is issued a bearer token, called a >> Cookie, and the browser is able to access Protected Resources by using t= he >> Cookie as the credential. >> >> The WRAP access token is intended to be a direct replacement for the HTT= P >> Cookie. A client should be able to present its bearer token (a WRAP Acce= ss >> Token or an HTTP Cookie) without having to sign the request. >> >> While I certainly think that requiring SSL would be a huge improvement i= n >> internet security, HTTP does not require SSL, and since WRAP was intende= d to >> be a replacement for HTTP Cookie Auth, then OAuth2 should also not requi= re >> HTTPS. >> >> Yes, dropping the SSL requirement isn=E2=80=99t optimal, but again the i= ntent with >> WRAP was to replace HTTP Cookie auth, and it should be up to the service >> provider to require HTTPS when applicable. >> >> Allen >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From torsten@lodderstedt.net Tue Apr 6 12:39:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E5D3A693E for ; Tue, 6 Apr 2010 12:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riASDHl5X4Ag for ; Tue, 6 Apr 2010 12:39:37 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id 4FCCB3A691F for ; Tue, 6 Apr 2010 12:39:34 -0700 (PDT) Received: from p4fff04d5.dip.t-dialin.net ([79.255.4.213] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1NzEcV-0006UU-LK; Tue, 06 Apr 2010 21:39:31 +0200 Message-ID: <4BBB8DE8.8080803@lodderstedt.net> Date: Tue, 06 Apr 2010 21:39:20 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Blaine Cook References: <4BBB8214.6060100@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 19:39:38 -0000 Hi Blaine, > My take on this is that MUSTs MAY be ignored. ;-) > > To echo John's concerns here, the worst-case scenario is that client > libraries implement "no SSL present" as a gentle reminder warning with > a flag (possibly the default) to disable those HTTPS warnings. Clients > I don't understand your objections. If a resource provider decides to support HTTPS only, no client w/o HTTPS support can connect thus circumventing this policy. > that behave in that way should be flagged as non-compliant and > publicly humiliated. agreed :-) > If we just write SHOULD for HTTPS/secure channel > support, then those clients are acting "properly." > Why not explicitly state in the spec that HTTPS support is a MUST HAVE for libraries? > If WRAP is aiming to just be a replacement for Cookie auth, then why > don't we just add a redirection profile for issuing cookies? They work > now, refreshing them is built-in, etc, etc. Instead, what we're trying > to do is build something better, more secure, and more aligned with > the sorts of behaviours we see and want to encourage on the web. > There are a variety of deployment scenarios for OAuth2 (e.g. internet small/large, intranet) as well as replay countermeasures (encryption, short-living tokens, restricted permissions, ...). Can we really anticipate/consider all of them and select HTTPS as the only solution? Even the spec for BASIC-Authentication (http://www.ietf.org/rfc/rfc2617.txt) does not force a certain mean of transport protection. It just recommends to consider security enhancements: ---- from http://www.ietf.org/rfc/rfc2617.txt The Basic authentication scheme is not a secure method of user authentication, nor does it in any way protect the entity, which is transmitted in cleartext across the physical network used as the carrier. HTTP does not prevent additional authentication schemes and encryption mechanisms from being employed to increase security or the addition of enhancements (such as schemes to use one-time passwords) to Basic authentication. The most serious flaw in Basic authentication is that it results in the essentially cleartext transmission of the user's password over the physical network. It is this problem which Digest Authentication attempts to address. Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used (without enhancements) to protect sensitive or valuable information. ---- HTTPS is state of the art and should from in my opinion be the _recommended_ option. This leaves implementors enough freedom to use other security measures where neccessary/sufficient/applicable. regards, Torsten. > b. > > On 6 April 2010 11:54, John Panzer wrote: > >> My $.02: SHOULD is okay, as long as all clients MUST support HTTPS. E.g., >> SHOULD for service providers, MUST support for clients. >> Otherwise, you will end up with clients that don't support https or don't do >> it properly. (E.g., don't bother to check certificates.) Which hurts >> security for service providers that do want SSL. >> >> On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt >> wrote: >> >>> +1 for the standard should recommand HTTPS or comparable means of >>> transport protection but not require it. >>> >>> This requirement does not result in any benefit for the specification by >>> itself (e.g. simplification). Therefore, the decision to use HTTPS or any >>> other means should be up to the service providers based on its security >>> considerations. >>> >>> One of the biggest differences between OAuth2 and WRAP is that OAuth2 >>> requires that Protected Resources be accessed using HTTPS if no signature is >>> being used. Bullet Point #2 in Section 1.2 says: >>> >>> 4. Don't allow bearer tokens without either SSL and/or signatures. >>> While some providers may offer this ability, they should be out >>> of spec for doing so though technically it won't break the flows. >>> >>> While I personally think that requiring SSL is a fantastic idea, and it’s >>> very hard for me to argue against it, however.... >>> >>> One of the goals for WRAP was to define a standard AuthZ interface for >>> APIs which matched what we currently have on the Web. WRAP protected APIs >>> are intended to be a replacement for screen scraping. >>> >>> On the web, almost all websites implement Cookie Auth. Specifically, when >>> you log into a website, the browser is issued a bearer token, called a >>> Cookie, and the browser is able to access Protected Resources by using the >>> Cookie as the credential. >>> >>> The WRAP access token is intended to be a direct replacement for the HTTP >>> Cookie. A client should be able to present its bearer token (a WRAP Access >>> Token or an HTTP Cookie) without having to sign the request. >>> >>> While I certainly think that requiring SSL would be a huge improvement in >>> internet security, HTTP does not require SSL, and since WRAP was intended to >>> be a replacement for HTTP Cookie Auth, then OAuth2 should also not require >>> HTTPS. >>> >>> Yes, dropping the SSL requirement isn’t optimal, but again the intent with >>> WRAP was to replace HTTP Cookie auth, and it should be up to the service >>> provider to require HTTPS when applicable. >>> >>> Allen >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From tonynad@microsoft.com Tue Apr 6 12:50:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFC03A6994 for ; Tue, 6 Apr 2010 12:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs5d0ZZJeIdM for ; Tue, 6 Apr 2010 12:50:32 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 149053A6953 for ; Tue, 6 Apr 2010 12:50:32 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 6 Apr 2010 12:50:30 -0700 Received: from TK5EX14MBXC103.redmond.corp.microsoft.com ([169.254.3.164]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Tue, 6 Apr 2010 12:50:29 -0700 From: Anthony Nadalin To: Allen Tom , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures Thread-Index: AcrVtrKPc2+a+5PkjUWcdom/sx3EFAAC1/Xg Date: Tue, 6 Apr 2010 19:50:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A08279DC79B11C48AD587060CD93977125EF96D7TK5EX14MBXC103r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 19:50:37 -0000 --_000_A08279DC79B11C48AD587060CD93977125EF96D7TK5EX14MBXC103r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure if you are coming from the user or service perspective. So if = a user asks for HTTPS do you have to support HTTPS? If a service asks for H= TTPS do you have to support it? Or do you just fail? From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= llen Tom Sent: Tuesday, April 06, 2010 11:27 AM To: oauth@ietf.org Subject: [OAUTH-WG] HTTPS requirement for using an Access Token without sig= natures One of the biggest differences between OAuth2 and WRAP is that OAuth2 requi= res that Protected Resources be accessed using HTTPS if no signature is bei= ng used. Bullet Point #2 in Section 1.2 says: 4. Don't allow bearer tokens without either SSL and/or signatures. While some providers may offer this ability, they should be out of spec for doing so though technically it won't break the flows. While I personally think that requiring SSL is a fantastic idea, and it's v= ery hard for me to argue against it, however.... One of the goals for WRAP was to define a standard AuthZ interface for APIs= which matched what we currently have on the Web. WRAP protected APIs are i= ntended to be a replacement for screen scraping. On the web, almost all websites implement Cookie Auth. Specifically, when y= ou log into a website, the browser is issued a bearer token, called a Cooki= e, and the browser is able to access Protected Resources by using the Cooki= e as the credential. The WRAP access token is intended to be a direct replacement for the HTTP C= ookie. A client should be able to present its bearer token (a WRAP Access T= oken or an HTTP Cookie) without having to sign the request. While I certainly think that requiring SSL would be a huge improvement in i= nternet security, HTTP does not require SSL, and since WRAP was intended to= be a replacement for HTTP Cookie Auth, then OAuth2 should also not require= HTTPS. Yes, dropping the SSL requirement isn't optimal, but again the intent with = WRAP was to replace HTTP Cookie auth, and it should be up to the service pr= ovider to require HTTPS when applicable. Allen --_000_A08279DC79B11C48AD587060CD93977125EF96D7TK5EX14MBXC103r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HTTPS requirement for using an Access= Token without signatures

I’m= not sure if you are coming from the user or service perspective. So if a u= ser asks for HTTPS do you have to support HTTPS? If a service asks for HTTP= S do you have to support it? Or  do you just fail?

 

<= p class=3DMsoNormal>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.o= rg] On Behalf Of Allen Tom
Sent: Tuesday, April 06, 2010 1= 1:27 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] HTTPS re= quirement for using an Access Token without signatures

 

One of= the biggest differences between OAuth2 and WRAP is that OAuth2 requires th= at Protected Resources be accessed using HTTPS if no signature is being use= d. Bullet Point #2 in Section 1.2 says:

   4.  D= on't allow bearer tokens without either SSL and/or signatures.
 &nb= sp;     While some providers may offer this abilit= y, they should be out
       of spec = for doing so though technically it won't break the flows.

While I pe= rsonally think that requiring SSL is a fantastic idea, and it’s very = hard for me to argue against it, however....

One of the goals for WR= AP was to define a standard AuthZ interface for APIs which matched what we = currently have on the Web. WRAP protected APIs are intended to be a replace= ment for screen scraping.

On the web, almost all websites implement = Cookie Auth. Specifically, when you log into a website, the browser is issu= ed a bearer token, called a Cookie, and the browser is able to access Prote= cted Resources by using the Cookie as the credential.

The WRAP acce= ss token is intended to be a direct replacement for the HTTP Cookie. A clie= nt should be able to present its bearer token (a WRAP Access Token or an HT= TP Cookie) without having to sign the request.

While I certainly thi= nk that requiring SSL would be a huge improvement in internet security, HTT= P does not require SSL, and since WRAP was intended to be a replacement for= HTTP Cookie Auth, then OAuth2 should also not require HTTPS.

Yes, d= ropping the SSL requirement isn’t optimal, but again the intent with = WRAP was to replace HTTP Cookie auth, and it should be up to the service pr= ovider to require HTTPS when applicable.

Allen

= --_000_A08279DC79B11C48AD587060CD93977125EF96D7TK5EX14MBXC103r_-- From igor.faynberg@alcatel-lucent.com Tue Apr 6 12:58:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B7428C0D6 for ; Tue, 6 Apr 2010 12:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVlQCZa1UU4F for ; Tue, 6 Apr 2010 12:58:51 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 5BA503A68ED for ; Tue, 6 Apr 2010 12:58:48 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o36JwfKR028887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 14:58:41 -0500 (CDT) Received: from [135.244.36.125] (faynberg.lra.lucent.com [135.244.36.125]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o36Jwes6007372; Tue, 6 Apr 2010 14:58:40 -0500 (CDT) Message-ID: <4BBB926B.4090508@alcatel-lucent.com> Date: Tue, 06 Apr 2010 15:58:35 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt References: <4BBB8214.6060100@lodderstedt.net> <4BBB8DE8.8080803@lodderstedt.net> In-Reply-To: <4BBB8DE8.8080803@lodderstedt.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 19:58:53 -0000 ++ Igor Torsten Lodderstedt wrote: > Hi Blaine, >> My take on this is that MUSTs MAY be ignored. ;-) >> >> To echo John's concerns here, the worst-case scenario is that client >> libraries implement "no SSL present" as a gentle reminder warning with >> a flag (possibly the default) to disable those HTTPS warnings. Clients >> > I don't understand your objections. If a resource provider decides to > support HTTPS only, no client w/o HTTPS support can connect thus > circumventing this policy. >> that behave in that way should be flagged as non-compliant and >> publicly humiliated. > agreed :-) >> If we just write SHOULD for HTTPS/secure channel >> support, then those clients are acting "properly." >> > Why not explicitly state in the spec that HTTPS support is a MUST HAVE > for libraries? >> If WRAP is aiming to just be a replacement for Cookie auth, then why >> don't we just add a redirection profile for issuing cookies? They work >> now, refreshing them is built-in, etc, etc. Instead, what we're trying >> to do is build something better, more secure, and more aligned with >> the sorts of behaviours we see and want to encourage on the web. >> > There are a variety of deployment scenarios for OAuth2 (e.g. internet > small/large, intranet) as well as replay countermeasures (encryption, > short-living tokens, restricted permissions, ...). Can we really > anticipate/consider all of them and select HTTPS as the only solution? > Even the spec for BASIC-Authentication > (http://www.ietf.org/rfc/rfc2617.txt) does not force a certain mean of > transport protection. It just recommends to consider security > enhancements: > > ---- from http://www.ietf.org/rfc/rfc2617.txt > > The Basic authentication scheme is not a secure method of user > authentication, nor does it in any way protect the entity, which is > transmitted in cleartext across the physical network used as the > carrier. HTTP does not prevent additional authentication schemes and > encryption mechanisms from being employed to increase security or the > addition of enhancements (such as schemes to use one-time passwords) > to Basic authentication. > > The most serious flaw in Basic authentication is that it results in > the essentially cleartext transmission of the user's password over > the physical network. It is this problem which Digest Authentication > attempts to address. > > Because Basic authentication involves the cleartext transmission of > passwords it SHOULD NOT be used (without enhancements) to protect > sensitive or valuable information. > > ---- > HTTPS is state of the art and should from in my opinion be the > _recommended_ option. This leaves implementors enough freedom to use > other security measures where neccessary/sufficient/applicable. > > regards, > Torsten. >> b. >> >> On 6 April 2010 11:54, John Panzer wrote: >> >>> My $.02: SHOULD is okay, as long as all clients MUST support >>> HTTPS. E.g., >>> SHOULD for service providers, MUST support for clients. >>> Otherwise, you will end up with clients that don't support https or >>> don't do >>> it properly. (E.g., don't bother to check certificates.) Which hurts >>> security for service providers that do want SSL. >>> >>> On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt >>> wrote: >>> >>>> +1 for the standard should recommand HTTPS or comparable means of >>>> transport protection but not require it. >>>> >>>> This requirement does not result in any benefit for the >>>> specification by >>>> itself (e.g. simplification). Therefore, the decision to use HTTPS >>>> or any >>>> other means should be up to the service providers based on its >>>> security >>>> considerations. >>>> >>>> One of the biggest differences between OAuth2 and WRAP is that OAuth2 >>>> requires that Protected Resources be accessed using HTTPS if no >>>> signature is >>>> being used. Bullet Point #2 in Section 1.2 says: >>>> >>>> 4. Don't allow bearer tokens without either SSL and/or >>>> signatures. >>>> While some providers may offer this ability, they should be >>>> out >>>> of spec for doing so though technically it won't break the >>>> flows. >>>> >>>> While I personally think that requiring SSL is a fantastic idea, >>>> and it’s >>>> very hard for me to argue against it, however.... >>>> >>>> One of the goals for WRAP was to define a standard AuthZ interface for >>>> APIs which matched what we currently have on the Web. WRAP >>>> protected APIs >>>> are intended to be a replacement for screen scraping. >>>> >>>> On the web, almost all websites implement Cookie Auth. >>>> Specifically, when >>>> you log into a website, the browser is issued a bearer token, called a >>>> Cookie, and the browser is able to access Protected Resources by >>>> using the >>>> Cookie as the credential. >>>> >>>> The WRAP access token is intended to be a direct replacement for >>>> the HTTP >>>> Cookie. A client should be able to present its bearer token (a WRAP >>>> Access >>>> Token or an HTTP Cookie) without having to sign the request. >>>> >>>> While I certainly think that requiring SSL would be a huge >>>> improvement in >>>> internet security, HTTP does not require SSL, and since WRAP was >>>> intended to >>>> be a replacement for HTTP Cookie Auth, then OAuth2 should also not >>>> require >>>> HTTPS. >>>> >>>> Yes, dropping the SSL requirement isn’t optimal, but again the >>>> intent with >>>> WRAP was to replace HTTP Cookie auth, and it should be up to the >>>> service >>>> provider to require HTTPS when applicable. >>>> >>>> Allen >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Tue Apr 6 13:30:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8608F3A67EF for ; Tue, 6 Apr 2010 13:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thKDMoyZzSrc for ; Tue, 6 Apr 2010 13:30:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D39EA3A6A58 for ; Tue, 6 Apr 2010 13:27:12 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [10.3.21.5]) by smtp-out.google.com with ESMTP id o36KR8aM016053 for ; Tue, 6 Apr 2010 22:27:09 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270585629; bh=BJgEpIF3+9si7/RxJ051+E0ykUU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tN3y2Txit+i9IK5/+5mtwK8Gh/REyxJJCH0ichYHsfZUGFVj3ziOKk/ej/tVM7osH sOMa8eU+2igLBFlkzrghQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=eGdVp078I4ZphDrDut0Yip4ATyYHjfRyRHenSwjkmkTFzVLdBdxTgA/4ZdMWFG7II yhx3L/w5UfwXL7iSvg9rQ== Received: from pzk34 (pzk34.prod.google.com [10.243.19.162]) by hpaq5.eem.corp.google.com with ESMTP id o36KR6KV020240 for ; Tue, 6 Apr 2010 22:27:07 +0200 Received: by pzk34 with SMTP id 34so327963pzk.20 for ; Tue, 06 Apr 2010 13:27:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.14 with HTTP; Tue, 6 Apr 2010 13:26:46 -0700 (PDT) In-Reply-To: <4BBB8DE8.8080803@lodderstedt.net> References: <4BBB8214.6060100@lodderstedt.net> <4BBB8DE8.8080803@lodderstedt.net> From: John Panzer Date: Tue, 6 Apr 2010 13:26:46 -0700 Received: by 10.141.5.9 with SMTP id h9mr6073828rvi.12.1270585626155; Tue, 06 Apr 2010 13:27:06 -0700 (PDT) Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=000e0cd0eb46e75a0004839744eb X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 20:30:23 -0000 --000e0cd0eb46e75a0004839744eb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Apr 6, 2010 at 12:39 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Blaine, > > My take on this is that MUSTs MAY be ignored. ;-) >> >> To echo John's concerns here, the worst-case scenario is that client >> libraries implement "no SSL present" as a gentle reminder warning with >> a flag (possibly the default) to disable those HTTPS warnings. Clients >> >> > I don't understand your objections. If a resource provider decides to > support HTTPS only, no client w/o HTTPS support can connect thus > circumventing this policy. It is possible to 'support' HTTPS but not check certificates. Would that b= e acceptable to servers supporting HTTPS only? (No.) > > that behave in that way should be flagged as non-compliant and >> publicly humiliated. >> > agreed :-) > > If we just write SHOULD for HTTPS/secure channel >> support, then those clients are acting "properly." >> >> > Why not explicitly state in the spec that HTTPS support is a MUST HAVE fo= r > libraries? This would also mirror the existing de facto situation for web browsers, al= l of which support HTTPS on demand. > > If WRAP is aiming to just be a replacement for Cookie auth, then why >> don't we just add a redirection profile for issuing cookies? They work >> now, refreshing them is built-in, etc, etc. Instead, what we're trying >> to do is build something better, more secure, and more aligned with >> the sorts of behaviours we see and want to encourage on the web. >> >> > There are a variety of deployment scenarios for OAuth2 (e.g. internet > small/large, intranet) as well as replay countermeasures (encryption, > short-living tokens, restricted permissions, ...). Can we really > anticipate/consider all of them and select HTTPS as the only solution? Ev= en > the spec for BASIC-Authentication (http://www.ietf.org/rfc/rfc2617.txt) > does not force a certain mean of transport protection. It just recommends= to > consider security enhancements: > > ---- from http://www.ietf.org/rfc/rfc2617.txt > > The Basic authentication scheme is not a secure method of user > authentication, nor does it in any way protect the entity, which is > transmitted in cleartext across the physical network used as the > carrier. HTTP does not prevent additional authentication schemes and > encryption mechanisms from being employed to increase security or the > addition of enhancements (such as schemes to use one-time passwords) > to Basic authentication. > > The most serious flaw in Basic authentication is that it results in > the essentially cleartext transmission of the user's password over > the physical network. It is this problem which Digest Authentication > attempts to address. > > Because Basic authentication involves the cleartext transmission of > passwords it SHOULD NOT be used (without enhancements) to protect > sensitive or valuable information. > > ---- > HTTPS is state of the art and should from in my opinion be the > _recommended_ option. This leaves implementors enough freedom to use othe= r > security measures where neccessary/sufficient/applicable. > > regards, > Torsten. > > b. >> >> On 6 April 2010 11:54, John Panzer wrote: >> >> >>> My $.02: SHOULD is okay, as long as all clients MUST support HTTPS. >>> E.g., >>> SHOULD for service providers, MUST support for clients. >>> Otherwise, you will end up with clients that don't support https or don= 't >>> do >>> it properly. (E.g., don't bother to check certificates.) Which hurts >>> security for service providers that do want SSL. >>> >>> On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt >>> wrote: >>> >>> >>>> +1 for the standard should recommand HTTPS or comparable means of >>>> transport protection but not require it. >>>> >>>> This requirement does not result in any benefit for the specification = by >>>> itself (e.g. simplification). Therefore, the decision to use HTTPS or >>>> any >>>> other means should be up to the service providers based on its securit= y >>>> considerations. >>>> >>>> One of the biggest differences between OAuth2 and WRAP is that OAuth2 >>>> requires that Protected Resources be accessed using HTTPS if no >>>> signature is >>>> being used. Bullet Point #2 in Section 1.2 says: >>>> >>>> 4. Don't allow bearer tokens without either SSL and/or signatures. >>>> While some providers may offer this ability, they should be out >>>> of spec for doing so though technically it won't break the flow= s. >>>> >>>> While I personally think that requiring SSL is a fantastic idea, and >>>> it=92s >>>> very hard for me to argue against it, however.... >>>> >>>> One of the goals for WRAP was to define a standard AuthZ interface for >>>> APIs which matched what we currently have on the Web. WRAP protected >>>> APIs >>>> are intended to be a replacement for screen scraping. >>>> >>>> On the web, almost all websites implement Cookie Auth. Specifically, >>>> when >>>> you log into a website, the browser is issued a bearer token, called a >>>> Cookie, and the browser is able to access Protected Resources by using >>>> the >>>> Cookie as the credential. >>>> >>>> The WRAP access token is intended to be a direct replacement for the >>>> HTTP >>>> Cookie. A client should be able to present its bearer token (a WRAP >>>> Access >>>> Token or an HTTP Cookie) without having to sign the request. >>>> >>>> While I certainly think that requiring SSL would be a huge improvement >>>> in >>>> internet security, HTTP does not require SSL, and since WRAP was >>>> intended to >>>> be a replacement for HTTP Cookie Auth, then OAuth2 should also not >>>> require >>>> HTTPS. >>>> >>>> Yes, dropping the SSL requirement isn=92t optimal, but again the inten= t >>>> with >>>> WRAP was to replace HTTP Cookie auth, and it should be up to the servi= ce >>>> provider to require HTTPS when applicable. >>>> >>>> Allen >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd0eb46e75a0004839744eb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Apr 6, 2010 at 12:39 PM, Torsten Lodderstedt <= torsten@lodderstedt.net><= /span> wrote:
Hi Blaine,

My take on this is that MUSTs MAY be ignored. ;-)

To echo John's concerns here, the worst-case scenario is that client libraries implement "no SSL present" as a gentle reminder warning= with
a flag (possibly the default) to disable those HTTPS warnings. Clients
=A0
I don't understand your objections. If a resource provider decides to s= upport HTTPS only, no client w/o HTTPS support can connect thus circumventi= ng this policy.

It is possible to 'supp= ort' HTTPS but not check certificates. =A0Would that be acceptable to s= ervers supporting HTTPS only? =A0(No.)
=A0

that behave in that way should be flagged as non-compliant and
publicly humiliated.
agreed :-)

If we just write SHOULD for HTTPS/secure channel
support, then those clients are acting "properly."
=A0
Why not explicitly state in the spec that HTTPS support is a MUST HAVE for = libraries?

This would also mirror the exist= ing de facto situation for web browsers, all of which support HTTPS on dema= nd.
=A0

If WRAP is aiming to just be a replacement for Cookie auth, then why
don't we just add a redirection profile for issuing cookies? They work<= br> now, refreshing them is built-in, etc, etc. Instead, what we're trying<= br> to do is build something better, more secure, and more aligned with
the sorts of behaviours we see and want to encourage on the web.
=A0
There are a variety of deployment scenarios for OAuth2 (e.g. internet small= /large, intranet) as well as replay countermeasures (encryption, short-livi= ng tokens, restricted permissions, ...). Can we really anticipate/consider = all of them and select HTTPS as the only solution? Even the spec for BASIC-= Authentication (http://www.ietf.org/rfc/rfc2617.txt) does not force a certain me= an of transport protection. It just recommends to consider security enhance= ments:

---- from http://www.ietf.org/rfc/rfc2617.txt

=A0 The Basic authentication scheme is not a secure method of user
=A0 authentication, nor does it in any way protect the entity, which is =A0 transmitted in cleartext across the physical network used as the
=A0 carrier. HTTP does not prevent additional authentication schemes and =A0 encryption mechanisms from being employed to increase security or the<= br> =A0 addition of enhancements (such as schemes to use one-time passwords) =A0 to Basic authentication.

=A0 The most serious flaw in Basic authentication is that it results in =A0 the essentially cleartext transmission of the user's password over=
=A0 the physical network. It is this problem which Digest Authentication =A0 attempts to address.

=A0 Because Basic authentication involves the cleartext transmission of =A0 passwords it SHOULD NOT be used (without enhancements) to protect
=A0 sensitive or valuable information.

----
HTTPS is state of the art and should from in my opinion be the _recommended= _ option. This leaves implementors enough freedom to use other security mea= sures where neccessary/sufficient/applicable.

regards,
Torsten.

b.

On 6 April 2010 11:54, John Panzer<jpanzer@google.com> =A0wrote:
=A0
My $.02: =A0SHOULD is okay, as long as all clients MUST support HTTPS. =A0E= .g.,
SHOULD for service providers, MUST support for clients.
Otherwise, you will end up with clients that don't support https or don= 't do
it properly. =A0(E.g., don't bother to check certificates.) =A0Which hu= rts
security for service providers that do want SSL.

On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt
<torsten@lo= dderstedt.net> =A0wrote:
=A0 =A0
+1 =A0for the standard should recommand HTTPS or comparable means of
transport protection but not require it.

This requirement does not result in any benefit for the specification by itself (e.g. simplification). Therefore, the decision to use HTTPS or any other means should be up to the service providers based on its security
considerations.

One of the biggest differences between OAuth2 and WRAP is that OAuth2
requires that Protected Resources be accessed using HTTPS if no signature i= s
being used. Bullet Point #2 in Section 1.2 says:

=A0 =A04. =A0Don't allow bearer tokens without either SSL and/or signa= tures.
=A0 =A0 =A0 =A0While some providers may offer this ability, they should be= out
=A0 =A0 =A0 =A0of spec for doing so though technically it won't break = the flows.

While I personally think that requiring SSL is a fantastic idea, and it=92s=
very hard for me to argue against it, however....

One of the goals for WRAP was to define a standard AuthZ interface for
APIs which matched what we currently have on the Web. WRAP protected APIs are intended to be a replacement for screen scraping.

On the web, almost all websites implement Cookie Auth. Specifically, when you log into a website, the browser is issued a bearer token, called a
Cookie, and the browser is able to access Protected Resources by using the<= br> Cookie as the credential.

The WRAP access token is intended to be a direct replacement for the HTTP Cookie. A client should be able to present its bearer token (a WRAP Access<= br> Token or an HTTP Cookie) without having to sign the request.

While I certainly think that requiring SSL would be a huge improvement in internet security, HTTP does not require SSL, and since WRAP was intended t= o
be a replacement for HTTP Cookie Auth, then OAuth2 should also not require<= br> HTTPS.

Yes, dropping the SSL requirement isn=92t optimal, but again the intent wit= h
WRAP was to replace HTTP Cookie auth, and it should be up to the service provider to require HTTPS when applicable.

Allen

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


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

=A0 =A0 =A0

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


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


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

--000e0cd0eb46e75a0004839744eb-- From eran@hueniverse.com Tue Apr 6 14:29:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737E73A6960 for ; Tue, 6 Apr 2010 14:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j195x1-uwt0x for ; Tue, 6 Apr 2010 14:29:45 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1223B3A69D7 for ; Tue, 6 Apr 2010 14:29:44 -0700 (PDT) Received: (qmail 10208 invoked from network); 6 Apr 2010 21:29:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 21:29:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Apr 2010 14:29:14 -0700 From: Eran Hammer-Lahav To: Blaine Cook , OAuth WG Date: Tue, 6 Apr 2010 14:29:10 -0700 Thread-Topic: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures Thread-Index: AcrVvGGnORPAYMGXRDa753m1dokfPAAE9A1X Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:29:46 -0000 IETF standards can do one of two things: they can set a high level of security or they can clearly point out where they are insecure. If we do no= t require HTTPS for bearer tokens, we will have to put a big disclaimer that doing so without some other protections is insecure. The choice is between setting a higher bar and letting those who don't use HTTPS be called 'not in compliance', or set a low bar and put a SHOULD with a strongly worded warning. I strongly believe we have a responsibility to improve internet security. The only tool we are given in this working group is calling an implementation 'not in compliance'. Calling something insecure does not deter developers from doing stupid things (hence the wide use of Basic auth where it clearly must not be used per the spec). Calling something in-compliance when it is not falls under false marketing... At the end, you are free to deploy whatever you want. But if you are going to deploy OAuth in an insecure way (regardless of how insecure your other interfaces are), you don't get say it is compliant. Is anyone here na=EFve enough to think that the first time such an insecure OAuth token is stolen and abused, people will care that it was ignoring the SHOULD? The company will say that their implementation is in compliance and move the blame on t= o OAuth. Go implement whatever you want. But the spec should set the highest practical bar it can, and requiring HTTPS is trivial. As a practical note, if the WG reaches consensus to drop the MUST, I would ask the chairs to ask the security area and IESG to provide guidance whethe= r they would approve such document. The IESG did not approve OAuth 1.0a for publication as an RFC until this was changed to a MUST (for PLAINTEXT) amon= g other comments, and that with a strong warning. There is also an on going effort to improve cookie security. Do we really want OAuth to become the next weakest link? EHL On 4/6/10 12:04 PM, "Blaine Cook" wrote: > My take on this is that MUSTs MAY be ignored. ;-) >=20 > To echo John's concerns here, the worst-case scenario is that client > libraries implement "no SSL present" as a gentle reminder warning with > a flag (possibly the default) to disable those HTTPS warnings. Clients > that behave in that way should be flagged as non-compliant and > publicly humiliated. If we just write SHOULD for HTTPS/secure channel > support, then those clients are acting "properly." >=20 > If WRAP is aiming to just be a replacement for Cookie auth, then why > don't we just add a redirection profile for issuing cookies? They work > now, refreshing them is built-in, etc, etc. Instead, what we're trying > to do is build something better, more secure, and more aligned with > the sorts of behaviours we see and want to encourage on the web. >=20 > b. >=20 > On 6 April 2010 11:54, John Panzer wrote: >> My $.02: =A0SHOULD is okay, as long as all clients MUST support HTTPS. = =A0E.g., >> SHOULD for service providers, MUST support for clients. >> Otherwise, you will end up with clients that don't support https or don'= t do >> it properly. =A0(E.g., don't bother to check certificates.) =A0Which hur= ts >> security for service providers that do want SSL. >>=20 >> On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt >> wrote: >>>=20 >>> +1=A0 for the standard should recommand HTTPS or comparable means of >>> transport protection but not require it. >>>=20 >>> This requirement does not result in any benefit for the specification b= y >>> itself (e.g. simplification). Therefore, the decision to use HTTPS or a= ny >>> other means should be up to the service providers based on its security >>> considerations. >>>=20 >>> One of the biggest differences between OAuth2 and WRAP is that OAuth2 >>> requires that Protected Resources be accessed using HTTPS if no signatu= re is >>> being used. Bullet Point #2 in Section 1.2 says: >>>=20 >>> =A0=A0=A04. =A0Don't allow bearer tokens without either SSL and/or sign= atures. >>> =A0=A0=A0=A0=A0=A0=A0While some providers may offer this ability, they = should be out >>> =A0=A0=A0=A0=A0=A0=A0of spec for doing so though technically it won't b= reak the flows. >>>=20 >>> While I personally think that requiring SSL is a fantastic idea, and it= =B9s >>> very hard for me to argue against it, however.... >>>=20 >>> One of the goals for WRAP was to define a standard AuthZ interface for >>> APIs which matched what we currently have on the Web. WRAP protected AP= Is >>> are intended to be a replacement for screen scraping. >>>=20 >>> On the web, almost all websites implement Cookie Auth. Specifically, wh= en >>> you log into a website, the browser is issued a bearer token, called a >>> Cookie, and the browser is able to access Protected Resources by using = the >>> Cookie as the credential. >>>=20 >>> The WRAP access token is intended to be a direct replacement for the HT= TP >>> Cookie. A client should be able to present its bearer token (a WRAP Acc= ess >>> Token or an HTTP Cookie) without having to sign the request. >>>=20 >>> While I certainly think that requiring SSL would be a huge improvement = in >>> internet security, HTTP does not require SSL, and since WRAP was intend= ed to >>> be a replacement for HTTP Cookie Auth, then OAuth2 should also not requ= ire >>> HTTPS. >>>=20 >>> Yes, dropping the SSL requirement isn=B9t optimal, but again the intent= with >>> WRAP was to replace HTTP Cookie auth, and it should be up to the servic= e >>> provider to require HTTPS when applicable. >>>=20 >>> Allen >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Tue Apr 6 14:30:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6C923A69D7 for ; Tue, 6 Apr 2010 14:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88RefJlLJhtE for ; Tue, 6 Apr 2010 14:30:45 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BA6D43A6960 for ; Tue, 6 Apr 2010 14:30:45 -0700 (PDT) Received: (qmail 2532 invoked from network); 6 Apr 2010 21:30:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 21:30:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 6 Apr 2010 14:30:43 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Tue, 6 Apr 2010 14:30:39 -0700 Thread-Topic: [OAUTH-WG] Scope Thread-Index: AcrVcza+YwTdl+euRjGbyrwIkY68RwAXTAod Message-ID: In-Reply-To: <4BBB0B97.6090704@lodderstedt.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E0F60F31DAEeranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:30:47 -0000 --_000_C7E0F60F31DAEeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Like anything else, we need proposed text to discuss. Discussing a list of = attributes is rarely practical. Discussing a concrete proposal usually work= s... EHL On 4/6/10 3:23 AM, "Torsten Lodderstedt" wrote: Hi Eran, > I agree that this is the right approach (separate parameters to well defi= ned > scope attributes). However, so far the only well-defined attribute is a > protected segment name (aka realm). > how shall we proceed in order to come to more well-defined attributes? I already proposed some, can we discuss them? regards, Torsten. > EHL > > > On 4/3/10 1:25 AM, "Torsten Lodderstedt" wrote: > > >> You are right, there are different aspects of scope. Why not define one >> optional parameter per scope aspect? >> >> Based on our experiences with implementing OAuth 1.0a at Deutsche >> Telekom, I see the need for the following parameters >> - resource: specification of the protected resource to be accessed >> (type: URI or opaque string) >> - requested permissions: permissions on this resource the client want >> to get authorized by the user (comma-separated list of opaque strings). >> The range of permissions is defined by the resource as part of its API >> design. This could be something like "upload", "download", "sent", or >> "establish connection". The set of available permissions might be >> advertised by way of a WWW-Authenticate parameter (status code 401), as >> part of a 403 response, or in a XRDS discovery process. >> - requested duration: specification of the token duration the client >> asks for >> >> regards, >> Torsten. >> >>> ... >>> There isn't one - its service specific. >>> >>> The easy ones are: >>> >>> Duration >>> List of protected resources, URI wildcard, or name of protected segment >>> Read/write access or HTTP methods >>> >>> 3 years ago when we dropped the scope/token_attributes parameter from t= he >>> spec we decided to bring it back when we have enough deployment experie= nce. >>> I strongly believe this rule still holds. >>> >>> It would be great if those with OAuth 1.0a deployments can share how th= ey >>> specify scope. >>> >>> EHL >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> > --_000_C7E0F60F31DAEeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Scope Like anything else, we need proposed text to discuss. Discussing a li= st of attributes is rarely practical. Discussing a concrete proposal usuall= y works...

EHL


On 4/6/10 3:23 AM, "Torsten Lodderstedt" <torsten@lodderstedt.net> wrote:

Hi Eran,

> I agree that this is the right approach (separate parameters to well d= efined
> scope attributes). However, so far the only well-defined attribute is = a
> protected segment name (aka realm).
>   
how shall we proceed in order to come to more well-defined attributes? I already proposed some, can we discuss them?

regards,
Torsten.
> EHL
>
>
> On 4/3/10 1:25 AM, "Torsten Lodderstedt"<torsten@lodderstedt.net>  wrote:
>
>   
>> You are right, there are different aspects of scope. Why not defin= e one
>> optional parameter per scope aspect?
>>
>> Based on our experiences with implementing OAuth 1.0a at Deutsche<= BR> >> Telekom, I see the need for the following parameters
>> - resource: specification of the protected resource to be accessed=
>> (type: URI or opaque string)
>> - requested permissions:  permissions on this resource the cl= ient want
>> to get authorized by the user (comma-separated list of opaque stri= ngs).
>> The range of permissions is defined by the resource as part of its= API
>> design. This could be something like "upload", "dow= nload", "sent", or
>> "establish connection". The set of available permissions= might be
>> advertised by way of a WWW-Authenticate parameter (status code 401= ), as
>> part of a 403 response, or in a XRDS discovery process.
>> - requested duration: specification of the token duration the clie= nt
>> asks for
>>
>> regards,
>> Torsten.
>>     
>>> ...
>>> There isn't one - its service specific.
>>>
>>> The easy ones are:
>>>
>>> Duration
>>> List of protected resources, URI wildcard, or name of protecte= d segment
>>> Read/write access or HTTP methods
>>>
>>> 3 years ago when we dropped the scope/token_attributes paramet= er from the
>>> spec we decided to bring it back when we have enough deploymen= t experience.
>>> I strongly believe this rule still holds.
>>>
>>> It would be great if those with OAuth 1.0a deployments can sha= re how they
>>> specify scope.
>>>
>>> EHL
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https:= //www.ietf.org/mailman/listinfo/oauth
>>>
>>>       
>>
>>
>>     
>   



--_000_C7E0F60F31DAEeranhueniversecom_-- From eran@hueniverse.com Tue Apr 6 14:41:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E8B3A6A01 for ; Tue, 6 Apr 2010 14:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-cJZ8QOydKp for ; Tue, 6 Apr 2010 14:41:12 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 7E1853A699A for ; Tue, 6 Apr 2010 14:41:12 -0700 (PDT) Received: (qmail 15689 invoked from network); 6 Apr 2010 21:41:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 21:41:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 6 Apr 2010 14:41:09 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Tue, 6 Apr 2010 14:41:06 -0700 Thread-Topic: [OAUTH-WG] Scope using Realm idea Thread-Index: AcrVmmXaTXWygkywRLqWmrZBqlcfdgAN3bIP Message-ID: In-Reply-To: <0E777AD1-500D-4FEA-BBAB-069060A40D73@gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:41:13 -0000 RFC 2617 defines what a realm is - a set of resources sharing the same set of credentials. It saves the client the need to prompt the user again for their credentials when browsing a site across resources. Because sending credentials to the wrong place is dangerous, realms are hard to use because the client must take into account more than just the same realm but also th= e domain name, etc. Most of the example people gave for their use of scope where in practice a segment ('photos', 'contacts', etc.). Usually each of these groups use different APIs (a single API call that can bring both a photo and contact, but only a photo if using a limited token without contact access, is rare). This is why I suggested using realm as a well defined subset of what people here refer to as 'scope'. I don't like the idea of defining a parameter that requires internal structure as opaque and leaving it up to the individual services to define. This doesn't help interop. If you have to define the structure of the scope parameter, you might as well define the parameter as well. The argument that having a consistent parameter with an opaque value help libraries is silly. Good libraries will pass along any custom parameters they found to the higher level. This adds nothing but is likely to cause problems when people code libraries with scope structure specific to one company. It will also cause confusion when two scopes mean completely different things across services. EHL On 4/6/10 8:03 AM, "Dick Hardt" wrote: >=20 >=20 > On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote: >=20 >>=20 >>=20 >>=20 >> On 4/2/10 3:27 PM, "Dick Hardt" wrote: >>=20 >>> There are times when a resource may have different scope for different = kinds >>> of access. realm !=3D scope >>=20 >> No. Realm is a subset. It is what people define as the protected segment >> name. >=20 > Different Protected Resources could require the same scope, so I see rea= lm > and scope as being orthogonal. >=20 >> For any other scope attribute we need to first define it. >=20 > Why? Scope will often be application specific. >=20 >=20 From eran@hueniverse.com Tue Apr 6 14:43:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA323A6958 for ; Tue, 6 Apr 2010 14:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLzerW5kD7Wd for ; Tue, 6 Apr 2010 14:43:13 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1E01B3A6A2E for ; Tue, 6 Apr 2010 14:43:13 -0700 (PDT) Received: (qmail 16855 invoked from network); 6 Apr 2010 21:43:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 21:43:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Apr 2010 14:42:54 -0700 From: Eran Hammer-Lahav To: Luke Shepard , Dick Hardt Date: Tue, 6 Apr 2010 14:42:50 -0700 Thread-Topic: [OAUTH-WG] Scope using Realm idea Thread-Index: AcrVnfQ34LAmIKgqTI2e0H2/hyNDyAANCZpx Message-ID: In-Reply-To: <27B54FC8-6C50-4283-89AF-6EB44A6FD006@facebook.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E0F8EA31DB5eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:43:17 -0000 --_000_C7E0F8EA31DB5eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The question is how your APIs are structure. Do you have APIs that require = multiple "scopes" in a single call? EHL On 4/6/10 8:29 AM, "Luke Shepard" wrote: For Facebook at least, we are currently planning to use scope as a comma-se= parated list of permissions from this set: http://wiki.developers.facebook.= com/index.php/Extended_permissions For instance: oauth_scope=3Dread_stream,email,photo_upload I'm not sure if that maps to realm exactly. On Apr 6, 2010, at 8:03 AM, Dick Hardt wrote: > > On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote: > >> >> >> >> On 4/2/10 3:27 PM, "Dick Hardt" wrote: >> >>> There are times when a resource may have different scope for different = kinds >>> of access. realm !=3D scope >> >> No. Realm is a subset. It is what people define as the protected segment >> name. > > Different Protected Resources could require the same scope, so I see real= m and scope as being orthogonal. > >> For any other scope attribute we need to first define it. > > Why? Scope will often be application specific. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_C7E0F8EA31DB5eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Scope using Realm idea The question is how your APIs are structure. Do you have APIs that re= quire multiple “scopes” in a single call?

EHL


On 4/6/10 8:29 AM, "Luke Shepard" <lshepard@facebook.com> wrote:

For Facebook at least, we are currently pla= nning to use scope as a comma-separated list of permissions from this set: = http://wiki.developers.facebook.com/index.php/Extended_permissions<= BR>
For instance:

        oauth_scope=3Dread_stream,e= mail,photo_upload

I'm not sure if that maps to realm exactly.

On Apr 6, 2010, at 8:03 AM, Dick Hardt wrote:

>
> On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote:
>
>>
>>
>>
>> On 4/2/10 3:27 PM, "Dick Hardt" <dick.hardt@gmail.com> wrote:
>>
>>> There are times when a resource may have different scope for d= ifferent kinds
>>> of access. realm !=3D scope
>>
>> No. Realm is a subset. It is what people define as the protected s= egment
>> name.
>
> Different Protected Resources could require the same scope, so I see r= ealm and scope as being orthogonal.
>
>> For any other scope attribute we need to first define it.
>
> Why? Scope will often be application specific.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth


--_000_C7E0F8EA31DB5eranhueniversecom_-- From eran@hueniverse.com Tue Apr 6 14:44:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F343A6958 for ; Tue, 6 Apr 2010 14:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlSvaIm38QK6 for ; Tue, 6 Apr 2010 14:44:41 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 0D0B93A6A45 for ; Tue, 6 Apr 2010 14:44:38 -0700 (PDT) Received: (qmail 17669 invoked from network); 6 Apr 2010 21:44:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 21:44:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Apr 2010 14:44:30 -0700 From: Eran Hammer-Lahav To: Evan Gilbert Date: Tue, 6 Apr 2010 14:44:27 -0700 Thread-Topic: [OAUTH-WG] Comments on Web Callback & Client Flow Thread-Index: AcrVkitujVD7sKHGQ5O78PgMYNSjcAAQCkBL Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Eran Hammer-Lahav , OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:44:42 -0000 On 4/6/10 7:04 AM, "Evan Gilbert" wrote: >=20 >=20 > On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav > wrote: >> Hi Evan, >>=20 >> On 4/5/10 4:28 PM, "Evan Gilbert" wrote: >>=20 >>> 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow >>> We should have an OPTIONAL username parameter: >>> username >>> =A0=A0The resource owner's username. The authorization server MUST only= send >>> back >>> refresh tokens or access tokens for this user. >>>=20 >>> This is useful for clients where a user is already logged into a 3rd pa= rty >>> web >>> site with a specific account, and the client wants the authorization to >>> match >>> the specific user. >>=20 >> I think introducing the concept of user identity is more complex than ju= st a >> username parameter. I agree that it can be useful but we need a more >> detailed discussion about this before we add it. >=20 > I agree issues around user identity are complex. >=20 > Would it help to spin up a separate discussion thread on this one issue? That's one way. A more developed proposal is another. EHL From eran@hueniverse.com Tue Apr 6 14:46:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70CA23A6958 for ; Tue, 6 Apr 2010 14:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bORxDsVZWRDe for ; Tue, 6 Apr 2010 14:46:29 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BDFDC3A6A2B for ; Tue, 6 Apr 2010 14:46:28 -0700 (PDT) Received: (qmail 15992 invoked from network); 6 Apr 2010 21:46:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 21:46:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Apr 2010 14:46:26 -0700 From: Eran Hammer-Lahav To: Luke Shepard Date: Tue, 6 Apr 2010 14:46:23 -0700 Thread-Topic: [OAUTH-WG] Renaming expires to expires_in? Thread-Index: AcrVnUFHfbQyCkOXQVChAWIe6+ALOQANVhNW Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E0F9BF31DB9eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Renaming expires to expires_in? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:46:33 -0000 --_000_C7E0F9BF31DB9eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "The duration in seconds of the access token lifetime." I liked 'lifetime' better than 'expires_in' (for no particular reason), but= lifetime can mean number of uses. EHL On 4/6/10 8:24 AM, "Luke Shepard" wrote: Just curious, where did "duration" come from? I hate to be picky, but I feel like "expires_in" is more clear than "durati= on" ... if only because other protocols (OAuth 1.0a, OpenID, Facebook auth)= use "expires". On Apr 6, 2010, at 12:11 AM, Eran Hammer-Lahav wrote: Changed to 'duration'. EHL On 4/5/10 9:09 AM, "David Recordon" > wrote: As one of our engineers was implementing a client, they got confused about = what was being returned by the expires parameter. Anyone object to renaming= it to expires_in so that it's clear that it isn't an absolute timestamp? Thanks, --David _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C7E0F9BF31DB9eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Renaming expires to expires_in? “The duration in seconds of the access token lifetime.”
I liked ‘lifetime’ better than ‘expires_in’ (for no= particular reason), but lifetime can mean number of uses.

EHL


On 4/6/10 8:24 AM, "Luke Shepard" <lshepard@facebook.com> wrote:

Just curious, where did "duration"= ; come from?

I hate to be picky, but I feel like "expires_in" is more clear th= an "duration" ... if only because other protocols (OAuth 1.0a, Op= enID, Facebook auth) use "expires".

On Apr 6, 2010, at 12:11 AM, Eran Hammer-Lahav wrote:

Changed to ‘duration’.

EHL


On 4/5/10 9:09 AM, "David Recordon" <davidrecordon@facebook.com <x-msg://353/davidrecordon@facebook.com> > wrot= e:

As one of our engineers was implementing a = client, they got confused about what was being returned by the expires para= meter. Anyone object to renaming it to expires_in so that it's clear that i= t isn't an absolute timestamp?

Thanks,
--David
_______________________________________________
OAuth mailing list
OAuth@ietf.org <x-msg://353/OAuth@ietf.org>
https://www.ietf.or= g/mailman/listinfo/oauth

Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:50:42 -0000 --_000_C7E0FAAB31DBBeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That's only when you need to trust the client. If your requirements demand = registration, discovery is mostly pointless (other than dynamic configurati= on). EHL On 4/6/10 6:58 AM, "Brian Eaton" wrote: Web clients are expected to have secrets or to have otherwise registered with the AS. In order for them to use those secrets, they need to know the AS URL. Cheers, Brian On Tue, Apr 6, 2010 at 1:23 AM, Eran Hammer-Lahav wro= te: > Why? > > > On 4/6/10 12:58 AM, "Brian Eaton" wrote: > > On Tue, Apr 6, 2010 at 12:47 AM, Eran Hammer-Lahav > wrote: >> That's the same as what I have in the draft, only with a single endpoint >> instead of two. Since we already have a 'mode' parameter (which I am >> renaming to 'type'), that single endpoint can speak more than one flow. > > Note that the discovery flow I outlined only works for rich clients, > and is completely insecure for other types of clients. > > In another thread Leif mentioned similar concerns. I think they are > justified. > > Cheers, > Brian > > --_000_C7E0FAAB31DBBeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Scope using Realm idea That’s only when you need to trust the client. If your requirem= ents demand registration, discovery is mostly pointless (other than dynamic= configuration).

EHL


On 4/6/10 6:58 AM, "Brian Eaton" <beaton@google.com> wrote:

Web clients are expected to have secrets or= to have otherwise
registered with the AS.  In order for them to use those secrets, they<= BR> need to know the AS URL.

Cheers,
Brian

On Tue, Apr 6, 2010 at 1:23 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Why?
>
>
> On 4/6/10 12:58 AM, "Brian Eaton" <beaton@google.com> wrote:
>
> On Tue, Apr 6, 2010 at 12:47 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>> That’s the same as what I have in the draft, only with a sin= gle endpoint
>> instead of two. Since we already have a ‘mode’ paramet= er (which I am
>> renaming to ‘type’), that single endpoint can speak mo= re than one flow.
>
> Note that the discovery flow I outlined only works for rich clients, > and is completely insecure for other types of clients.
>
> In another thread Leif mentioned similar concerns. =A0I think they are=
> justified.
>
> Cheers,
> Brian
>
>

--_000_C7E0FAAB31DBBeranhueniversecom_-- From mscurtescu@google.com Tue Apr 6 14:58:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7703A68A5 for ; Tue, 6 Apr 2010 14:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LvapDcYAFpu for ; Tue, 6 Apr 2010 14:58:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BDE423A689C for ; Tue, 6 Apr 2010 14:58:25 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o36LwJDM007530 for ; Tue, 6 Apr 2010 14:58:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270591099; bh=G6pXirLsdyjIISgaJSjpeqXKCuU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=REJnQktD/QTBQqX9nbt7pN4hg4dK+Qvf4yQTwD7yRLIq7W3dIu8q9d658nRU+09I6 2yr+ZwO3aNpWgrS76IBZg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=Y3hjSwEBNrbs24RwP+dKebnwSRO6sM4Q2kBzrF0kAbARkvba7Rm2oyGMSOMmGyrcG JinQ9f53n+IKKevJmgZCw== Received: from pzk17 (pzk17.prod.google.com [10.243.19.145]) by kpbe11.cbf.corp.google.com with ESMTP id o36LwHaL023483 for ; Tue, 6 Apr 2010 16:58:17 -0500 Received: by pzk17 with SMTP id 17so401826pzk.5 for ; Tue, 06 Apr 2010 14:58:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Tue, 6 Apr 2010 14:57:57 -0700 (PDT) In-Reply-To: References: <27B54FC8-6C50-4283-89AF-6EB44A6FD006@facebook.com> From: Marius Scurtescu Date: Tue, 6 Apr 2010 14:57:57 -0700 Received: by 10.140.247.15 with SMTP id u15mr6363921rvh.1.1270591097344; Tue, 06 Apr 2010 14:58:17 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:58:27 -0000 On Tue, Apr 6, 2010 at 2:42 PM, Eran Hammer-Lahav wro= te: > The question is how your APIs are structure. Do you have APIs that requir= e > multiple =93scopes=94 in a single call? Things can get even more complicated. When the user grants access for the client, the approval page should list all the scopes the client is requesting. This is the set of scopes needed by the client for *all* the API calls. Each API will need a subset of this approved, larger set. With that in mind, it would be useful to be able to down-scope access tokens when using the refresh token, this way the client can send the smallest set of scopes with each API call. But again, for all the above, the client must have intimate knowledge of the APIs (aka protected resources) and what scopes are required, the OAuth 2.0 libraries used by the client can treat the scopes as opaque strings IMO. Marius > > EHL > > > On 4/6/10 8:29 AM, "Luke Shepard" wrote: > > For Facebook at least, we are currently planning to use scope as a > comma-separated list of permissions from this set: > http://wiki.developers.facebook.com/index.php/Extended_permissions > > For instance: > > =A0=A0=A0=A0=A0=A0=A0=A0oauth_scope=3Dread_stream,email,photo_upload > > I'm not sure if that maps to realm exactly. > > On Apr 6, 2010, at 8:03 AM, Dick Hardt wrote: > >> >> On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote: >> >>> >>> >>> >>> On 4/2/10 3:27 PM, "Dick Hardt" wrote: >>> >>>> There are times when a resource may have different scope for different >>>> kinds >>>> of access. realm !=3D scope >>> >>> No. Realm is a subset. It is what people define as the protected segmen= t >>> name. >> >> Different Protected Resources could require the same scope, so I see rea= lm >> and scope as being orthogonal. >> >>> For any other scope attribute we need to first define it. >> >> Why? Scope will often be application specific. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Tue Apr 6 15:12:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60FEF3A69E5 for ; Tue, 6 Apr 2010 15:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6oh7CHiBFNi for ; Tue, 6 Apr 2010 15:12:45 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EB9613A6933 for ; Tue, 6 Apr 2010 15:12:44 -0700 (PDT) Received: (qmail 5144 invoked from network); 6 Apr 2010 22:12:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 22:12:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Apr 2010 15:12:36 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Tue, 6 Apr 2010 15:12:31 -0700 Thread-Topic: [OAUTH-WG] Scope using Realm idea Thread-Index: AcrV1EaitWnGKKCgTcmLV2WuST8VuAAAfmP9 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E0FFDF31DC1eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:12:51 -0000 --_000_C7E0FFDF31DC1eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am still waiting for someone to show how a scope parameter with an opaque= value helps interop, where every single example requires the client to kno= w how to construct this opaque string. OAuth libraries will need to support= extension parameters - that's a given. So how is this not an extension if = you will have to document how to use it in your own API spec? If I want to ask for both a set of resources (photos, contact), access righ= ts (read, write), and a specific duration (3 days), should I put all this i= nto the scope parameter? Put some in and some in another parameter? Help me write a definition that helps people understand exactly when and ho= w they should use this parameter. How are you going to use it? EHL On 4/6/10 2:57 PM, "Marius Scurtescu" wrote: On Tue, Apr 6, 2010 at 2:42 PM, Eran Hammer-Lahav wro= te: > The question is how your APIs are structure. Do you have APIs that requir= e > multiple "scopes" in a single call? Things can get even more complicated. When the user grants access for the client, the approval page should list all the scopes the client is requesting. This is the set of scopes needed by the client for *all* the API calls. Each API will need a subset of this approved, larger set. With that in mind, it would be useful to be able to down-scope access tokens when using the refresh token, this way the client can send the smallest set of scopes with each API call. But again, for all the above, the client must have intimate knowledge of the APIs (aka protected resources) and what scopes are required, the OAuth 2.0 libraries used by the client can treat the scopes as opaque strings IMO. Marius > > EHL > > > On 4/6/10 8:29 AM, "Luke Shepard" wrote: > > For Facebook at least, we are currently planning to use scope as a > comma-separated list of permissions from this set: > http://wiki.developers.facebook.com/index.php/Extended_permissions > > For instance: > > oauth_scope=3Dread_stream,email,photo_upload > > I'm not sure if that maps to realm exactly. > > On Apr 6, 2010, at 8:03 AM, Dick Hardt wrote: > >> >> On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote: >> >>> >>> >>> >>> On 4/2/10 3:27 PM, "Dick Hardt" wrote: >>> >>>> There are times when a resource may have different scope for different >>>> kinds >>>> of access. realm !=3D scope >>> >>> No. Realm is a subset. It is what people define as the protected segmen= t >>> name. >> >> Different Protected Resources could require the same scope, so I see rea= lm >> and scope as being orthogonal. >> >>> For any other scope attribute we need to first define it. >> >> Why? Scope will often be application specific. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --_000_C7E0FFDF31DC1eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Scope using Realm idea I am still waiting for someone to show how a scope parameter with an = opaque value helps interop, where every single example requires the client = to know how to construct this opaque string. OAuth libraries will need to s= upport extension parameters – that’s a given. So how is this no= t an extension if you will have to document how to use it in your own API s= pec?

If I want to ask for both a set of resources (photos, contact), access righ= ts (read, write), and a specific duration (3 days), should I put all this i= nto the scope parameter? Put some in and some in another parameter?

Help me write a definition that helps people understand exactly when and ho= w they should use this parameter. How are you going to use it?

EHL




On 4/6/10 2:57 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote:

On Tue, Apr 6, 2010 at 2:42 PM, Eran Hammer= -Lahav <eran@hueniverse.com> wrot= e:
> The question is how your APIs are structure. Do you have APIs that req= uire
> multiple “scopes” in a single call?

Things can get even more complicated. When the user grants access for
the client, the approval page should list all the scopes the client is
requesting. This is the set of scopes needed by the client for *all*
the API calls. Each API will need a subset of this approved, larger
set.

With that in mind, it would be useful to be able to down-scope access
tokens when using the refresh token, this way the client can send the
smallest set of scopes with each API call.

But again, for all the above, the client must have intimate knowledge
of the APIs (aka protected resources) and what scopes are required,
the OAuth 2.0 libraries used by the client can treat the scopes as
opaque strings IMO.

Marius

>
> EHL
>
>
> On 4/6/10 8:29 AM, "Luke Shepard" <lshepard@facebook.com> wrote:
>
> For Facebook at least, we are currently planning to use scope as a
> comma-separated list of permissions from this set:
> http://wiki.developers.facebook.com/index.php/Extended_permissions=
>
> For instance:
>
> =A0=A0=A0=A0=A0=A0=A0=A0oauth_scope=3Dread_stream,email,photo_upload >
> I'm not sure if that maps to realm exactly.
>
> On Apr 6, 2010, at 8:03 AM, Dick Hardt wrote:
>
>>
>> On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote:
>>
>>>
>>>
>>>
>>> On 4/2/10 3:27 PM, "Dick Hardt" <dick.hardt@gmail.com> wrote:
>>>
>>>> There are times when a resource may have different scope f= or different
>>>> kinds
>>>> of access. realm !=3D scope
>>>
>>> No. Realm is a subset. It is what people define as the protect= ed segment
>>> name.
>>
>> Different Protected Resources could require the same scope, so I s= ee realm
>> and scope as being orthogonal.
>>
>>> For any other scope attribute we need to first define it.
>>
>> Why? Scope will often be application specific.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
>
>

--_000_C7E0FFDF31DC1eranhueniversecom_-- From eran@hueniverse.com Tue Apr 6 15:21:16 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3D628C147 for ; Tue, 6 Apr 2010 15:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6OzIVdPI4OU for ; Tue, 6 Apr 2010 15:21:05 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 639D63A6A03 for ; Tue, 6 Apr 2010 15:18:14 -0700 (PDT) Received: (qmail 32644 invoked from network); 6 Apr 2010 22:18:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2010 22:18:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Apr 2010 15:17:45 -0700 From: Eran Hammer-Lahav To: John Kemp Date: Tue, 6 Apr 2010 15:17:41 -0700 Thread-Topic: [OAUTH-WG] Scope using Realm idea Thread-Index: AcrUPpQflwAbvQjZThGonJ0x9dZaJgBmGTWk Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E1011531DC8eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:21:16 -0000 --_000_C7E1011531DC8eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks John. I tend to agree that realm comes with a lot of baggage and is probably not = going to work given people's expectations. After all, they are not likely t= o study 2617 before implementing OAuth. The point of my proposal was to show one aspect of scope in which the clien= t is being told what kind of access it should ask for. The client treats th= is as an opaque string, and it remains the an opaque string (i.e. No higher= level handling by the client). In this scenario, if the client has an acce= ss token for "photos,contact", it will not use it for "contact,photos". There seems to be high demand for scope parameter support, but very little = actual use cases (provided). EHL On 4/4/10 2:34 PM, "John Kemp" wrote: Hi Eran, On Apr 2, 2010, at 12:18 PM, Eran Hammer-Lahav wrote: > This is half baked but I wanted to get people's reaction: > > Clients tries accessing a resource with or without an access token: > > GET /resource/1 HTTP/1.1 > Host: server.example.com > > The server replies with: > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: OAuth realm=3D'example' >From RFC 2617 (http://www.ietf.org/rfc/rfc2617.txt): "The realm value (case-sensitive), in combination with the canonical root U= RL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realms." and: realm A string to be displayed to users so they know which username and password to use. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be "registered_users@gotham.news.com". Leading me to conclude: i) Realm is supposed to contain a hint for users as to which username/passw= ord to use (ie. a client cannot by default assume it to be machine-readable= ) ii) The "protection space" defined by a realm may be as small as one resour= ce, or as big as an entire site. RFC2617 tells clients what they can assume= if they receive a challenge: "A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server." > > Clients requests an access token (using the client credentials flow) and > includes the requested realm (line breaks for display purposes): > > POST /access_token HTTP/1.1 > Host: server.example.com > > client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpnqmM& > mode=3Dflow_client&realm=3Dexample > > The server issues a access token capable of accessing the resource realm. > > This means one new parameter on the request side which is already baked i= nto > the 401 response in a standard way. > > Thoughts? I think that RFC2617 realms are similar in concept to the 'scope' you're lo= oking for, but have some differences in use for the HTTP basic/digest proto= col. In order to be sure you don't confuse clients which already know HTTP = Basic/Digest, you may want to place some further restrictions on the values= that can be in the realm parameter when a WWW-Authenticate challenge is is= sued (it's just a string in RFC2617). If a client receives an OAuth WWW-Aut= henticate challenge, I would assume that OAuth should anyway tell the clien= t whether/what to present the user in order to have the client get an appro= priate token to access the protected resource. Some care is needed to specify this in a way that is compatible with the ex= pected behaviour of user agents already familiar with RFC2617. Regards, - johnk --_000_C7E1011531DC8eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Scope using Realm idea Thanks John.

I tend to agree that realm comes with a lot of baggage and is probably not = going to work given people’s expectations. After all, they are not li= kely to study 2617 before implementing OAuth.

The point of my proposal was to show one aspect of scope in which the clien= t is being told what kind of access it should ask for. The client treats th= is as an opaque string, and it remains the an opaque string (i.e. No higher= level handling by the client). In this scenario, if the client has an acce= ss token for “photos,contact”, it will not use it for “co= ntact,photos”.

There seems to be high demand for scope parameter support, but very little = actual use cases (provided).

EHL


On 4/4/10 2:34 PM, "John Kemp" <joh= n@jkemp.net> wrote:

Hi Eran,

On Apr 2, 2010, at 12:18 PM, Eran Hammer-Lahav wrote:

> This is half baked but I wanted to get people's reaction:
>
> Clients tries accessing a resource with or without an access token: >
> GET /resource/1 HTTP/1.1
> Host: server.example.com
>
> The server replies with:
>
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: OAuth realm=3D'example'

>From RFC 2617 (http://www.i= etf.org/rfc/rfc2617.txt):

"The realm value (case-sensitive), in combination with the canonical r= oot URL (the
absoluteURI for the server whose abs_path is empty; see section 5.1.2
of [2]) of the server being accessed, defines the protection space.
These realms allow the protected resources on a server to be
partitioned into a set of protection spaces, each with its own
authentication scheme and/or authorization database. The realm value
is a string, generally assigned by the origin server, which may have
additional semantics specific to the authentication scheme. Note that
there may be multiple challenges with the same auth-scheme but
different realms."

and:

realm
A string to be displayed to users so they know which username and
password to use. This string should contain at least the name of
the host performing the authentication and might additionally
indicate the collection of users who might have access. An example
might be "registered_user= s@gotham.news.com".

Leading me to conclude:

i) Realm is supposed to contain a hint for users as to which username/passw= ord to use (ie. a client cannot by default assume it to be machine-readable= )
ii) The "protection space" defined by a realm may be as small as = one resource, or as big as an entire site. RFC2617 tells clients what they = can assume if they receive a challenge:

"A client SHOULD assume that all paths at or deeper than the depth of<= BR> the last symbolic element in the path field of the Request-URI also
are within the protection space specified by the Basic realm value of
the current challenge. A client MAY preemptively send the
corresponding Authorization header with requests for resources in
that space without receipt of another challenge from the server."

>
> Clients requests an access token (using the client credentials flow) a= nd
> includes the requested realm (line breaks for display purposes):
>
> POST /access_token HTTP/1.1
> Host: server.example.com
>
> client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpnqmM&
> mode=3Dflow_client&realm=3Dexample
>
> The server issues a access token capable of accessing the resource rea= lm.
>
> This means one new parameter on the request side which is already bake= d into
> the 401 response in a standard way.
>
> Thoughts?

I think that RFC2617 realms are similar in concept to the 'scope' you're lo= oking for, but have some differences in use for the HTTP basic/digest proto= col. In order to be sure you don't confuse clients which already know HTTP = Basic/Digest, you may want to place some further restrictions on the values= that can be in the realm parameter when a WWW-Authenticate challenge is is= sued (it's just a string in RFC2617). If a client receives an OAuth WWW-Aut= henticate challenge, I would assume that OAuth should anyway tell the clien= t whether/what to present the user in order to have the client get an appro= priate token to access the protected resource.

Some care is needed to specify this in a way that is compatible with the ex= pected behaviour of user agents already familiar with RFC2617.

Regards,

- johnk



--_000_C7E1011531DC8eranhueniversecom_-- From mscurtescu@google.com Tue Apr 6 15:28:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6A53A68C5 for ; Tue, 6 Apr 2010 15:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaBU96NX5auO for ; Tue, 6 Apr 2010 15:28:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 659683A68A4 for ; Tue, 6 Apr 2010 15:28:36 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o36MSRpA029396 for ; Wed, 7 Apr 2010 00:28:31 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270592912; bh=0CR8fviRXuU3UWEeoxox6P3m6Rw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=SVQmDPdi8G+0UTraIQcXdI8DB9V67mifn/LK3Hm9Xx2GQvp2VlczE8qRr+rAUf+F9 OXkmWt5eJl9x9tQsOX9eg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=ivKCMcH9TBoSyD5fPUHGL5QtjbeUzg0xwvdwlHKDK1YKCmKQQwXdXd/SAUXMohdQL YrtWtR2sGo9k/AyxtWCew== Received: from pwj3 (pwj3.prod.google.com [10.241.219.67]) by wpaz1.hot.corp.google.com with ESMTP id o36MSDWI012085 for ; Tue, 6 Apr 2010 15:28:26 -0700 Received: by pwj3 with SMTP id 3so421324pwj.8 for ; Tue, 06 Apr 2010 15:28:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Tue, 6 Apr 2010 15:28:06 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 6 Apr 2010 15:28:06 -0700 Received: by 10.140.87.23 with SMTP id k23mr6284013rvb.108.1270592906186; Tue, 06 Apr 2010 15:28:26 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:28:37 -0000 On Tue, Apr 6, 2010 at 3:12 PM, Eran Hammer-Lahav wro= te: > I am still waiting for someone to show how a scope parameter with an opaq= ue > value helps interop, where every single example requires the client to kn= ow > how to construct this opaque string. OAuth libraries will need to support > extension parameters =96 that=92s a given. So how is this not an extensio= n if > you will have to document how to use it in your own API spec? You are probably right, an opaque scope does not help interop. I think the reason the scope parameter was added to wrap is that in practice with OAuth most implementations ended up needing such a parameter. Having a standard one prevents everyone from (re)inventing a custom parameter. Beyond that, I don't see any benefits. > If I want to ask for both a set of resources (photos, contact), access > rights (read, write), and a specific duration (3 days), should I put all > this into the scope parameter? Put some in and some in another parameter? Set of resources and access rights probably go together in a scope. Not so sure about duration, until now duration was considered unlimited, Authz Servers probably allow users to revoke access at any time (this would revoke the corresponding refresh token and any auto-approvals). > Help me write a definition that helps people understand exactly when and = how > they should use this parameter. How are you going to use it? I think the vague definition from the wrap spec was good enough: "The Authorization Server MAY define authorization scope values for the Client to include" Marius > > EHL > > > > > On 4/6/10 2:57 PM, "Marius Scurtescu" wrote: > > On Tue, Apr 6, 2010 at 2:42 PM, Eran Hammer-Lahav > wrote: >> The question is how your APIs are structure. Do you have APIs that requi= re >> multiple =93scopes=94 in a single call? > > Things can get even more complicated. When the user grants access for > the client, the approval page should list all the scopes the client is > requesting. This is the set of scopes needed by the client for *all* > the API calls. Each API will need a subset of this approved, larger > set. > > With that in mind, it would be useful to be able to down-scope access > tokens when using the refresh token, this way the client can send the > smallest set of scopes with each API call. > > But again, for all the above, the client must have intimate knowledge > of the APIs (aka protected resources) and what scopes are required, > the OAuth 2.0 libraries used by the client can treat the scopes as > opaque strings IMO. > > Marius > >> >> EHL >> >> >> On 4/6/10 8:29 AM, "Luke Shepard" wrote: >> >> For Facebook at least, we are currently planning to use scope as a >> comma-separated list of permissions from this set: >> http://wiki.developers.facebook.com/index.php/Extended_permissions >> >> For instance: >> >> =A0=A0=A0=A0=A0=A0=A0=A0oauth_scope=3Dread_stream,email,photo_upload >> >> I'm not sure if that maps to realm exactly. >> >> On Apr 6, 2010, at 8:03 AM, Dick Hardt wrote: >> >>> >>> On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote: >>> >>>> >>>> >>>> >>>> On 4/2/10 3:27 PM, "Dick Hardt" wrote: >>>> >>>>> There are times when a resource may have different scope for differen= t >>>>> kinds >>>>> of access. realm !=3D scope >>>> >>>> No. Realm is a subset. It is what people define as the protected segme= nt >>>> name. >>> >>> Different Protected Resources could require the same scope, so I see >>> realm >>> and scope as being orthogonal. >>> >>>> For any other scope attribute we need to first define it. >>> >>> Why? Scope will often be application specific. >>> >>> _______________________________________________ >>> OAuth mailing 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 mscurtescu@google.com Tue Apr 6 15:40:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEDCD3A69BC for ; Tue, 6 Apr 2010 15:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgkyBakkIm65 for ; Tue, 6 Apr 2010 15:40:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 2D9293A697F for ; Tue, 6 Apr 2010 15:40:10 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o36Me5xH012230 for ; Wed, 7 Apr 2010 00:40:06 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270593606; bh=ZzqcctOiH+kjDgrwCM7vPyWzGt4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=EtinX5C9Ljia5rv6Tfi2EFHO3aQ8h45spaSC6zKHQe02mHy9HsyZTvIZRcriHsick +i+LQ8fA4yV3SgdMPQdjQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=l5FR5DR1C3aqz0zov1Ys8nTw91Q8xANVq4MQODrpOTFfH/QFVprQPQqms84BkWLyr 7O+W2C0660vVlH2iWquuA== Received: from pvc22 (pvc22.prod.google.com [10.241.209.150]) by kpbe20.cbf.corp.google.com with ESMTP id o36Me4pe017198 for ; Tue, 6 Apr 2010 15:40:04 -0700 Received: by pvc22 with SMTP id 22so311782pvc.39 for ; Tue, 06 Apr 2010 15:40:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Tue, 6 Apr 2010 15:39:44 -0700 (PDT) In-Reply-To: <4BBB68BB.4010206@lodderstedt.net> References: <4BBB68BB.4010206@lodderstedt.net> From: Marius Scurtescu Date: Tue, 6 Apr 2010 15:39:44 -0700 Received: by 10.141.90.21 with SMTP id s21mr6441882rvl.118.1270593604209; Tue, 06 Apr 2010 15:40:04 -0700 (PDT) Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Access Token Exchange Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:40:18 -0000 On Tue, Apr 6, 2010 at 10:00 AM, Torsten Lodderstedt wrote: > Hi all, > > here at Deutsche Telekom, we see the need for a flow supporting the exchange > of access tokens for one service into access tokens for another service. > > The scenarios is as follows: In the context of mobile applications, we > employ multi-layered architectures of personalized web services. The first > layer typically exposes an API optimized for the flows of a particular > application. This layer's business logic is built on top of other web > services and so on. We use self-contained bearer tokens carrying id's, > attributes and permissions. Each of the web services involed has a trust > relationship with our authorization server based on shared secrets. Every > web service requires a different token with different claims (id, > permissions, attributes) and signature (HMAC). > > The flow is as follows: > > 1) The client acquires a token for the first service eather by > username/password authentication or web-based authorization flow. > > 2) The client sends a request (including the access token) to the first web > service. > > 3) Access control and some business logic is executed based on the token > contents. Afterwards, the first service determines that it needs > to call another services (second web service) on behalf of the user. > > 4) It requests the issuance of a new token for the second service from the > authorization server based on the original token sent by the client. > > 5) The authorization server issues a new token carrying the claims need by > the second web service and digitally signs the token > with the respective shared secret. It also encrypts the token content in > order to prevent the first web service from eavesdropping the users data > intended for the second service only. > > 6) The first web service uses the token to invoke the second web service. > > ... > > Does anyone else see the need for such a flow? I think I suggested something like that on the scope thread: "Things can get even more complicated. When the user grants access for the client, the approval page should list all the scopes the client is requesting. This is the set of scopes needed by the client for *all* the API calls. Each API will need a subset of this approved, larger set. With that in mind, it would be useful to be able to down-scope access tokens when using the refresh token, this way the client can send the smallest set of scopes with each API call." In your example, instead of having the first service request a new token for the second service, step 4, I think the client should do that and pass the second token as an argument in the API call. Basically the client requests a refresh token with largest set of permissions and then it uses the refresh token flow to get lower-permission access tokens as needed. The first service can ask for a second token only if the set of permissions is a sub-set of the one it received, otherwise it has not authority to do that. Marius From atom@yahoo-inc.com Tue Apr 6 16:01:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69EE3A68A4 for ; Tue, 6 Apr 2010 16:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.902 X-Spam-Level: X-Spam-Status: No, score=-14.902 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CputZzNoYDWd for ; Tue, 6 Apr 2010 16:01:51 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id EC49C3A67E1 for ; Tue, 6 Apr 2010 16:01:51 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o36N1a4Q060991; Tue, 6 Apr 2010 16:01:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type:x-originalarrivaltime; b=LT7Nm8n2HQsEmg8RHxrysE1lzNVolWGpDYPSJmY1SLgiopd2mLcFEE8Hdp4uuapb Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 16:01:36 -0700 Received: from 10.72.244.204 ([10.72.244.204]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Tue, 6 Apr 2010 23:00:48 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 06 Apr 2010 16:00:47 -0700 From: Allen Tom To: Anthony Nadalin , "oauth@ietf.org" Message-ID: Thread-Topic: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures Thread-Index: AcrVtrKPc2+a+5PkjUWcdom/sx3EFAAC1/XgAAa6/MY= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3353414447_1105009" X-OriginalArrivalTime: 06 Apr 2010 23:01:36.0843 (UTC) FILETIME=[1C0AA9B0:01CAD5DD] Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 23:01:58 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3353414447_1105009 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Tony, I=B9m suggesting that the Service Provider determine whether its services are available via HTTPS, HTTP, or both. This is exactly how it is today. AFAIK, there are no standard interoperable APIs that use Oauth. All (or practically all) APIs that use Oauth are completely proprietary. For proprietary interfaces, it=B9s really up to the Service Provider to determine if their data and services are valuable enoug= h to justify using HTTPs. (I personally think that everything should use HTTPS, however I don=B9t think that Service Providers should be required to implement HTTPS if they don=B9t think their proprietary API requires it) I do hope that there are standard interoperable interfaces that are built o= n top of OAuth2 =AD however it=B9s up to the authors of these interfaces to determine whether SSL is required or not. The issue with specifying whether the SP should require HTTPS is very similar to the problem with specifying how the the user authenticates with the SP. Should the user have a strong password? Should the SP implement CAPTCHA or other anti-password cracking mechanisms? Maybe users should have multi-factor auth?=20 I recommend that the spec does not require HTTPS =AD this decision is really up to the Service Provider if they=B9re providing a proprietary interface. Future standard interfaces that are built on top of Oauth should determine for themselves whether or not HTTPS is required. Allen On 4/6/10 12:50 PM, "Anthony Nadalin" wrote: > I=B9m not sure if you are coming from the user or service perspective. So i= f a > user asks for HTTPS do you have to support HTTPS? If a service asks for H= TTPS > do you have to support it? Or do you just fail? > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Allen Tom > Sent: Tuesday, April 06, 2010 11:27 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] HTTPS requirement for using an Access Token without > signatures > =20 > One of the biggest differences between OAuth2 and WRAP is that OAuth2 req= uires > that Protected Resources be accessed using HTTPS if no signature is being > used. Bullet Point #2 in Section 1.2 says: >=20 > 4. Don't allow bearer tokens without either SSL and/or signatures. > While some providers may offer this ability, they should be out > of spec for doing so though technically it won't break the flows. >=20 > While I personally think that requiring SSL is a fantastic idea, and it=B9s= very > hard for me to argue against it, however.... >=20 > One of the goals for WRAP was to define a standard AuthZ interface for AP= Is > which matched what we currently have on the Web. WRAP protected APIs are > intended to be a replacement for screen scraping. >=20 > On the web, almost all websites implement Cookie Auth. Specifically, when= you > log into a website, the browser is issued a bearer token, called a Cookie= , and > the browser is able to access Protected Resources by using the Cookie as = the > credential.=20 >=20 > The WRAP access token is intended to be a direct replacement for the HTTP > Cookie. A client should be able to present its bearer token (a WRAP Acces= s > Token or an HTTP Cookie) without having to sign the request. >=20 > While I certainly think that requiring SSL would be a huge improvement in > internet security, HTTP does not require SSL, and since WRAP was intended= to > be a replacement for HTTP Cookie Auth, then OAuth2 should also not requir= e > HTTPS. >=20 > Yes, dropping the SSL requirement isn=B9t optimal, but again the intent wit= h > WRAP was to replace HTTP Cookie auth, and it should be up to the service > provider to require HTTPS when applicable. >=20 > Allen >=20 --B_3353414447_1105009 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] HTTPS requirement for using an Access Token without s= ignatures Hi Tony,

I’m suggesting that the Service Provider determine whether its servic= es are available via HTTPS, HTTP, or both.

This is exactly how it is today. AFAIK, there are no standard interoperable= APIs that use Oauth. All (or practically all) APIs that use Oauth are compl= etely proprietary. For proprietary interfaces, it’s really up to the S= ervice Provider to determine if their data and services are valuable enough = to justify using HTTPs.

(I personally think that everything should use HTTPS, however I don’t= think that Service Providers should be required to implement HTTPS if they = don’t think their proprietary API requires it)

I do hope that there are standard interoperable interfaces that are built o= n top of OAuth2 – however it’s up to the authors of these interf= aces to determine whether SSL is required or not.

The issue with specifying whether the SP should require HTTPS is very simil= ar to the problem with specifying how the the user authenticates with  = the SP.   Should the user have a strong password? Should the SP im= plement CAPTCHA or other anti-password cracking mechanisms? Maybe users shou= ld have multi-factor auth?

I recommend that the spec does not require HTTPS – this decision is r= eally up to the Service Provider if they’re providing a proprietary in= terface. Future standard interfaces that are built on top of Oauth should de= termine for themselves whether or not HTTPS is required.

Allen


On 4/6/10 12:50 PM, "Anthony Nadalin" <tonynad@microsoft.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>I’m not sure if you = are coming from the user or service perspective. So if a user asks for HTTPS= do you have to support HTTPS? If a service asks for HTTPS do you have to su= pport it? Or  do you just fail?
 

From: = oauth-bounces@ietf.org [mailto:o= auth-bounces@ietf.org] On Behalf Of Allen Tom
Sent: Tuesday, April 06, 2010 11:27 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] HTTPS requirement for using an Access Token with= out signatures
One of the biggest differences between OAuth2 and WRAP is th= at OAuth2 requires that Protected Resources be accessed using HTTPS if no si= gnature is being used. Bullet Point #2 in Section 1.2 says:

   4.  Don't allow bearer tokens without either SSL and= /or signatures.
       While some providers may offer th= is ability, they should be out
       of spec for doing so though techn= ically it won't break the flows.

While I personally think that requiring SSL is a fantastic idea, and itR= 17;s very hard for me to argue against it, however....

One of the goals for WRAP was to define a standard AuthZ interface for APIs= which matched what we currently have on the Web. WRAP protected APIs are in= tended to be a replacement for screen scraping.

On the web, almost all websites implement Cookie Auth. Specifically, when y= ou log into a website, the browser is issued a bearer token, called a Cookie= , and the browser is able to access Protected Resources by using the Cookie = as the credential.

The WRAP access token is intended to be a direct replacement for the HTTP C= ookie. A client should be able to present its bearer token (a WRAP Access To= ken or an HTTP Cookie) without having to sign the request.

While I certainly think that requiring SSL would be a huge improvement in i= nternet security, HTTP does not require SSL, and since WRAP was intended to = be a replacement for HTTP Cookie Auth, then OAuth2 should also not require H= TTPS.

Yes, dropping the SSL requirement isn’t optimal, but again the intent= with WRAP was to replace HTTP Cookie auth, and it should be up to the servi= ce provider to require HTTPS when applicable.

Allen

--B_3353414447_1105009-- From mscurtescu@google.com Tue Apr 6 16:07:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6010C28C101 for ; Tue, 6 Apr 2010 16:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.648 X-Spam-Level: X-Spam-Status: No, score=-99.648 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIRuXptaksbC for ; Tue, 6 Apr 2010 16:07:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id AB8763A6905 for ; Tue, 6 Apr 2010 16:07:07 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id o36N72gr026459 for ; Wed, 7 Apr 2010 01:07:03 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270595224; bh=NuJn1tLlzn6HE005lgEHBS8U5BM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=J98vz+NrFXn9lKbVLRvhfxJOVcH3PZ6VgxcSGe905/VFlGzEArhpjQfQgIV3Wt1Nx SrDszA+pSefpryHYwr0Iw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=s0ebZtum3m5Qobce0bALtDmzM29vkopFkA63h6DLdB5eAVVVZWMaCY0Ca9LEo8MxC IsfMxVN5GREdVBAkqapOA== Received: from pwj10 (pwj10.prod.google.com [10.241.219.74]) by kpbe15.cbf.corp.google.com with ESMTP id o36N70Hq004899 for ; Tue, 6 Apr 2010 16:07:01 -0700 Received: by pwj10 with SMTP id 10so414705pwj.40 for ; Tue, 06 Apr 2010 16:07:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.18 with HTTP; Tue, 6 Apr 2010 16:06:40 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 6 Apr 2010 16:06:40 -0700 Received: by 10.140.251.20 with SMTP id y20mr6203109rvh.206.1270595220170; Tue, 06 Apr 2010 16:07:00 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/mixed; boundary=000e0cd11250c06a6104839980f5 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 23:07:56 -0000 --000e0cd11250c06a6104839980f5 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 5, 2010 at 11:56 PM, Eran Hammer-Lahav wrote: > Hey Marius, > > Detailed replies inline but I think most of these can be answered by the > fact that we are still getting outside feedback that says OAuth is still > complicated and has too many options / things left open to each > implementation. > > My goal with any limitation added was to increase interop. If something > doesn't increase inteop, I agree we should remove it. I'm all for simplification. Do we have a clear definition for interop? I think it is clear that 100% interop cannot be achieved in all areas. > On 4/2/10 11:21 AM, "Marius Scurtescu" wrote: > >> 1. Only one endpoint. While I think collapsing the access token and >> refresh token URLs into one URL was a good think, keeping the user >> authorization as a separate URL could be beneficial. I think there >> should be 2 endpoints defined: access token and user authorization. >> Calls to the access token endpoint are alway direct calls and >> restricted to HTTPS and POST, and with many frameworks this can be >> enforced through configuration. The user authorization endpoint is >> always accessed with a browser. > > I'm trying to simplify configuration and reduce the need for complex > discovery. I am not sure what the benefits of keeping them different are. > Can you elaborate? Sure. Constraints for endpoints: access token URL: HTTPS and POST only, no user user authentication URL: HTTP or HTTPS, GET or POST, authenticated user In many cases the above constraints can be enforced with configuration that sits in front of the controllers implementing these endpoints. For example, Apache config can enforce SSL and POST. Same can be done in a Java filter. Also a Java filter can enforce that only authenticated users hit the endpoint, it can redirect to a login page if needed. By keeping two different endpoints all of the above is much simpler. Nothing prevents an authz server to collapse these two into one endpoint. >> 2. Section 2.1: "The authorization endpoint advertised by the server >> MUST NOT include a query or fragment components as defined by >> [RFC3986] section 3." Why do we disallow query parameters? If we want >> to enforce strict matching of callback URLs maybe we should just >> demand that. > > I don't like having both custom query and a state parameter. If servers have > to accommodate custom queries, then we might as well drop the special state > parameter since clients can just make up whatever they want. I opted to use > the state parameter because it makes pre-registering URIs easier, and it > doesn't cause parameter namepsace conflicts (which is still an open issue). I think I got mixed up a bit. The authorization server endpoints should be allowed to have query parameters. No state is passed through these, and also no matching done against them. Registered callback URLs for clients should also be allowed to have query parameters. If strict matching is enforced, at least for the query part, then no state that can be passed, so they have to use the state parameter. Parameter namespace can be an issue, one more reason to keep the prefix :-) >> 3. Section 2.2: "The values of the request and response parameters >> defined in this section MUST only contain the following characters". I >> asked in another thread what is the reason behind this limitation. Why >> not any UTF-8 string? > > I marked this as an open issue. We need to figure out signatures first to > deal with this. If the signature flow will be simple enough, we can/should > drop this limitation. If we end up keeping this limitation, how do you see clients and authz servers dealing with this requirement? Don't you think this will lead to real interop issues? I think it is much better to not rely on this limitation at all when looking at signatures. >> 4. Section 2.4.1.1: "The client directs the end user to the >> constructed URI using an HTTP redirection response, or by other means >> available to it via the end user's user-agent. The request MUST use >> the HTTP "GET" method." Why do we enforce GET? > > First, to stay consistent across a redirection (3xx) and something else > (such as a button press with a form). Yes, dealing with redirects could be an issue. Not sure how well supported are POSTs and redirects. But on the other hand, I think it is OK to require authz servers to support POST. > Second, we need to guarantee interop > which means at a minimum we must require the server to accept GET. I don't > think making this a server requirement instead of a client one that > beneficial. It think we should rather require servers to support POST, that seems the more difficult case. >> 5. Section 2.4.2. Web Client Flow combines both rich app and >> JavaScript flows. It think the two flows should be treated separately. >> >> For the rich apps the flow should include a verification code step, >> similar to Web Client Flow. Also, in this case the callback URL should >> be optional and if not present the authorization server must display a >> page with instructions and a special title. >> >> For the JavaScript flow, the presence of an empty fragment in the >> callback URL is a signal that the response should be put there? Can we >> make it mandatory that the response always goes to the fragment? It is >> not defined how is the response supposed to be encoded into the >> fragment. I assume that also URL encoded, but it should be specified. > > Didn't get to it. Care to suggest text or point me where to copy it from? See "6.3. Rich App Profile" in attached draft-hardt-oauth-01. Marius --000e0cd11250c06a6104839980f5 Content-Type: text/html; charset=US-ASCII; name="draft-hardt-oauth-wrap-01.html" Content-Disposition: attachment; filename="draft-hardt-oauth-wrap-01.html" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g7pbj8vi0 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sIGxhbmc9 ImVuIj48aGVhZD48dGl0bGU+T0F1dGggV2ViIFJlc291cmNlIEF1dGhvcml6YXRpb24KICAgIFBy b2ZpbGVzPC90aXRsZT4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0 ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPgo8bWV0YSBuYW1lPSJkZXNjcmlwdGlvbiIgY29udGVu dD0iT0F1dGggV2ViIFJlc291cmNlIEF1dGhvcml6YXRpb24KICAgIFByb2ZpbGVzIj4KPG1ldGEg bmFtZT0ia2V5d29yZHMiIGNvbnRlbnQ9InRlbXBsYXRlIj4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9y IiBjb250ZW50PSJ4bWwycmZjIHYxLjM0IChodHRwOi8veG1sLnJlc291cmNlLm9yZy8pIj4KPHN0 eWxlIHR5cGU9J3RleHQvY3NzJz48IS0tCiAgICAgICAgYm9keSB7CiAgICAgICAgICAgICAgICBm b250LWZhbWlseTogdmVyZGFuYSwgY2hhcmNvYWwsIGhlbHZldGljYSwgYXJpYWwsIHNhbnMtc2Vy aWY7CiAgICAgICAgICAgICAgICBmb250LXNpemU6IHNtYWxsOyBjb2xvcjogIzAwMDsgYmFja2dy b3VuZC1jb2xvcjogI0ZGRjsKICAgICAgICAgICAgICAgIG1hcmdpbjogMmVtOwogICAgICAgIH0K ICAgICAgICBoMSwgaDIsIGgzLCBoNCwgaDUsIGg2IHsKICAgICAgICAgICAgICAgIGZvbnQtZmFt aWx5OiBoZWx2ZXRpY2EsIG1vbmFjbywgIk1TIFNhbnMgU2VyaWYiLCBhcmlhbCwgc2Fucy1zZXJp ZjsKICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOyBmb250LXN0eWxlOiBub3JtYWw7 CiAgICAgICAgfQogICAgICAgIGgxIHsgY29sb3I6ICM5MDA7IGJhY2tncm91bmQtY29sb3I6IHRy YW5zcGFyZW50OyB0ZXh0LWFsaWduOiByaWdodDsgfQogICAgICAgIGgzIHsgY29sb3I6ICMzMzM7 IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyB9CgogICAgICAgIHRkLlJGQ2J1ZyB7CiAg ICAgICAgICAgICAgICBmb250LXNpemU6IHgtc21hbGw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsK ICAgICAgICAgICAgICAgIHdpZHRoOiAzMHB4OyBoZWlnaHQ6IDMwcHg7IHBhZGRpbmctdG9wOiAy cHg7CiAgICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBqdXN0aWZ5OyB2ZXJ0aWNhbC1hbGlnbjog bWlkZGxlOwogICAgICAgICAgICAgICAgYmFja2dyb3VuZC1jb2xvcjogIzAwMDsKICAgICAgICB9 CiAgICAgICAgdGQuUkZDYnVnIHNwYW4uUkZDIHsKICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5 OiBtb25hY28sIGNoYXJjb2FsLCBnZW5ldmEsICJNUyBTYW5zIFNlcmlmIiwgaGVsdmV0aWNhLCB2 ZXJkYW5hLCBzYW5zLXNlcmlmOwogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGNv bG9yOiAjNjY2OwogICAgICAgIH0KICAgICAgICB0ZC5SRkNidWcgc3Bhbi5ob3RUZXh0IHsKICAg ICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBjaGFyY29hbCwgbW9uYWNvLCBnZW5ldmEsICJNUyBT YW5zIFNlcmlmIiwgaGVsdmV0aWNhLCB2ZXJkYW5hLCBzYW5zLXNlcmlmOwogICAgICAgICAgICAg ICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsgdGV4dC1hbGlnbjogY2VudGVyOyBjb2xvcjogI0ZGRjsK ICAgICAgICB9CgogICAgICAgIHRhYmxlLlRPQ2J1ZyB7IHdpZHRoOiAzMHB4OyBoZWlnaHQ6IDE1 cHg7IH0KICAgICAgICB0ZC5UT0NidWcgewogICAgICAgICAgICAgICAgdGV4dC1hbGlnbjogY2Vu dGVyOyB3aWR0aDogMzBweDsgaGVpZ2h0OiAxNXB4OwogICAgICAgICAgICAgICAgY29sb3I6ICNG RkY7IGJhY2tncm91bmQtY29sb3I6ICM5MDA7CiAgICAgICAgfQogICAgICAgIHRkLlRPQ2J1ZyBh IHsKICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBtb25hY28sIGNoYXJjb2FsLCBnZW5ldmEs ICJNUyBTYW5zIFNlcmlmIiwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmOwogICAgICAgICAgICAgICAg Zm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc2l6ZTogeC1zbWFsbDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOwogICAgICAgICAgICAgICAgY29sb3I6ICNGRkY7IGJhY2tncm91bmQtY29sb3I6IHRyYW5z cGFyZW50OwogICAgICAgIH0KCiAgICAgICAgdGQuaGVhZGVyIHsKICAgICAgICAgICAgICAgIGZv bnQtZmFtaWx5OiBhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IHgtc21h bGw7CiAgICAgICAgICAgICAgICB2ZXJ0aWNhbC1hbGlnbjogdG9wOyB3aWR0aDogMzMlOwogICAg ICAgICAgICAgICAgY29sb3I6ICNGRkY7IGJhY2tncm91bmQtY29sb3I6ICM2NjY7CiAgICAgICAg fQogICAgICAgIHRkLmF1dGhvciB7IGZvbnQtd2VpZ2h0OiBib2xkOyBmb250LXNpemU6IHgtc21h bGw7IG1hcmdpbi1sZWZ0OiA0ZW07IH0KICAgICAgICB0ZC5hdXRob3ItdGV4dCB7IGZvbnQtc2l6 ZTogeC1zbWFsbDsgfQoKICAgICAgICAvKiBpbmZvIGNvZGUgZnJvbSBTYW50YUtsYXVzcyBhdCBo dHRwOi8vd3d3Lm1hZGFib3V0c3R5bGUuY29tL3Rvb2x0aXAyLmh0bWwgKi8KICAgICAgICBhLmlu Zm8gewogICAgICAgICAgICAgICAgLyogVGhpcyBpcyB0aGUga2V5LiAqLwogICAgICAgICAgICAg ICAgcG9zaXRpb246IHJlbGF0aXZlOwogICAgICAgICAgICAgICAgei1pbmRleDogMjQ7CiAgICAg ICAgICAgICAgICB0ZXh0LWRlY29yYXRpb246IG5vbmU7CiAgICAgICAgfQogICAgICAgIGEuaW5m bzpob3ZlciB7CiAgICAgICAgICAgICAgICB6LWluZGV4OiAyNTsKICAgICAgICAgICAgICAgIGNv bG9yOiAjRkZGOyBiYWNrZ3JvdW5kLWNvbG9yOiAjOTAwOwogICAgICAgIH0KICAgICAgICBhLmlu Zm8gc3BhbiB7IGRpc3BsYXk6IG5vbmU7IH0KICAgICAgICBhLmluZm86aG92ZXIgc3Bhbi5pbmZv IHsKICAgICAgICAgICAgICAgIC8qIFRoZSBzcGFuIHdpbGwgZGlzcGxheSBqdXN0IG9uIDpob3Zl ciBzdGF0ZS4gKi8KICAgICAgICAgICAgICAgIGRpc3BsYXk6IGJsb2NrOwogICAgICAgICAgICAg ICAgcG9zaXRpb246IGFic29sdXRlOwogICAgICAgICAgICAgICAgZm9udC1zaXplOiBzbWFsbGVy OwogICAgICAgICAgICAgICAgdG9wOiAyZW07IGxlZnQ6IC01ZW07IHdpZHRoOiAxNWVtOwogICAg ICAgICAgICAgICAgcGFkZGluZzogMnB4OyBib3JkZXI6IDFweCBzb2xpZCAjMzMzOwogICAgICAg ICAgICAgICAgY29sb3I6ICM5MDA7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7CiAgICAgICAgICAg ICAgICB0ZXh0LWFsaWduOiBsZWZ0OwogICAgICAgIH0KCiAgICAgICAgYSB7IGZvbnQtd2VpZ2h0 OiBib2xkOyB9CiAgICAgICAgYTpsaW5rICAgIHsgY29sb3I6ICM5MDA7IGJhY2tncm91bmQtY29s b3I6IHRyYW5zcGFyZW50OyB9CiAgICAgICAgYTp2aXNpdGVkIHsgY29sb3I6ICM2MzM7IGJhY2tn cm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyB9CiAgICAgICAgYTphY3RpdmUgIHsgY29sb3I6ICM2 MzM7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyB9CgogICAgICAgIHAgeyBtYXJnaW4t bGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQogICAgICAgIHAuY29weXJpZ2h0IHsgZm9u dC1zaXplOiB4LXNtYWxsOyB9CiAgICAgICAgcC50b2MgeyBmb250LXNpemU6IHNtYWxsOyBmb250 LXdlaWdodDogYm9sZDsgbWFyZ2luLWxlZnQ6IDNlbTsgfQogICAgICAgIHRhYmxlLnRvYyB7IG1h cmdpbjogMCAwIDAgM2VtOyBwYWRkaW5nOiAwOyBib3JkZXI6IDA7IHZlcnRpY2FsLWFsaWduOiB0 ZXh0LXRvcDsgfQogICAgICAgIHRkLnRvYyB7IGZvbnQtc2l6ZTogc21hbGw7IGZvbnQtd2VpZ2h0 OiBib2xkOyB2ZXJ0aWNhbC1hbGlnbjogdGV4dC10b3A7IH0KCiAgICAgICAgb2wudGV4dCB7IG1h cmdpbi1sZWZ0OiAyZW07IG1hcmdpbi1yaWdodDogMmVtOyB9CiAgICAgICAgdWwudGV4dCB7IG1h cmdpbi1sZWZ0OiAyZW07IG1hcmdpbi1yaWdodDogMmVtOyB9CiAgICAgICAgbGkgICAgICB7IG1h cmdpbi1sZWZ0OiAzZW07IH0KCiAgICAgICAgLyogUkZDLTI2MjkgPHNwYW54PnMgYW5kIDxhcnR3 b3JrPnMuICovCiAgICAgICAgZW0gICAgIHsgZm9udC1zdHlsZTogaXRhbGljOyB9CiAgICAgICAg c3Ryb25nIHsgZm9udC13ZWlnaHQ6IGJvbGQ7IH0KICAgICAgICBkZm4gICAgeyBmb250LXdlaWdo dDogYm9sZDsgZm9udC1zdHlsZTogbm9ybWFsOyB9CiAgICAgICAgY2l0ZSAgIHsgZm9udC13ZWln aHQ6IG5vcm1hbDsgZm9udC1zdHlsZTogbm9ybWFsOyB9CiAgICAgICAgdHQgICAgIHsgY29sb3I6 ICMwMzY7IH0KICAgICAgICB0dCwgcHJlLCBwcmUgZGZuLCBwcmUgZW0sIHByZSBjaXRlLCBwcmUg c3BhbiB7CiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IiwgQ291cmll ciwgbW9ub3NwYWNlOyBmb250LXNpemU6IHNtYWxsOwogICAgICAgIH0KICAgICAgICBwcmUgewog ICAgICAgICAgICAgICAgdGV4dC1hbGlnbjogbGVmdDsgcGFkZGluZzogNHB4OwogICAgICAgICAg ICAgICAgY29sb3I6ICMwMDA7IGJhY2tncm91bmQtY29sb3I6ICNDQ0M7CiAgICAgICAgfQogICAg ICAgIHByZSBkZm4gIHsgY29sb3I6ICM5MDA7IH0KICAgICAgICBwcmUgZW0gICB7IGNvbG9yOiAj NjZGOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZDOyBmb250LXdlaWdodDogbm9ybWFsOyB9CiAgICAg ICAgcHJlIC5rZXkgeyBjb2xvcjogIzMzQzsgZm9udC13ZWlnaHQ6IGJvbGQ7IH0KICAgICAgICBw cmUgLmlkICB7IGNvbG9yOiAjOTAwOyB9CiAgICAgICAgcHJlIC5zdHIgeyBjb2xvcjogIzAwMDsg YmFja2dyb3VuZC1jb2xvcjogI0NGRjsgfQogICAgICAgIHByZSAudmFsIHsgY29sb3I6ICMwNjY7 IH0KICAgICAgICBwcmUgLnJlcCB7IGNvbG9yOiAjOTA5OyB9CiAgICAgICAgcHJlIC5vdGggeyBj b2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xvcjogI0ZDRjsgfQogICAgICAgIHByZSAuZXJyIHsg YmFja2dyb3VuZC1jb2xvcjogI0ZDQzsgfQoKICAgICAgICAvKiBSRkMtMjYyOSA8dGV4dHRhYmxl PnMuICovCiAgICAgICAgdGFibGUuYWxsLCB0YWJsZS5mdWxsLCB0YWJsZS5oZWFkZXJzLCB0YWJs ZS5ub25lIHsKICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogc21hbGw7IHRleHQtYWxpZ246IGNl bnRlcjsgYm9yZGVyLXdpZHRoOiAycHg7CiAgICAgICAgICAgICAgICB2ZXJ0aWNhbC1hbGlnbjog dG9wOyBib3JkZXItY29sbGFwc2U6IGNvbGxhcHNlOwogICAgICAgIH0KICAgICAgICB0YWJsZS5h bGwsIHRhYmxlLmZ1bGwgeyBib3JkZXItc3R5bGU6IHNvbGlkOyBib3JkZXItY29sb3I6IGJsYWNr OyB9CiAgICAgICAgdGFibGUuaGVhZGVycywgdGFibGUubm9uZSB7IGJvcmRlci1zdHlsZTogbm9u ZTsgfQogICAgICAgIHRoIHsKICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOyBib3Jk ZXItY29sb3I6IGJsYWNrOwogICAgICAgICAgICAgICAgYm9yZGVyLXdpZHRoOiAycHggMnB4IDNw eCAycHg7CiAgICAgICAgfQogICAgICAgIHRhYmxlLmFsbCB0aCwgdGFibGUuZnVsbCB0aCB7IGJv cmRlci1zdHlsZTogc29saWQ7IH0KICAgICAgICB0YWJsZS5oZWFkZXJzIHRoIHsgYm9yZGVyLXN0 eWxlOiBub25lIG5vbmUgc29saWQgbm9uZTsgfQogICAgICAgIHRhYmxlLm5vbmUgdGggeyBib3Jk ZXItc3R5bGU6IG5vbmU7IH0KICAgICAgICB0YWJsZS5hbGwgdGQgewogICAgICAgICAgICAgICAg Ym9yZGVyLXN0eWxlOiBzb2xpZDsgYm9yZGVyLWNvbG9yOiAjMzMzOwogICAgICAgICAgICAgICAg Ym9yZGVyLXdpZHRoOiAxcHggMnB4OwogICAgICAgIH0KICAgICAgICB0YWJsZS5mdWxsIHRkLCB0 YWJsZS5oZWFkZXJzIHRkLCB0YWJsZS5ub25lIHRkIHsgYm9yZGVyLXN0eWxlOiBub25lOyB9Cgog ICAgICAgIGhyIHsgaGVpZ2h0OiAxcHg7IH0KICAgICAgICBoci5pbnNlcnQgewogICAgICAgICAg ICAgICAgd2lkdGg6IDgwJTsgYm9yZGVyLXN0eWxlOiBub25lOyBib3JkZXItd2lkdGg6IDA7CiAg ICAgICAgICAgICAgICBjb2xvcjogI0NDQzsgYmFja2dyb3VuZC1jb2xvcjogI0NDQzsKICAgICAg ICB9Ci0tPjwvc3R5bGU+CjwvaGVhZD4KPGJvZHk+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgd2lkdGg9IjY2JSIg Ym9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0cj48dGQ+PHRhYmxl IHN1bW1hcnk9ImxheW91dCIgd2lkdGg9IjEwMCUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjIi IGNlbGxzcGFjaW5nPSIxIj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5JbnRlcm5ldCBFbmdpbmVl cmluZyBUYXNrIEZvcmNlPC90ZD48dGQgY2xhc3M9ImhlYWRlciI+RC4gSGFyZHQsIEVkLjwvdGQ+ PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5JbnRlcm5ldC1EcmFmdDwvdGQ+PHRkIGNsYXNz PSJoZWFkZXIiPk1pY3Jvc29mdDwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5JbnRl bmRlZCBzdGF0dXM6IEluZm9ybWF0aW9uYWw8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5BLiBUb208 L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+RXhwaXJlczogSnVseSAxOSwgMjAxMDwv dGQ+PHRkIGNsYXNzPSJoZWFkZXIiPllhaG9vITwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVh ZGVyIj4mbmJzcDs8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5CLiBFYXRvbjwvdGQ+PC90cj4KPHRy Pjx0ZCBjbGFzcz0iaGVhZGVyIj4mbmJzcDs8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5Hb29nbGU8 L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9Imhl YWRlciI+WS4gR29sYW5kPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwv dGQ+PHRkIGNsYXNzPSJoZWFkZXIiPk1pY3Jvc29mdDwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0i aGVhZGVyIj4mbmJzcDs8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5KYW51YXJ5IDE1LCAyMDEwPC90 ZD48L3RyPgo8L3RhYmxlPjwvdGQ+PC90cj48L3RhYmxlPgo8aDE+PGJyIC8+T0F1dGggV2ViIFJl c291cmNlIEF1dGhvcml6YXRpb24KICAgIFByb2ZpbGVzPGJyIC8+ZHJhZnQtaGFyZHQtb2F1dGgt MDE8L2gxPgoKPGgzPkFic3RyYWN0PC9oMz4KCjxwPlRoZSBPQXV0aCBXZWIgUmVzb3VyY2UgQXV0 aG9yaXphdGlvbiBQcm9maWxlcyAoT0F1dGggV1JBUCkgYWxsb3cgYQogICAgICBzZXJ2ZXIgaG9z dGluZyBhIFByb3RlY3RlZCBSZXNvdXJjZSB0byBkZWxlZ2F0ZSBhdXRob3JpemF0aW9uIHRvIG9u ZSBvcgogICAgICBtb3JlIGF1dGhvcml0aWVzLiBBbiBhcHBsaWNhdGlvbiAoQ2xpZW50KSBhY2Nl c3NlcyB0aGUgUHJvdGVjdGVkCiAgICAgIFJlc291cmNlIGJ5IHByZXNlbnRpbmcgYSBzaG9ydCBs aXZlZCwgb3BhcXVlLCBiZWFyZXIgdG9rZW4gKEFjY2VzcwogICAgICBUb2tlbikgb2J0YWluZWQg ZnJvbSBhbiBhdXRob3JpdHkgKEF1dGhvcml6YXRpb24gU2VydmVyKS4gVGhlcmUgYXJlCiAgICAg IFByb2ZpbGVzIGZvciBob3cgYSBDbGllbnQgbWF5IG9idGFpbiBhbiBBY2Nlc3MgVG9rZW4gd2hl biBhY3RpbmcKICAgICAgYXV0b25vbW91c2x5IG9yIG9uIGJlaGFsZiBvZiBhIFVzZXIuCjwvcD4K PGgzPlN0YXR1cyBvZiB0aGlzIE1lbW88L2gzPgo8cD4KVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBz dWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsCmNvbmZvcm1hbmNlIHdpdGggdGhlIHByb3Zpc2lvbnMg b2YgQkNQJm5ic3A7NzggYW5kIEJDUCZuYnNwOzc5LjwvcD4KPHA+CkludGVybmV0LURyYWZ0cyBh cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nClRhc2sgRm9y Y2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuCk5vdGUgdGhhdCBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcwpJbnRl cm5ldC1EcmFmdHMuPC9wPgo8cD4KSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMg dmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCmFuZCBtYXkgYmUgdXBkYXRlZCwgcmVw bGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55IHRpbWUuCkl0IGlz IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJp YWwgb3IgdG8gY2l0ZQp0aGVtIG90aGVyIHRoYW4gYXMgJmxkcXVvO3dvcmsgaW4gcHJvZ3Jlc3Mu JnJkcXVvOzwvcD4KPHA+ClRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBi ZSBhY2Nlc3NlZCBhdAo8YSBocmVmPSdodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3Ry YWN0cy50eHQnPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dDwvYT4u PC9wPgo8cD4KVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNh biBiZSBhY2Nlc3NlZCBhdAo8YSBocmVmPSdodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s Jz5odHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPC9hPi48L3A+CjxwPgpUaGlzIEludGVy bmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEp1bHkgMTksIDIwMTAuPC9wPgoKPGgzPkNvcHlyaWdo dCBOb3RpY2U8L2gzPgo8cD4KQ29weXJpZ2h0IChjKSAyMDEwIElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCmRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJl c2VydmVkLjwvcD4KPHA+ClRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRo ZSBJRVRGIFRydXN0J3MgTGVnYWwKUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50 cyBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCAo aHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKS4KUGxlYXNlIHJldmlldyB0aGVz ZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIKcmlnaHRzIGFuZCBy ZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuPC9wPgo8YSBuYW1lPSJ0 b2MiPjwvYT48YnIgLz48aHIgLz4KPGgzPlRhYmxlIG9mIENvbnRlbnRzPC9oMz4KPHAgY2xhc3M9 InRvYyI+CjxhIGhyZWY9IiNhbmNob3IxIj4xLjwvYT4mbmJzcDsKT3ZlcnZpZXc8YnIgLz4KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjIiPjEuMS48L2E+Jm5ic3A7CkFj Y2Vzc2luZyBhIFByb3RlY3RlZCBSZXNvdXJjZTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YSBocmVmPSIjYW5jaG9yMyI+MS4yLjwvYT4mbmJzcDsKQXV0b25vbW91cyBDbGllbnQgUHJv ZmlsZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjQiPjEu My48L2E+Jm5ic3A7ClVzZXIgRGVsZWdhdGlvbiBQcm9maWxlczxiciAvPgo8YSBocmVmPSIjYW5j aG9yNSI+Mi48L2E+Jm5ic3A7ClJlcXVpcmVtZW50cyBMYW5ndWFnZTxiciAvPgo8YSBocmVmPSIj YW5jaG9yNiI+My48L2E+Jm5ic3A7CkRlZmluaXRpb25zPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9IiNhbmNob3I3Ij4zLjEuPC9hPiZuYnNwOwpVUkxzPGJyIC8+CjxhIGhy ZWY9IiNQcm90ZWN0ZWRSZXNvdXJjZSI+NC48L2E+Jm5ic3A7CkFjY2Vzc2luZyBhIFByb3RlY3Rl ZCBSZXNvdXJjZTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9y OCI+NC4xLjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9IiNhbmNob3I5Ij40LjIuPC9hPiZuYnNwOwpBY3F1aXJpbmcgYW4gQWNjZXNz IFRva2VuPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxMCI+ NC4zLjwvYT4mbmJzcDsKQ2xpZW50IENhbGxzIFByb3RlY3RlZCBSZXNvdXJjZSBVc2luZyBIVFRQ IEhlYWRlcjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTEi PjQuNC48L2E+Jm5ic3A7CkNsaWVudCBDYWxscyBQcm90ZWN0ZWQgUmVzb3VyY2UgVXNpbmcgVVJM IFF1ZXJ5IFBhcmFtZXRlcjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIj YW5jaG9yMTIiPjQuNS48L2E+Jm5ic3A7CkNsaWVudCBDYWxscyBQcm90ZWN0ZWQgUmVzb3VyY2Ug VXNpbmcgUG9zdCBQYXJhbWV0ZXI8YnIgLz4KPGEgaHJlZj0iI2F1dG9ub21vdXMucHJvZmlsZXMi PjUuPC9hPiZuYnNwOwpBY3F1aXJpbmcgYW4gQWNjZXNzIFRva2VuOiBBdXRvbm9tb3VzIENsaWVu dCBQcm9maWxlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjcDEiPjUu MS48L2E+Jm5ic3A7CkNsaWVudCBBY2NvdW50IGFuZCBQYXNzd29yZCBQcm9maWxlPGJyIC8+CiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNh bmNob3IxMyI+NS4xLjEuPC9hPiZuYnNwOwpQcm92aXNpb25pbmc8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3AxcmVxdWVzdCI+ NS4xLjIuPC9hPiZuYnNwOwpDbGllbnQgUmVxdWVzdHMgQWNjZXNzIFRva2VuPGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNo b3IxNCI+NS4xLjMuPC9hPiZuYnNwOwpTdWNjZXNzZnVsIEFjY2VzcyBUb2tlbiBSZXNwb25zZSBm cm9tIEF1dGhvcml6YXRpb24gIFNlcnZlcjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTUiPjUuMS40LjwvYT4mbmJz cDsKVW5zdWNjZXNzZnVsIEFjY2VzcyBUb2tlbiBSZXNwb25zZSBmcm9tIEF1dGhvcml6YXRpb24g U2VydmVyPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9IiNhbmNob3IxNiI+NS4xLjUuPC9hPiZuYnNwOwpDbGllbnQgUmVmcmVzaGVz IEFjY2VzcyBUb2tlbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjcDIi PjUuMi48L2E+Jm5ic3A7CkFzc2VydGlvbiBQcm9maWxlPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxNyI+NS4yLjEu PC9hPiZuYnNwOwpQcm92aXNpb25pbmc8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3AyLmFzc2VydGlvbiI+NS4yLjIuPC9hPiZu YnNwOwpDbGllbnQgT2J0YWlucyBBc3NlcnRpb248YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3AyLnJlcXVlc3QiPjUuMi4zLjwv YT4mbmJzcDsKQ2xpZW50IFJlcXVlc3RzIEFjY2VzcyBUb2tlbjxiciAvPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTgiPjUu Mi40LjwvYT4mbmJzcDsKU3VjY2Vzc2Z1bCBBY2Nlc3MgVG9rZW4gUmVzcG9uc2UgZnJvbSBBdXRo b3JpemF0aW9uIFNlcnZlcjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTkiPjUuMi41LjwvYT4mbmJzcDsKVW5zdWNj ZXNzZnVsIEFjY2VzcyBUb2tlbiBSZXNwb25zZSBmcm9tIEF1dGhvcml6YXRpb24gU2VydmVyPGJy IC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9IiNhbmNob3IyMCI+NS4yLjYuPC9hPiZuYnNwOwpDbGllbnQgUmVmcmVzaGVzIEFjY2VzcyBU b2tlbjxiciAvPgo8YSBocmVmPSIjdXNlci5wcm9maWxlcyI+Ni48L2E+Jm5ic3A7CkFjcXVpcmlu ZyBhbiBBY2Nlc3MgVG9rZW46IFVzZXIgRGVsZWdhdGlvbiBQcm9maWxlczxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjcDMiPjYuMS48L2E+Jm5ic3A7ClVzZXJuYW1lIGFu ZCBQYXNzd29yZCBQcm9maWxlPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IyMSI+Ni4xLjEuPC9hPiZuYnNwOwpQcm92 aXNpb25pbmc8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0iI3AzLnBhc3N3b3JkIj42LjEuMi48L2E+Jm5ic3A7CkNsaWVudCBPYnRh aW5zIFVzZXJuYW1lIGFuZCAgICAgIFBhc3N3b3JkPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNwMy5yZXF1ZXN0Ij42LjEuMy48 L2E+Jm5ic3A7CkNsaWVudCBSZXF1ZXN0cyBBY2Nlc3MgVG9rZW48YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjIyIj42 LjEuNC48L2E+Jm5ic3A7ClN1Y2Nlc3NmdWwgQWNjZXNzIFRva2VuIFJlc3BvbnNlIGZyb20gQXV0 aG9yaXphdGlvbiBTZXJ2ZXI8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjIzIj42LjEuNS48L2E+Jm5ic3A7ClVuc3Vj Y2Vzc2Z1bCBBY2Nlc3MgVG9rZW4gUmVzcG9uc2UgZnJvbSBBdXRob3JpemF0aW9uIFNlcnZlcjxi ciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYW5jaG9yMjQiPjYuMS42LjwvYT4mbmJzcDsKVmVyaWZpY2F0aW9uIFVSTCBSZXNwb25z ZSBmcm9tIEF1dGhvcml6YXRpb24gU2VydmVyPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IyNSI+Ni4xLjcuPC9hPiZu YnNwOwpDQVBUQ0hBIFJlc3BvbnNlIGZyb20gQXV0aG9yaXphdGlvbiBTZXJ2ZXI8YnIgLz4KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2Fu Y2hvcjI2Ij42LjEuOC48L2E+Jm5ic3A7CkNsaWVudCBSZWZyZXNoZXMgQWNjZXNzIFRva2VuPGJy IC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9IiNhbmNob3IyNyI+Ni4xLjkuPC9hPiZuYnNwOwpTdWNjZXNzZnVsIEFjY2VzcyBUb2tlbiBS ZWZyZXNoPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9IiNhbmNob3IyOCI+Ni4xLjEwLjwvYT4mbmJzcDsKVW5zdWNjZXNzZnVsIEFj Y2VzcyBUb2tlbiBSZWZyZXNoPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9 IiNwNCI+Ni4yLjwvYT4mbmJzcDsKV2ViIEFwcCBQcm9maWxlPGJyIC8+CiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IyOSI+Ni4y LjEuPC9hPiZuYnNwOwpQcm92aXNpb25pbmc8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3A0LmF1dGhvcml6YXRpb24iPjYuMi4y LjwvYT4mbmJzcDsKQ2xpZW50IERpcmVjdHMgdGhlIFVzZXIgdG8gdGhlICAgICAgQXV0aG9yaXph dGlvbiBTZXJ2ZXI8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjMwIj42LjIuMy48L2E+Jm5ic3A7CkF1dGhvcml6YXRp b24gU2VydmVyIENvbmZpcm1zIEF1dGhvcml6YXRpb24gUmVxdWVzdCB3aXRoIFVzZXI8YnIgLz4K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0i I2FuY2hvcjMxIj42LjIuNC48L2E+Jm5ic3A7CkF1dGhvcml6YXRpb24gU2VydmVyIERpcmVjdHMg VXNlciBiYWNrIHRvIHRoZSBDbGllbnQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3A0LnJlcXVlc3QiPjYuMi41LjwvYT4mbmJz cDsKQ2xpZW50IFJlcXVlc3RzIEFjY2VzcyBUb2tlbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMzIiPjYuMi42Ljwv YT4mbmJzcDsKU3VjY2Vzc2Z1bCBBY2Nlc3MgVG9rZW4gUmVzcG9uc2UgZnJvbSBBdXRob3JpemF0 aW9uIFNlcnZlcjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMzMiPjYuMi43LjwvYT4mbmJzcDsKVW5zdWNjZXNzZnVs IEFjY2VzcyBUb2tlbiBSZXNwb25zZSBmcm9tIEF1dGhvcml6YXRpb24gU2VydmVyPGJyIC8+CiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNh bmNob3IzNCI+Ni4yLjguPC9hPiZuYnNwOwpDbGllbnQgUmVmcmVzaGVzIEFjY2VzcyBUb2tlbjxi ciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYW5jaG9yMzUiPjYuMi45LjwvYT4mbmJzcDsKU3VjY2Vzc2Z1bCBBY2Nlc3MgVG9rZW4g UmVmcmVzaDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8YSBocmVmPSIjYW5jaG9yMzYiPjYuMi4xMC48L2E+Jm5ic3A7ClVuc3VjY2Vzc2Z1bCBB Y2Nlc3MgVG9rZW4gUmVmcmVzaDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSIjcDUiPjYuMy48L2E+Jm5ic3A7ClJpY2ggQXBwIFByb2ZpbGU8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjM3Ij42 LjMuMS48L2E+Jm5ic3A7ClByb3Zpc2lvbmluZzxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjcDUuYXV0aG9yaXphdGlvbiI+Ni4z LjIuPC9hPiZuYnNwOwpDbGllbnQgRGlyZWN0cyB0aGUgVXNlciB0byB0aGUgICAgICBBdXRob3Jp emF0aW9uIFNlcnZlcjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMzgiPjYuMy4zLjwvYT4mbmJzcDsKQXV0aG9yaXph dGlvbiBTZXJ2ZXIgQ29uZmlybXMgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IHdpdGggVXNlcjxiciAv PgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSIjcDUucmVxdWVzdCI+Ni4zLjQuPC9hPiZuYnNwOwpDbGllbnQgUmVxdWVzdHMgQWNjZXNzIFRv a2VuPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9IiNwNS52ZXJpZmljYXRpb24iPjYuMy41LjwvYT4mbmJzcDsKU3VjY2Vzc2Z1bCBB Y2Nlc3MgVG9rZW4gUmVzcG9uc2UgZnJvbSBBdXRob3JpemF0aW9uIFNlcnZlcjxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5j aG9yNDEiPjYuMy42LjwvYT4mbmJzcDsKVW5zdWNjZXNzZnVsIEFjY2VzcyBUb2tlbiBSZXNwb25z ZSBmcm9tIEF1dGhvcml6YXRpb24gU2VydmVyPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I0MiI+Ni4zLjcuPC9hPiZu YnNwOwpDbGllbnQgUmVmcmVzaGVzIEFjY2VzcyBUb2tlbjxiciAvPgombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNDMiPjYuMy44 LjwvYT4mbmJzcDsKU3VjY2Vzc2Z1bCBBY2Nlc3MgVG9rZW4gUmVmcmVzaDxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9y NDQiPjYuMy45LjwvYT4mbmJzcDsKVW5zdWNjZXNzZnVsIEFjY2VzcyBUb2tlbiBSZWZyZXNoPGJy IC8+CjxhIGhyZWY9IiNQYXJhbUNvbiI+Ny48L2E+Jm5ic3A7ClBhcmFtZXRlciBDb25zaWRlcmF0 aW9uczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNDUiPjcu MS48L2E+Jm5ic3A7CkF1dGhvcml6YXRpb24gU2VydmVyIFJlcXVlc3QgLyBSZXNwb25zZSBQYXJh bWV0ZXIgICAgICAgRW5jb2Rpbmc8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJl Zj0iI2FuY2hvcjQ2Ij43LjIuPC9hPiZuYnNwOwpQYXJhbWV0ZXIgU2l6ZTxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNDciPjcuMy48L2E+Jm5ic3A7CkFjY2Vz cyBUb2tlbiBGb3JtYXQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2Fu Y2hvcjQ4Ij43LjQuPC9hPiZuYnNwOwpSZWZyZXNoIFRva2VuIEZvcm1hdDxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNDkiPjcuNS48L2E+Jm5ic3A7CkFkZGl0 aW9uYWwgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgUGFyYW1ldGVyczxiciAvPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNTAiPjcuNi48L2E+Jm5ic3A7ClBhcmFtZXRlciBO YW1lcyBhbmQgT3JkZXI8YnIgLz4KPGEgaHJlZj0iI0lBTkEiPjguPC9hPiZuYnNwOwpJQU5BIENv bnNpZGVyYXRpb25zPGJyIC8+CjxhIGhyZWY9IiNTZWN1cml0eSI+OS48L2E+Jm5ic3A7ClNlY3Vy aXR5IENvbnNpZGVyYXRpb25zPGJyIC8+CjxhIGhyZWY9IiNyZmMucmVmZXJlbmNlczEiPjEwLjwv YT4mbmJzcDsKUmVmZXJlbmNlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSIjcmZjLnJlZmVyZW5jZXMxIj4xMC4xLjwvYT4mbmJzcDsKTm9ybWF0aXZlIFJlZmVyZW5jZXM8 YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3JmYy5yZWZlcmVuY2VzMiI+ MTAuMi48L2E+Jm5ic3A7CkluZm9ybWF0aXZlIFJlZmVyZW5jZXM8YnIgLz4KPGEgaHJlZj0iI2Fu Y2hvcjUzIj5BcHBlbmRpeCZuYnNwO0EuPC9hPiZuYnNwOwpDbGllbnQgQWNjb3VudCBhbmQgUGFz c3dvcmQgUHJvZmlsZSBFeGFtcGxlPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9IiNhbmNob3I1NCI+QS4xLjwvYT4mbmJzcDsKUHJvdmlzaW9uaW5nPGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I1NSI+QS4yLjwvYT4mbmJzcDsKQ2xpZW50 IFJlcXVlc3RzIEFjY2VzcyBUb2tlbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYW5jaG9yNTYiPkEuMy48L2E+Jm5ic3A7ClN1Y2Nlc3NmdWwgQWNjZXNzIFRva2VuIFJl c3BvbnNlIGZyb20gQXV0aG9yaXphdGlvbiBTZXJ2ZXI8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjU3Ij5BLjQuPC9hPiZuYnNwOwpDbGllbnQgQ2FsbHMgUHJv dGVjdGVkIFJlc291cmNlPGJyIC8+CjxhIGhyZWY9IiNhbmNob3I1OCI+QXBwZW5kaXgmbmJzcDtC LjwvYT4mbmJzcDsKV2ViIEFwcCBQcm9maWxlIEV4YW1wbGU8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjU5Ij5CLjEuPC9hPiZuYnNwOwpQcm92aXNpb25pbmc8 YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjYwIj5CLjIuPC9h PiZuYnNwOwpDbGllbnQgRGlyZWN0cyB0aGUgVXNlciB0byB0aGUgU2VydmVyPGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I2MSI+Qi4zLjwvYT4mbmJzcDsKQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgQ29uZmlybXMgRGVsZWdhdGlvbiBSZXF1ZXN0IHdpdGggVXNlcjxi ciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNjIiPkIuNC48L2E+ Jm5ic3A7ClNlcnZlciBEaXJlY3RzIFVzZXIgYmFjayB0byB0aGUgQ2xpZW50PGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I2MyI+Qi41LjwvYT4mbmJzcDsKQ2xp ZW50IFJlcXVlc3RzIEFjY2VzcyBUb2tlbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSIjYW5jaG9yNjQiPkIuNi48L2E+Jm5ic3A7ClN1Y2Nlc3NmdWwgQWNjZXNzIFRva2Vu IFJlc3BvbnNlIGZyb20gQXV0aG9yaXphdGlvbiBTZXJ2ZXI8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjY1Ij5CLjcuPC9hPiZuYnNwOwpDbGllbnQgQ2FsbHMg UHJvdGVjdGVkIFJlc291cmNlPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9 IiNhbmNob3I2NiI+Qi44LjwvYT4mbmJzcDsKQ2xpZW50IFJlZnJlc2hlcyBBY2Nlc3MgVG9rZW48 YnIgLz4KPGEgaHJlZj0iI3JmYy5hdXRob3JzIj4mIzE2Nzs8L2E+Jm5ic3A7CkF1dGhvcnMnIEFk ZHJlc3NlczxiciAvPgo8L3A+CjxiciBjbGVhcj0iYWxsIiAvPgoKPGEgbmFtZT0iYW5jaG9yMSI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEiPjwvYT48aDM+MS4mbmJzcDsKT3ZlcnZpZXc8 L2gzPgoKPHA+QXMgdGhlIGludGVybmV0IGhhcyBldm9sdmVkLCB0aGVyZSBpcyBhIGdyb3dpbmcg dHJlbmQgZm9yIGEgdmFyaWV0eQogICAgICBvZiBhcHBsaWNhdGlvbnMgKENsaWVudHMpIHRvIGFj Y2VzcyByZXNvdXJjZXMgdGhyb3VnaCBhbiBBUEkgb3ZlciBIVFRQCiAgICAgIG9yIG90aGVyIHBy b3RvY29scy4gT2Z0ZW4gdGhlc2UgcmVzb3VyY2VzIHJlcXVpcmUgYXV0aG9yaXphdGlvbiBmb3IK ICAgICAgYWNjZXNzIGFuZCBhcmUgUHJvdGVjdGVkIFJlc291cmNlcy4gVGhlIHN5c3RlbXMgdGhh dCBhcmUgdHJ1c3RlZCB0byBtYWtlCiAgICAgIGF1dGhvcml6YXRpb24gZGVjaXNpb25zIG1heSBi ZSBpbmRlcGVuZGVudCBmcm9tIHRoZSBQcm90ZWN0ZWQgUmVzb3VyY2VzCiAgICAgIGZvciBzY2Fs ZSBhbmQgc2VjdXJpdHkgcmVhc29ucy4gVGhlIE9BdXRoIFdlYiBSZXNvdXJjZSBBdXRob3JpemF0 aW9uCiAgICAgIFByb2ZpbGVzIChPQXV0aCBXUkFQKSBlbmFibGUgYSBQcm90ZWN0ZWQgUmVzb3Vy Y2UgdG8gZGVsZWdhdGUgdGhlCiAgICAgIGF1dGhvcml6YXRpb24gdG8gYWNjZXNzIGEgUHJvdGVj dGVkIFJlc291cmNlIHRvIG9uZSBvciBtb3JlIHRydXN0ZWQKICAgICAgYXV0aG9yaXRpZXMuCjwv cD4KPHA+Q2xpZW50cyB0aGF0IHdpc2ggdG8gYWNjZXNzIGEgUHJvdGVjdGVkIFJlc291cmNlIGZp cnN0IG9idGFpbgogICAgICBhdXRob3JpemF0aW9uIGZyb20gYSB0cnVzdGVkIGF1dGhvcml0eSAo QXV0aG9yaXphdGlvbiBTZXJ2ZXIpLiBEaWZmZXJlbnQKICAgICAgY3JlZGVudGlhbHMgYW5kIHBy b2ZpbGVzIGNhbiBiZSB1c2VkIHRvIG9idGFpbiB0aGlzIGF1dGhvcml6YXRpb24sIGJ1dAogICAg ICBvbmNlIGF1dGhvcml6ZWQsIHRoZSBDbGllbnQgaXMgcHJvdmlkZWQgYW4gQWNjZXNzIFRva2Vu LCBhbmQgcG9zc2libGUgYQogICAgICBSZWZyZXNoIFRva2VuIHRvIG9idGFpbiBuZXcgQWNjZXNz IFRva2Vucy4gVGhlIEF1dGhvcml6YXRpb24gU2VydmVyCiAgICAgIHR5cGljYWxseSBpbmNsdWRl cyBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9uIGluIHRoZSBBY2Nlc3MgVG9rZW4gYW5kCiAgICAg IGRpZ2l0YWxseSBzaWducyB0aGUgQWNjZXNzIFRva2VuLiBQcm90ZWN0ZWQgUmVzb3VyY2UgY2Fu IHZlcmlmeSB0aGF0IGFuCiAgICAgIEFjY2VzcyBUb2tlbiByZWNlaXZlZCBmcm9tIGEgQ2xpZW50 IHdhcyBpc3N1ZWQgYnkgYSB0cnVzdGVkCiAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyIGFuZCBp cyB2YWxpZC4gVGhlIFByb3RlY3RlZCBSZXNvdXJjZSBjYW4gdGhlbgogICAgICBleGFtaW5lIHRo ZSBjb250ZW50cyBvZiB0aGUgQWNjZXNzIFRva2VuIHRvIGRldGVybWluZSB0aGUgYXV0aG9yaXph dGlvbgogICAgICB0aGF0IGhhcyBiZWVuIGdyYW50ZWQgdG8gdGhlIENsaWVudC4KPC9wPgo8YSBu YW1lPSJhbmNob3IyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMS4xIj48L2E+PGgzPjEu MS4mbmJzcDsKQWNjZXNzaW5nIGEgUHJvdGVjdGVkIFJlc291cmNlPC9oMz4KCjxwPlRoZSBBY2Nl c3MgVG9rZW4gaXMgb3BhcXVlIHRvIHRoZSBDbGllbnQsIGFuZCBjYW4gYmUgYW55IGZvcm1hdAog ICAgICAgIGFncmVlZCB0byBiZXR3ZWVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQgdGhl IFByb3RlY3RlZCBSZXNvdXJjZQogICAgICAgIGVuYWJsaW5nIGV4aXN0aW5nIHN5c3RlbXMgdG8g cmV1c2Ugc3VpdGFibGUgdG9rZW5zLCBvciB1c2UgYSBzdGFuZGFyZAogICAgICAgIHRva2VuIGZv cm1hdCBzdWNoIGFzIGEgU2ltcGxlIFdlYiBUb2tlbiBvciBKU09OIFdlYiBUb2tlbi4gU2luY2Ug dGhlCiAgICAgICAgQWNjZXNzIFRva2VuIHByb3ZpZGVzIHRoZSBDbGllbnQgYXV0aG9yaXphdGlv biB0byB0aGUgUHJvdGVjdGVkCiAgICAgICAgUmVzb3VyY2UgZm9yIHRoZSBsaWZlIG9mIHRoZSBB Y2Nlc3MgVG9rZW4sIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcgogICAgICAgIHNob3VsZCBpc3N1 ZSBBY2Nlc3MgVG9rZW5zIHRoYXQgZXhwaXJlIHdpdGhpbiBhbiBhcHByb3ByaWF0ZSB0aW1lLgog ICAgICAgIFdoZW4gYW4gQWNjZXNzIFRva2VuIGV4cGlyZXMsIHRoZSBDbGllbnQgcmVxdWVzdHMg YSBuZXcgQWNjZXNzIFRva2VuCiAgICAgICAgZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIs IHdoaWNoIG9uY2UgYWdhaW4gY29tcHV0ZXMgdGhlIENsaWVudCdzCiAgICAgICAgYXV0aG9yaXph dGlvbiwgYW5kIGlzc3VlcyBhIG5ldyBBY2Nlc3MgVG9rZW4uIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjZmlnMSc+RmlndXJlJm5ic3A7MTwvYT4gYmVsb3cgc2hvd3MgdGhlIGZsb3cgYmV0d2VlbiB0 aGUgQ2xpZW50IGFuZAogICAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyIChBLEIpOyBhbmQgdGhl biBiZXR3ZWVuIHRoZSBDbGllbnQgYW5kIFByb3RlY3RlZAogICAgICAgIFJlc291cmNlIChDLEQp Ogo8L3A+PGJyIC8+PGhyIGNsYXNzPSJpbnNlcnQiIC8+CjxhIG5hbWU9ImZpZzEiPjwvYT4KPGRp diBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJn aW4tcmlnaHQ6IGF1dG8nPjxwcmU+CiAgKy0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8IEMgfC0tKEEpLS0tLS0tIGNyZWRlbnRpYWxzIC0t LS0tLS0tLSZndDt8IEF1dGhvcml6YXRpb24gfAogIHwgbCB8Jmx0Oy0oQiktLS0tLS0gQWNjZXNz IFRva2VuIC0tLS0tLS0tLXwgU2VydmVyICAgICAgICB8CiAgfCBpIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8IGUgfAogIHwgbiB8ICAgICAg ICAgICAgQWNjZXNzIFRva2VuICAgICAgICAgICstLS0tLS0tLS0tLSsKICB8IHQgfC0tKEMpLS0t LS0gaW4gSFRUUCBoZWFkZXIgLS0tLS0tLSZndDt8IFByb3RlY3RlZCB8CiAgfCAgIHwmbHQ7LShE KS0tLS0tLSBBUEkgcmVzcG9uc2UgLS0tLS0tLS0tfCBSZXNvdXJjZSAgfAogICstLS0rICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsKPC9wcmU+PC9kaXY+PHRh YmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBhbGlnbj0iY2Vu dGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9Im1vbmFjbywgTVMgU2FucyBT ZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7RmlndXJlJm5ic3A7MSZuYnNwOzwvYj48L2ZvbnQ+PGJy IC8+PC90ZD48L3RyPjwvdGFibGU+PGhyIGNsYXNzPSJpbnNlcnQiIC8+Cgo8cD5JbiBzdGVwIEEs IHRoZSBDbGllbnQgcHJlc2VudHMgY3JlZGVudGlhbHMgdG8gdGhlIEF1dGhvcml6YXRpb24KICAg ICAgICBTZXJ2ZXIgaW4gZXhjaGFuZ2UgZm9yIGFuIEFjY2VzcyBUb2tlbi4KPC9wPgo8cD4gQSBQ cm9maWxlIHNwZWNpZmllcyB0aGUgY3JlZGVudGlhbHMgdG8gYmUgcHJvdmlkZWQgaW4gc3RlcCBB LCBhbmQKCWhvdyB0aGUgQ2xpZW50IG9idGFpbnMgdGhlbS4gVGhpcyBzcGVjaWZpY2F0aW9uIGRl ZmluZXMgYSBudW1iZXIgb2YKCVByb2ZpbGVzOyBhZGRpdGlvbmFsIFByb2ZpbGVzIG1heSBiZSBk ZWZpbmVkIHRvIHN1cHBvcnQgYWRkaXRpb25hbAoJc2NlbmFyaW9zLiBUaGUgUHJvZmlsZXMgaW4g dGhpcyBzcGVjaWZpY2F0aW9uIGFyZSBzZXBhcmF0ZWQgaW50byB0d28KCWdyb3VwczogYXV0b25v bW91cyBwcm9maWxlcyB3aGVyZSB0aGUgQ2xpZW50IGFzIGFjdGluZyBmb3IgaXRzZWxmLCBhbmQK CXVzZXIgZGVsZWdhdGlvbiBwcm9maWxlcyB3aGVyZSB0aGUgQ2xpZW50IGlzIGFjdGluZyBvbiBi ZWhhbGYgb2YgYQoJVXNlci4KPC9wPgo8YSBuYW1lPSJhbmNob3IzIj48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uMS4yIj48L2E+PGgzPjEuMi4mbmJzcDsKQXV0b25vbW91cyBDbGllbnQgUHJv ZmlsZXM8L2gzPgoKPHA+VGhlIGZvbGxvd2luZyB0d28gUHJvZmlsZXMgKHNlZSA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI2F1dG9ub21vdXMucHJvZmlsZXMnPlNlY3Rpb24mbmJzcDs1PHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjcXVpcmluZyBhbiBBY2Nlc3MgVG9rZW46IEF1dG9u b21vdXMgQ2xpZW50IFByb2ZpbGVzPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPikgYXJlIHJlY29t bWVuZGVkIGZvciBzY2VuYXJpb3MKICAgICAgICBpbnZvbHZpbmcgYSBDbGllbnQgYWN0aW5nIGF1 dG9ub21vdXNseS4KPC9wPgo8cD5DbGllbnQgQWNjb3VudCBhbmQgUGFzc3dvcmQgUHJvZmlsZSAo PGEgY2xhc3M9J2luZm8nIGhyZWY9JyNwMSc+U2VjdGlvbiZuYnNwOzUuMTxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5DbGllbnQgQWNjb3VudCBhbmQgUGFzc3dvcmQgUHJvZmlsZTwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pOiBUaGlzCglpcyB0aGUgc2ltcGxlc3QgUHJvZmlsZS4g VGhlIENsaWVudCBpcyBwcm92aXNpb25lZCB3aXRoIGFuIGFjY291bnQgbmFtZQoJYW5kIGNvcnJl c3BvbmRpbmcgcGFzc3dvcmQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiBUaGUgQ2xpZW50 CglwcmVzZW50cyB0aGUgYWNjb3VudCBuYW1lIGFuZCBwYXNzd29yZCB0byB0aGUgQWNjZXNzIFRv a2VuIFVSTCBhdCB0aGUKCUF1dGhvcml6YXRpb24gU2VydmVyIGluIGV4Y2hhbmdlIGZvciBhbiBB Y2Nlc3MgVG9rZW4uIFRoaXMgUHJvZmlsZSBpcwoJbm90IGludGVuZGVkIGZvciBhIENsaWVudCBh Y3Rpbmcgb24gYmVoYWxmIG9mIGEgVXNlci4gU2VlIHRoZSBVc2VyCglEZWxlZ2F0aW9uIFByb2Zp bGVzLgo8L3A+CjxwPkFzc2VydGlvbiBQcm9maWxlICg8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Ay Jz5TZWN0aW9uJm5ic3A7NS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFzc2Vy dGlvbiBQcm9maWxlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPik6IFRoaXMgcHJvZmlsZSBlbmFi bGVzIGEKCUNsaWVudCB3aXRoIGEgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNPQVNJUy5zYW1sLWNv cmUtMi4wLW9zJz5TQU1MPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNhbnRvciwg Uy4sIEtlbXAsIEouLCBQaGlscG90dCwgUi4sIGFuZCBFLiBNYWxlciwgJmxkcXVvO0Fzc2VydGlv bnMgYW5kIFByb3RvY29sIGZvciB0aGUgT0FTSVMgU2VjdXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBM YW5ndWFnZSAgICAgICAgICAgICAoU0FNTCkgVjIuMCwmcmRxdW87IE1hcmNoJm5ic3A7MjAwNS48 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtPQVNJUy5zYW1sJiM4MjA5O2NvcmUmIzgyMDk7Mi4w JiM4MjA5O29zXSBvciBvdGhlcgoJYXNzZXJ0aW9uIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6 YXRpb24gU2VydmVyLiBUaGUgQ2xpZW50IHByZXNlbnRzCgl0aGUgYXNzZXJ0aW9uIHRvIHRoZSBB Y2Nlc3MgVG9rZW4gVVJMIGF0IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBpbgoJZXhjaGFuZ2Ug Zm9yIGFuIEFjY2VzcyBUb2tlbi4gSG93IHRoZSBDbGllbnQgb2J0YWlucyB0aGUgYXNzZXJ0aW9u IGlzCglvdXQgb2Ygc2NvcGUgb2YgT0F1dGggV1JBUC4KPC9wPgo8cD5BY2Nlc3MgVG9rZW5zIGFy ZSBzaG9ydCBsaXZlZCBiZWFyZXIgdG9rZW5zLiBXaGVuIHRoZSBQcm90ZWN0ZWQKICAgICAgICBS ZXNvdXJjZSBpcyBwcmVzZW50ZWQgd2l0aCBhbiBleHBpcmVkIEFjY2VzcyBUb2tlbiBieSB0aGUg Q2xpZW50LCB0aGUKICAgICAgICBQcm90ZWN0ZWQgUmVzb3VyY2UgcmV0dXJucyBhbiBlcnJvci4g VGhlIENsaWVudCBwcmVzZW50cyB0aGUgYXNzZXJ0aW9uCiAgICAgICAgb25jZSBhZ2FpbiB0byB0 aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG8gb2J0YWluIGEgbmV3IEFjY2VzcwogICAgICAgIFRv a2VuLgo8L3A+CjxhIG5hbWU9ImFuY2hvcjQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4x LjMiPjwvYT48aDM+MS4zLiZuYnNwOwpVc2VyIERlbGVnYXRpb24gUHJvZmlsZXM8L2gzPgoKPHA+ Q29tbW9uIHNjZW5hcmlvcyBpbnZvbHZlIHRoZSBVc2VyIGRlbGVnYXRpbmcgdG8gYSBDbGllbnQg dG8gYWN0IG9uCiAgICAgICAgdGhlIFVzZXIncyBiZWhhbGYsIGFkZGluZyBhbm90aGVyIHBhcnR5 ICh0aGUgVXNlcikgdG8gdGhlIHByb3RvY29sLiBJbgogICAgICAgIHRoZXNlIFByb2ZpbGVzIChz ZWUgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN1c2VyLnByb2ZpbGVzJz5TZWN0aW9uJm5ic3A7Njxz cGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY3F1aXJpbmcgYW4gQWNjZXNzIFRva2Vu OiBVc2VyIERlbGVnYXRpb24gUHJvZmlsZXM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSwgdGhl IENsaWVudAogICAgICAgIHJlY2VpdmVzIGEgUmVmcmVzaCBUb2tlbiB3aGVuIGl0IGFjcXVpcmVz IHRoZSBmaXJzdCBBY2Nlc3MgVG9rZW4uIFdoZW4KICAgICAgICBhbiBBY2Nlc3MgVG9rZW4gZXhw aXJlcywgdGhlIENsaWVudCBwcmVzZW50cyB0aGUgUmVmcmVzaCBUb2tlbiB0bwogICAgICAgIGFj cXVpcmUgYSBuZXcgQWNjZXNzIFRva2VuLiBSZWZyZXNoIFRva2VucyBhcmUgc2Vuc2l0aXZlIGFz IHRoZXkKICAgICAgICByZXByZXNlbnQgbG9uZy1saXZlZCBwZXJtaXNzaW9ucyB0byBhY2Nlc3Mg YSBQcm90ZWN0ZWQgUmVzb3VyY2UgYW5kCiAgICAgICAgYXJlIGFsd2F5cyB0cmFuc21pdHRlZCB1 c2luZyBIVFRQUy4KPC9wPgo8cD5Vc2VybmFtZSBhbmQgUGFzc3dvcmQgUHJvZmlsZSAoPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNwMyc+U2VjdGlvbiZuYnNwOzYuMTxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5Vc2VybmFtZSBhbmQgUGFzc3dvcmQgUHJvZmlsZTwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT4pOiBXaGlsZQogICAgICAgIHRoZSBVc2VyIG1heSB1c2UgYSB1c2VybmFtZSBh bmQgcGFzc3dvcmQgdG8gYXV0aGVudGljYXRlIHRvIHRoZQogICAgICAgIEF1dGhvcml6YXRpb24g U2VydmVyLCBpdCBpcyB1bmRlc2lyYWJsZSBmb3IgdGhlIENsaWVudCB0byBzdG9yZSB0aGUKICAg ICAgICBVc2VyJ3MgdXNlcm5hbWUgYW5kIHBhc3N3b3JkLiBJbiB0aGlzIHByb2ZpbGUgdGhlIFVz ZXIgcHJvdmlkZXMgdGhlaXIKICAgICAgICB1c2VybmFtZSBhbmQgcGFzc3dvcmQgdG8gYW4gYXBw bGljYXRpb24gKENsaWVudCkgdGhleSBoYXZlIGluc3RhbGxlZAogICAgICAgIG9uIHRoZWlyIGRl dmljZS4gVGhlIENsaWVudCBwcmVzZW50cyBhIENsaWVudCBJZGVudGlmaWVyLCB0aGUgdXNlcm5h bWUKICAgICAgICBhbmQgcGFzc3dvcmQgKGNyZWRlbnRpYWxzKSB0byB0aGUgQWNjZXNzIFRva2Vu IFVSTCBhdCB0aGUKICAgICAgICBBdXRob3JpemF0aW9uIFNlcnZlciBpbiBleGNoYW5nZSBmb3Ig YW4gQWNjZXNzIFRva2VuIGFuZCBhIFJlZnJlc2gKICAgICAgICBUb2tlbiBhcyBkZXBpY3RlZCBp biA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2ZpZzInPkZpZ3VyZSZuYnNwOzI8L2E+IGJlbG93Lgo8 L3A+PGJyIC8+PGhyIGNsYXNzPSJpbnNlcnQiIC8+CjxhIG5hbWU9ImZpZzIiPjwvYT4KPGRpdiBz dHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4t cmlnaHQ6IGF1dG8nPjxwcmU+CiAgKy0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8IEMgfC0tKEEpLS0tLS0tIGNyZWRlbnRpYWxzIC0tLS0t LS0tLSZndDt8IEF1dGhvcml6YXRpb24gfAogIHwgbCB8Jmx0Oy0oQiktLS0tLS0gQWNjZXNzIFRv a2VuIC0tLS0tLS0tLXwgU2VydmVyICAgICAgICB8CiAgfCBpIHwgICAgICAgICAgICBSZWZyZXNo IFRva2VuICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8IGUgfAogIHwgbiB8ICAgICAgICAg ICAgQWNjZXNzIFRva2VuICAgICAgICAgICstLS0tLS0tLS0tLSsKICB8IHQgfC0tKEMpLS0tLS0g aW4gSFRUUCBoZWFkZXIgLS0tLS0tLSZndDt8IFByb3RlY3RlZCB8CiAgfCAgIHwmbHQ7LShEKS0t LS0tLSBBUEkgcmVzcG9uc2UgLS0tLS0tLS0tfCBSZXNvdXJjZSAgfAogICstLS0rICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsKCjwvcHJlPjwvZGl2Pjx0YWJs ZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgYWxpZ249ImNlbnRl ciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJtb25hY28sIE1TIFNhbnMgU2Vy aWYiIHNpemU9IjEiPjxiPiZuYnNwO0ZpZ3VyZSZuYnNwOzImbmJzcDs8L2I+PC9mb250PjxiciAv PjwvdGQ+PC90cj48L3RhYmxlPjxociBjbGFzcz0iaW5zZXJ0IiAvPgoKPHA+V2hlbiB0aGUgQWNj ZXNzIFRva2VuIGV4cGlyZXMsIHRoZSBDbGllbnQgcHJlc2VudHMgdGhlIFJlZnJlc2gKICAgICAg ICBUb2tlbiB0byB0aGUgUmVmcmVzaCBUb2tlbiBVUkwgYXQgdGhlIEF1dGhvcml6YXRpb24gU2Vy dmVyIGluIGV4Y2hhbmdlCiAgICAgICAgZm9yIGEgbmV3IEFjY2VzcyBUb2tlbiAoPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNmaWczJz5GaWd1cmUmbmJzcDszPC9hPiwgc3RlcHMgQSBhbmQgQikuCiAg ICAgICAgVGhlIENsaWVudCB0aGVuIHVzZXMgdGhlIG5ldyBBY2Nlc3MgVG9rZW4gdG8gYWNjZXNz IHRoZSBQcm90ZWN0ZWQKICAgICAgICBSZXNvdXJjZSAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNm aWczJz5GaWd1cmUmbmJzcDszPC9hPiwgc3RlcHMgQyBhbmQgRCkuCjwvcD48YnIgLz48aHIgY2xh c3M9Imluc2VydCIgLz4KPGEgbmFtZT0iZmlnMyI+PC9hPgo8ZGl2IHN0eWxlPSdkaXNwbGF5OiB0 YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHBy ZT4KICArLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tKwogIHwgQyB8LS0oQSktLS0tLSBSZWZyZXNoIFRva2VuIC0tLS0tLS0tJmd0O3wgQXV0aG9y aXphdGlvbiB8CiAgfCBsIHwmbHQ7LShCKS0tLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLS0tfCBT ZXJ2ZXIgICAgICAgIHwKICB8IGkgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0tKwogIHwgZSB8CiAgfCBuIHwgICAgICAgICAgICBBY2Nlc3MgVG9rZW4g ICAgICAgICAgKy0tLS0tLS0tLS0tKwogIHwgdCB8LS0oQyktLS0tLSBpbiBIVFRQIGhlYWRlciAt LS0tLS0tJmd0O3wgUHJvdGVjdGVkIHwKICB8ICAgfCZsdDstKEQpLS0tLS0tIEFQSSByZXNwb25z ZSAtLS0tLS0tLS18IFJlc291cmNlICB8CiAgKy0tLSsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tKwoKPC9wcmU+PC9kaXY+PHRhYmxlIGJvcmRlcj0iMCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBhbGlnbj0iY2VudGVyIj48dHI+PHRkIGFsaWdu PSJjZW50ZXIiPjxmb250IGZhY2U9Im1vbmFjbywgTVMgU2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+ Jm5ic3A7RmlndXJlJm5ic3A7MyZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48L3RyPjwvdGFi bGU+PGhyIGNsYXNzPSJpbnNlcnQiIC8+Cgo8cD5XZWIgQXBwIFByb2ZpbGUgKDxhIGNsYXNzPSdp bmZvJyBocmVmPScjcDQnPlNlY3Rpb24mbmJzcDs2LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+V2ViIEFwcCBQcm9maWxlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPik6IEl0IGlz IHVuZGVzaXJhYmxlIGZvcgogICAgICAgIGEgVXNlciB0byBwcm92aWRlIHRoZWlyIEF1dGhvcml6 YXRpb24gU2VydmVyIHVzZXJuYW1lIGFuZCBwYXNzd29yZCB0bwogICAgICAgIHdlYiBhcHBsaWNh dGlvbnMuIEFkZGl0aW9uYWxseSwgdGhlIFVzZXIgbWF5IGF1dGhlbnRpY2F0ZSB0byB0aGUKICAg ICAgICBBdXRob3JpemF0aW9uIFNlcnZlciB1c2luZyBvdGhlciBtZWNoYW5pc21zIHRoYW4gYSB1 c2VybmFtZSBhbmQKICAgICAgICBwYXNzd29yZC4gSW4gdGhpcyBwcm9maWxlLCBhIHdlYiBhcHBs aWNhdGlvbiAoQ2xpZW50KSBoYXMgYmVlbgogICAgICAgIHByb3Zpc2lvbmVkIHdpdGggYSBDbGll bnQgSWRlbnRpZmllciBhbmQgQ2xpZW50IFNlY3JldCBhbmQgbWF5IGhhdmUKICAgICAgICByZWdp c3RlcmVkIGEgQ2FsbGJhY2sgVVJMLiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2ZpZzQnPkZpZ3Vy ZSZuYnNwOzQ8L2E+IGJlbG93CiAgICAgICAgaWxsdXN0cmF0ZXMgdGhlIHByb3RvY29sLiAoQSkg VGhlIENsaWVudCBpbml0aWF0ZXMgdGhlIHByb3RvY29sIGJ5CiAgICAgICAgcmVkaXJlY3Rpbmcg dGhlIFVzZXIgdG8gdGhlIFVzZXIgQXV0aG9yaXphdGlvbiBVUkwgYXQgdGhlCiAgICAgICAgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgcGFzc2luZyB0aGUgQ2xpZW50IElkZW50aWZpZXIgYW5kIHRoZSBD YWxsYmFjawogICAgICAgIFVSTC4gKEIpIFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhdXRoZW50 aWNhdGVzIHRoZSBVc2VyLCBjb25maXJtcyB0aGUKICAgICAgICBVc2VyIHdvdWxkIGxpa2UgdG8g YXV0aG9yaXplIHRoZSBDbGllbnQgdG8gYWNjZXNzIHRoZSBQcm90ZWN0ZWQKICAgICAgICBSZXNv dXJjZSwgYW5kIGdlbmVyYXRlcyBhIFZlcmlmaWNhdGlvbiBDb2RlLiAoQykgVGhlIEF1dGhvcml6 YXRpb24KICAgICAgICBTZXJ2ZXIgdGhlbiByZWRpcmVjdHMgdGhlIFVzZXIgdG8gdGhlIENhbGxi YWNrIFVSTCBhdCB0aGUgQ2xpZW50CiAgICAgICAgcGFzc2luZyBhbG9uZyB0aGUgVmVyaWZpY2F0 aW9uIENvZGUuCjwvcD48YnIgLz48aHIgY2xhc3M9Imluc2VydCIgLz4KPGEgbmFtZT0iZmlnNCI+ PC9hPgo8ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAz ZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICstLS0tLS0tLS0rCiB8IFdlYiBBcHAgfAog fCBDbGllbnQgIHwKICstLS0tLS0tLS0rCiAgIHYgICAgXgogICB8ICAgIHwKICAoQSkgIChDKQog ICB8ICAgIHwKICAgXCAgICBcCiArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiB8ICAgICAgICAgfFwtLS0oQyktLSBWZXJpZmljYXRp b24gQ29kZSAtLS0tJmx0O3wgICAgICAgICAgICAgICB8CiB8ICAgVXNlciAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgQXV0aG9yaXphdGlvbiB8CiB8ICAgIGF0ICAgfCZsdDst LS0oQiktLSBVc2VyIGF1dGhlbnRpY2F0ZXMgLS0tJmd0O3wgU2VydmVyICAgICAgICB8CiB8IEJy b3dzZXIgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8 CiB8ICAgICAgICAgfFwtLS0oQSktLSBDbGllbnQgSWRlbnRpZmllciAtLS0tJmd0O3wgICAgICAg ICAgICAgICB8CiArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0rCjwvcHJlPjwvZGl2Pjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVy Ij48Zm9udCBmYWNlPSJtb25hY28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEiPjxiPiZuYnNwO0Zp Z3VyZSZuYnNwOzQmbmJzcDs8L2I+PC9mb250PjxiciAvPjwvdGQ+PC90cj48L3RhYmxlPjxociBj bGFzcz0iaW5zZXJ0IiAvPgoKPHA+U2ltaWxhciB0byBzdGVwIEEgaW4gPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNmaWcyJz5GaWd1cmUmbmJzcDsyPC9hPiwgdGhlIENsaWVudCB0aGVuCiAgICAgICAg cHJlc2VudHMgdGhlIENsaWVudCBJZGVudGlmaWVyLCBDbGllbnQgU2VjcmV0LCBDYWxsYmFjayBV UkwgYW5kCiAgICAgICAgVmVyaWZpY2F0aW9uIGNvZGUgKGNyZWRlbnRpYWxzKSB0byB0aGUgQWNj ZXNzIFRva2VuIFVSTCBhdCB0aGUKICAgICAgICBBdXRob3JpemF0aW9uIFNlcnZlciBmb3IgYW4g QWNjZXNzIFRva2VuIGFuZCBhIFJlZnJlc2ggVG9rZW4uCjwvcD4KPHA+UmljaCBBcHAgUHJvZmls ZSAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNwNSc+U2VjdGlvbiZuYnNwOzYuMzxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SaWNoIEFwcCBQcm9maWxlPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPik6IFRoaXMgcHJvZmlsZSBpcwogICAgICAgIHN1aXRhYmxlIHdoZW4gdGhlIENsaWVu dCBpcyBhbiBhcHBsaWNhdGlvbiB0aGUgVXNlciBoYXMgaW5zdGFsbGVkIG9uCiAgICAgICAgdGhl aXIgZGV2aWNlIGFuZCBhIHdlYiBicm93c2VyIGlzIGF2YWlsYWJsZSwgYnV0IGl0IGlzIHVuZGVz aXJhYmxlIGZvcgogICAgICAgIHRoZSBVc2VyIHRvIHByb3ZpZGUgdGhlaXIgdXNlcm5hbWUgYW5k IHBhc3N3b3JkIHRvIGFuIGFwcGxpY2F0aW9uLCBvcgogICAgICAgIHRoZSB1c2VyIG1heSBub3Qg YmUgdXNpbmcgYSB1c2VybmFtZSBhbmQgcGFzc3dvcmQgdG8gYXV0aGVudGljYXRlIHRvCiAgICAg ICAgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLgo8L3A+CjxwPlRoZSBDbGllbnQgaW5pdGlhdGVz IHRoZSBwcm90b2NvbCBieSBkaXJlY3RpbmcgdGhlIFVzZXIncyBicm93c2VyCiAgICAgICAgdG8g dGhlIEF1dGhvcml6YXRpb24gVVJMIGF0IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBwYXNzaW5n IHRoZQogICAgICAgIENsaWVudCBJZGVudGlmaWVyIGFuZCBwb3RlbnRpYWxseSBhIENhbGxiYWNr IFVSTC4gVGhlIEF1dGhvcml6YXRpb24KICAgICAgICBTZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUg VXNlciwgY29uZmlybXMgdGhlIFVzZXIgd291bGQgbGlrZSB0bwogICAgICAgIGF1dGhvcml6ZSB0 aGUgQ2xpZW50IHRvIGFjY2VzcyB0aGUgUHJvdGVjdGVkIFJlc291cmNlLCBhbmQgZ2VuZXJhdGVz IGEKICAgICAgICBWZXJpZmljYXRpb24gQ29kZS4gVGhlIFZlcmlmaWNhdGlvbiBDb2RlIG1heSBi ZSBjb21tdW5pY2F0ZWQgYmFjayB0bwogICAgICAgIHRoZSBDbGllbnQgaW4gYSBudW1iZXIgb2Yg d2F5czoKPC9wPgo8cD48L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5hLjwv ZHQ+CjxkZD50aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgcHJlc2VudHMgdGhlIFZlcmlmaWNhdGlv biBDb2RlIHRvIHRoZQogICAgICAgICAgICBVc2VyLCB3aG8gaXMgaW5zdHJ1Y3RlZCB0byBlbnRl ciB0aGUgVmVyaWZpY2F0aW9uIENvZGUgZGlyZWN0bHkgaW4KICAgICAgICAgICAgdGhlIENsaWVu dDsKPC9kZD4KPGR0PmIuPC9kdD4KPGRkPnRoZSBDbGllbnQgcmVhZHMgdGhlIFZlcmlmaWNhdGlv biBDb2RlIGZyb20gdGhlIHRpdGxlIG9mIHRoZQogICAgICAgICAgICB3ZWIgcGFnZSBwcmVzZW50 ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyOwo8L2RkPgo8ZHQ+Yy48L2R0Pgo8ZGQ+dGhl IEF1dGhvcml6YXRpb24gU2VydmVyIHJlZGlyZWN0cyB0aGUgVXNlciB0byB0aGUgQ2FsbGJhY2sg VVJMCiAgICAgICAgICAgIHRoYXQgcHJlc2VudHMgQ2xpZW50IHNwZWNpZmljIGxhbmd1YWdlIGZv ciB0aGUgVXNlciB0byBlbnRlciB0aGUKICAgICAgICAgICAgVmVyaWZpY2F0aW9uIENvZGUgaW50 byB0aGUgQ2xpZW50OyBvcgo8L2RkPgo8ZHQ+ZC48L2R0Pgo8ZGQ+dGhlIENsaWVudCBoYXMgcmVn aXN0ZXJlZCBhIGN1c3RvbSBzY2hlbWUgYW5kIHRoZSBBdXRob3JpemF0aW9uCiAgICAgICAgICAg IFNlcnZlciByZWRpcmVjdHMgdGhlIGJyb3dzZXIgdG8gdGhlIGN1c3RvbSBzY2hlbWUgdGhhdCBj YXVzZXMgdGhlCiAgICAgICAgICAgIFVzZXIncyBicm93c2VyIHRvIGxvYWQgdGhlIENsaWVudCBh cHBsaWNhdGlvbiB3aXRoIHRoZQogICAgICAgICAgICBWZXJpZmljYXRpb24gQ29kZSBhcyBhIHBh cmFtZXRlci4KPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+Cgo8cD5TaW1pbGFyIHRvIHN0ZXAgQSBp biA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2ZpZzInPkZpZ3VyZSZuYnNwOzI8L2E+LCB0aGUgQ2xp ZW50IHRoZW4KICAgICAgICBwcmVzZW50cyB0aGUgQ2xpZW50IElkZW50aWZpZXIsIENhbGxiYWNr IFVSTCAoaWYgcHJvdmlkZWQpIGFuZAogICAgICAgIFZlcmlmaWNhdGlvbiBjb2RlIChjcmVkZW50 aWFscykgdG8gdGhlIEFjY2VzcyBUb2tlbiBVUkwgYXQgdGhlCiAgICAgICAgQXV0aG9yaXphdGlv biBTZXJ2ZXIgZm9yIGFuIEFjY2VzcyBUb2tlbiBhbmQgYSBSZWZyZXNoIFRva2VuLgo8L3A+Cjxh IG5hbWU9ImFuY2hvcjUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4yIj48L2E+PGgzPjIu Jm5ic3A7ClJlcXVpcmVtZW50cyBMYW5ndWFnZTwvaDM+Cgo8cD5UaGUga2V5IHdvcmRzICJNVVNU IiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICAgICJT SE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFM IiBpbiB0aGlzCiAgICAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmli ZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyMTE5Jz5bUkZDMjExOV08c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QnJhZG5lciwgUy4sICZsZHF1bztLZXkgd29yZHMgZm9y IHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50IExldmVscywmcmRxdW87IE1hcmNo Jm5ic3A7MTk5Ny48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiBEb21haW4gbmFtZSBleGFtcGxl cyB1c2UgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyNjA2Jz5bUkZDMjYwNl08c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RWFzdGxha2UsIEQuIGFuZCBBLiBQYW5pdHosICZsZHF1 bztSZXNlcnZlZCBUb3AgTGV2ZWwgRE5TIE5hbWVzLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9z cGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KPC9wPgo8YSBuYW1lPSJhbmNob3I2Ij48L2E+PGJyIC8+ PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWci PjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEg bmFtZT0icmZjLnNlY3Rpb24uMyI+PC9hPjxoMz4zLiZuYnNwOwpEZWZpbml0aW9uczwvaDM+Cgo8 cD48L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5BY2Nlc3MgVG9rZW46PC9k dD4KPGRkPmEgc2hvcnQgbGl2ZWQgYmVhcmVyIHRva2VuIGlzc3VlZCBieSB0aGUKICAgICAgICAg IEF1dGhvcml6YXRpb24gU2VydmVyIHRvIHRoZSBDbGllbnQuIFRoZSBBY2Nlc3MgVG9rZW4gaXMg cHJlc2VudGVkIGJ5CiAgICAgICAgICB0aGUgQ2xpZW50IHRvIHRoZSBQcm90ZWN0ZWQgUmVzb3Vy Y2UgdG8gYWNjZXNzIHByb3RlY3RlZAogICAgICAgICAgcmVzb3VyY2VzLgo8L2RkPgo8ZHQ+QXV0 aG9yaXphdGlvbiBTZXJ2ZXI6PC9kdD4KPGRkPmFuIGF1dGhvcml6YXRpb24gcmVzb3VyY2UgdGhh dAogICAgICAgICAgaXNzdWVzIEFjY2VzcyBUb2tlbnMgdG8gQ2xpZW50cyBhZnRlciBzdWNjZXNz ZnVsIGF1dGhvcml6YXRpb24uIE1heQogICAgICAgICAgYmUgdGhlIHNhbWUgZW50aXR5IGFzIHRo ZSBQcm90ZWN0ZWQgUmVzb3VyY2UuCjwvZGQ+CjxkdD5DbGllbnQ6PC9kdD4KPGRkPmFuIGFwcGxp Y2F0aW9uIHRoYXQgd291bGQgbGlrZSBhY2Nlc3MgdG8gYQogICAgICAgICAgUHJvdGVjdGVkIFJl c291cmNlLiBDbGllbnQgSWRlbnRpZmllcjoiJmd0OyBhIHZhbHVlIHVzZWQgYnkgYSBDbGllbnQK ICAgICAgICAgIHRvIGlkZW50aWZ5IGl0c2VsZiB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIu IFRoaXMgbWF5IGJlIGEgaHVtYW4KICAgICAgICAgIHJlYWRhYmxlIHN0cmluZyBvciBhbiBvcGFx dWUgaWRlbnRpZmllci4KPC9kZD4KPGR0PkNsaWVudCBTZWNyZXQ6PC9kdD4KPGRkPmEgc2VjcmV0 IHVzZWQgYnkgYSB3ZWIgYXBwbGljYXRpb24KICAgICAgICAgIENsaWVudCB0byBlc3RhYmxpc2gg b3duZXJzaGlwIG9mIHRoZSBDbGllbnQgSWRlbnRpZmllci4KPC9kZD4KPGR0PlByb2ZpbGU6PC9k dD4KPGRkPmEgbWVjaGFuaXNtIGZvciBhIENsaWVudCB0byBvYnRhaW4gYW4gQWNjZXNzCiAgICAg ICAgICBUb2tlbiBmcm9tIGFuIEF1dGhvcml6YXRpb24gU2VydmVyLgo8L2RkPgo8ZHQ+UHJvdGVj dGVkIFJlc291cmNlOjwvZHQ+CjxkZD5hIHByb3RlY3RlZCBBUEkgdGhhdCBhbGxvd3MgYWNjZXNz CiAgICAgICAgICB2aWEgT0F1dGggV1JBUC4gTWF5IGJlIHRoZSBzYW1lIGVudGl0eSBhcyB0aGUg QXV0aG9yaXphdGlvbiBTZXJ2ZXIuCiAgICAgICAgICBSZWZyZXNoIFRva2VuOiImZ3Q7IGEgbG9u ZyBsaXZlZCBiZWFyZXIgdG9rZW4gdXNlZCBieSBhIENsaWVudCB0bwogICAgICAgICAgYWNxdWly ZSBhbiBBY2Nlc3MgVG9rZW4gZnJvbSBhbiBBdXRob3JpemF0aW9uIFNlcnZlci4KPC9kZD4KPGR0 PlVzZXI6PC9kdD4KPGRkPmFuIGluZGl2aWR1YWwgd2hvIGhhcyBhbiBhY2NvdW50IHdpdGggdGhl CiAgICAgICAgICBBdXRob3JpemF0aW9uIFNlcnZlci4KPC9kZD4KPGR0PlZlcmlmaWNhdGlvbiBD b2RlOjwvZHQ+CjxkZD5hIGNvZGUgdXNlZCBieSBhIENsaWVudCB0byB2ZXJpZnkKICAgICAgICAg IHRoZSBVc2VyIGhhcyBhdXRob3JpemVkIHRoZSBDbGllbnQgdG8gaGF2ZSBzcGVjaWZpYyBhY2Nl c3MgdG8gYQogICAgICAgICAgUHJvdGVjdGVkIFJlc291cmNlLgo8L2RkPgo8L2RsPjwvYmxvY2tx dW90ZT4KCjxhIG5hbWU9ImFuY2hvcjciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9 ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBh bGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7 VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjEi PjwvYT48aDM+My4xLiZuYnNwOwpVUkxzPC9oMz4KCjxwPjwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9 InRleHQiPjxkbD4KPGR0PkFjY2VzcyBUb2tlbiBVUkw6PC9kdD4KPGRkPnRoZSBBdXRob3JpemF0 aW9uIFNlcnZlciBVUkwgYXQKICAgICAgICAgICAgd2hpY2ggYW4gQWNjZXNzIFRva2VuIGlzIHJl cXVlc3RlZCBieSB0aGUgQ2xpZW50LiBUaGUgVVJMIG1heQogICAgICAgICAgICBhY2NlcHQgYSB2 YXJpZXR5IG9mIHBhcmFtZXRlcnMgZGVwZW5kaW5nIG9uIHRoZSBQcm9maWxlLiBBIFJlZnJlc2gK ICAgICAgICAgICAgVG9rZW4gbWF5IGFsc28gYmUgcmV0dXJuZWQgdG8gdGhlIENsaWVudC4gVGhp cyBVUkwgTVVTVCBiZSBhbgogICAgICAgICAgICBIVFRQUyBVUkwgYW5kIE1VU1QgYWx3YXlzIGJl IGNhbGxlZCB3aXRoIFBPU1QuCjwvZGQ+CjxkdD5DYWxsYmFjayBVUkw6PC9kdD4KPGRkPnRoZSBD bGllbnQgVVJMIHdoZXJlIHRoZSBVc2VyIHdpbGwgYmUKICAgICAgICAgICAgcmVkaXJlY3RlZCBh ZnRlciBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QgdG8gdGhlIEF1dGhvcml6YXRpb24KICAgICAg ICAgICAgU2VydmVyLgo8L2RkPgo8ZHQ+UmVmcmVzaCBUb2tlbiBVUkw6PC9kdD4KPGRkPnRoZSBB dXRob3JpemF0aW9uIFNlcnZlciBVUkwgYXQKICAgICAgICAgICAgd2hpY2ggYSBSZWZyZXNoIFRv a2VuIGlzIHByZXNlbnRlZCBpbiBleGNoYW5nZSBmb3IgYSBuZXcgQWNjZXNzCiAgICAgICAgICAg IFRva2VuIGlzIHJlcXVlc3RlZC4gVGhpcyBVUkwgTVVTVCBiZSBhbiBIVFRQUyBVUkwgYW5kIE1V U1QgYWx3YXlzCiAgICAgICAgICAgIGJlIGNhbGxlZCB3aXRoIFBPU1QuCjwvZGQ+CjxkdD5Vc2Vy IEF1dGhvcml6YXRpb24gVVJMOjwvZHQ+CjxkZD50aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgVVJM CiAgICAgICAgICAgIHdoZXJlIHRoZSBDbGllbnQgcmVkaXJlY3RzIHRoZSBVc2VyIHRvIG1ha2Ug YW4gYXV0aG9yaXphdGlvbgogICAgICAgICAgICByZXF1ZXN0Lgo8L2RkPgo8L2RsPjwvYmxvY2tx dW90ZT4KCjxhIG5hbWU9IlByb3RlY3RlZFJlc291cmNlIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJs ZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9 IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0 b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNl Y3Rpb24uNCI+PC9hPjxoMz40LiZuYnNwOwpBY2Nlc3NpbmcgYSBQcm90ZWN0ZWQgUmVzb3VyY2U8 L2gzPgoKPHA+Q2xpZW50cyBhbHdheXMgcHJlc2VudCBhbiBBY2Nlc3MgVG9rZW4gdG8gYWNjZXNz IGEgUHJvdGVjdGVkCiAgICAgIFJlc291cmNlLiBVc2Ugb2YgdGhlIEF1dGhvcml6YXRpb24gaGVh ZGVyIGlzIFJFQ09NTUVOREVELCBzaW5jZSBIVFRQCiAgICAgIGltcGxlbWVudGF0aW9ucyBhcmUg YXdhcmUgdGhhdCBBdXRob3JpemF0aW9uIGhlYWRlcnMgaGF2ZSBzcGVjaWFsCiAgICAgIHNlY3Vy aXR5IHByb3BlcnRpZXMgYW5kIG1heSByZXF1aXJlIHNwZWNpYWwgdHJlYXRtZW50IGluIGNhY2hl cyBhbmQKICAgICAgbG9ncy4gUHJvdGVjdGVkIFJlc291cmNlcyBTSE9VTEQgdGFrZSBwcmVjYXV0 aW9ucyB0byBpbnN1cmUgdGhhdCBBY2Nlc3MKICAgICAgVG9rZW5zIGFyZSBub3QgaW5hZHZlcnRl bnRseSBsb2dnZWQgb3IgY2FwdHVyZWQuIEluIGFkZGl0aW9uIHRvIHRoZQogICAgICBtZXRob2Rz IHByZXNlbnRlZCBoZXJlLCB0aGUgUHJvdGVjdGVkIFJlc291cmNlIE1BWSBhbGxvdyB0aGUgQ2xp ZW50IHRvCiAgICAgIHByZXNlbnQgdGhlIEFjY2VzcyBUb2tlbiB1c2luZyBhbnkgc2NoZW1lIGFn cmVlZCBvbiBieSB0aGUgQ2xpZW50IGFuZAogICAgICBQcm90ZWN0ZWQgUmVzb3VyY2UuCjwvcD4K PGEgbmFtZT0iYW5jaG9yOCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0 IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJy aWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJz cDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMSI+PC9hPjxo Mz40LjEuJm5ic3A7CkFjY2VzcyBUb2tlbjwvaDM+Cgo8cD5UaGUgZXhhY3QgZm9ybWF0IG9mIHRo ZSBBY2Nlc3MgVG9rZW4gaXMgb3BhcXVlIHRvIENsaWVudHMgYW5kIGlzCiAgICAgICAgb3V0IG9m IHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gSG93ZXZlciwgUHJvdGVjdGVkIFJlc291cmNl cyBNVVNUCiAgICAgICAgYmUgYWJsZSB0byB2ZXJpZnkgdGhhdCB0aGUgQWNjZXNzIFRva2VuIHdh cyBpc3N1ZWQgYnkgYSB0cnVzdGVkCiAgICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIGlz IHN0aWxsIHZhbGlkLiBBY2Nlc3MgVG9rZW5zIFNIT1VMRAogICAgICAgIHBlcmlvZGljYWxseSBl eHBpcmUuIFRoZSBleHBpcnkgdGltZSBvZiBBY2Nlc3MgVG9rZW5zIGlzIGRldGVybWluZWQgYXMK ICAgICAgICBhbiBhcHByb3ByaWF0ZSBiYWxhbmNlIGJldHdlZW4gZXhjZXNzaXZlIHJlc291cmNl IHV0aWxpemF0aW9uIGlmIHRvbwogICAgICAgIHNob3J0IGFuZCB1bmF1dGhvcml6ZWQgYWNjZXNz IGlmIHRvbyBsb25nLgo8L3A+CjxhIG5hbWU9ImFuY2hvcjkiPjwvYT48YnIgLz48aHIgLz4KPHRh YmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFz cz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0i I3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMu c2VjdGlvbi40LjIiPjwvYT48aDM+NC4yLiZuYnNwOwpBY3F1aXJpbmcgYW4gQWNjZXNzIFRva2Vu PC9oMz4KCjxwPkFuIEF1dGhvcml6YXRpb24gU2VydmVyIG1heSBzdXBwb3J0IG9uZSBvciBtb3Jl IHByb3RvY29sIHByb2ZpbGVzCiAgICAgICAgdGhhdCBlbmFibGUgYSBDbGllbnQgdG8gb2J0YWlu IGFuIEFjY2VzcyBUb2tlbiB0aGF0IGNhbiBiZSB1c2VkIHRvCiAgICAgICAgYWNjZXNzIGEgUHJv dGVjdGVkIFJlc291cmNlLgo8L3A+CjxwPkNsaWVudCBkZXZlbG9wZXJzIG9ubHkgbmVlZCB0byBp bXBsZW1lbnQgdGhlIHByb2ZpbGUocykgdGhhdCBhbGlnbgogICAgICAgIHdpdGggaG93IHRoZWly IGFwcGxpY2F0aW9uIHdpbGwgYmUgZGVwbG95ZWQgYW5kIGFyZSBzdXBwb3J0ZWQgYnkgdGhlCiAg ICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuCjwvcD4KPHA+QXV0aG9yaXphdGlvbiBTZXJ2ZXIg ZGV2ZWxvcGVycyBvbmx5IG5lZWQgdG8gaW1wbGVtZW50IHRoZQogICAgICAgIHByb2ZpbGUocykg dGhhdCBhcmUgYXBwcm9wcmlhdGUgZm9yIHRoZW0uCjwvcD4KPHA+UHJvdGVjdGVkIFJlc291cmNl IGRldmVsb3BlcnMgZG8gbm90IGltcGxlbWVudCBhIHByb2ZpbGUgYXMgdGhlCiAgICAgICAgQ2xp ZW50IGFsd2F5cyBpbnRlcmFjdHMgd2l0aCB0aGUgUHJvdGVjdGVkIFJlc291cmNlIGJ5IHByZXNl bnRpbmcgYW4KICAgICAgICBBY2Nlc3MgVG9rZW4uCjwvcD4KPHA+PGEgY2xhc3M9J2luZm8nIGhy ZWY9JyNQYXJhbUNvbic+U2VjdGlvbiZuYnNwOzc8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+UGFyYW1ldGVyIENvbnNpZGVyYXRpb25zPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBo YXMgZ2VuZXJhbCBpbmZvcm1hdGlvbiBhYm91dAogICAgICAgIHBhcmFtZXRlcnMgcGFzc2VkIHRv IGFuZCBmcm9tIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4KPC9wPgo8cD5TZWUgPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNhdXRvbm9tb3VzLnByb2ZpbGVzJz5TZWN0aW9uJm5ic3A7NTxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY3F1aXJpbmcgYW4gQWNjZXNzIFRva2VuOiBBdXRv bm9tb3VzIENsaWVudCBQcm9maWxlczwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gZm9yIGhvdyB0 aGUgQ2xpZW50CiAgICAgICAgYWNxdWlyZXMgYW4gQWNjZXNzIFRva2VuIHdoZW4gYWN0aW5nIGF1 dG9ub21vdXNseSwgYW5kIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdXNlci5wcm9maWxlcyc+U2Vj dGlvbiZuYnNwOzY8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QWNxdWlyaW5nIGFu IEFjY2VzcyBUb2tlbjogVXNlciBEZWxlZ2F0aW9uIFByb2ZpbGVzPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPiBmb3IgaG93IHRoZSBDbGllbnQgYWNxdWlyZXMgYW4gQWNjZXNzCiAgICAgICAgVG9r ZW4gd2hlbiBhY3RpbmcgYWN0aW5nIG9uIGJlaGFsZiBvZiBhIFVzZXIuCjwvcD4KPGEgbmFtZT0i YW5jaG9yMTAiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0 cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwv dGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjMiPjwvYT48aDM+NC4zLiZu YnNwOwpDbGllbnQgQ2FsbHMgUHJvdGVjdGVkIFJlc291cmNlIFVzaW5nIEhUVFAgSGVhZGVyPC9o Mz4KCjxwPlRoZSBQcm90ZWN0ZWQgUmVzb3VyY2UgU0hPVUxEIGVuYWJsZSBDbGllbnRzIHRvIGFj Y2VzcyB0aGUKICAgICAgICBQcm90ZWN0ZWQgUmVzb3VyY2UgYnkgaW5jbHVkaW5nIHRoZSBBY2Nl c3MgVG9rZW4gaW4gdGhlIEhUVFAKICAgICAgICBBdXRob3JpemF0aW9uIGhlYWRlciB1c2luZyB0 aGUgT0F1dGggV1JBUCBzY2hlbWUgd2l0aCB0aGUgZm9sbG93aW5nCiAgICAgICAgcGFyYW1ldGVy Ogo8L3A+CjxwPjwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmFjY2Vzc190 b2tlbjwvZHQ+CjxkZD4gUkVRVUlSRUQuIFRoZSB2YWx1ZSBvZiB0aGUKICAgICAgICAgICAgQWNj ZXNzIFRva2VuCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPgoKPHA+Rm9yIGV4YW1wbGUsIGlmIHRo ZSBBY2Nlc3MgVG9rZW4gaXMgdGhlIHN0cmluZyAxMjM0NTY3ODksIHRoZSBIVFRQCiAgICAgICAg aGVhZGVyIHdvdWxkIGJlOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAw OyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CiAgQXV0aG9yaXph dGlvbjogV1JBUCBhY2Nlc3NfdG9rZW49IjEyMzQ1Njc4OSIKPC9wcmU+PC9kaXY+CjxwPk5vdGUg dGhhdCBwZXIgc2VjdGlvbiAxLjIgb2YgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyNjE3Jz5b UkZDMjYxN108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RnJhbmtzLCBKLiwgSGFs bGFtLUJha2VyLCBQLiwgSG9zdGV0bGVyLCBKLiwgTGF3cmVuY2UsIFMuLCBMZWFjaCwgUC4sIEx1 b3RvbmVuLCBBLiwgYW5kIEwuIFN0ZXdhcnQsICZsZHF1bztIVFRQIEF1dGhlbnRpY2F0aW9uOiBC YXNpYyBhbmQgRGlnZXN0IEFjY2VzcyBBdXRoZW50aWNhdGlvbiwmcmRxdW87IEp1bmUmbmJzcDsx OTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gdGhhdAogICAgICAgIHRoZSBmb2xsb3dpbmcg aGVhZGVyIGlzIGFsc28gdmFsaWQ6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lk dGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICBBdXRo b3JpemF0aW9uOiAgV1JBUCAgYWNjZXNzX3Rva2VuID0gMTIzNDU2Nzg5CjwvcHJlPjwvZGl2Pgo8 cD5JZiB0aGUgQWNjZXNzIFRva2VuIGhhcyBleHBpcmVkIG9yIGlzIGludmFsaWQsIHRoZSBQcm90 ZWN0ZWQKICAgICAgICBSZXNvdXJjZSBNVVNUIHJldHVybjoKPC9wPjxkaXYgc3R5bGU9J2Rpc3Bs YXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRv Jz48cHJlPgogIEhUVFAgNDAxIFVuYXV0aG9yaXplZAo8L3ByZT48L2Rpdj4KPHA+YW5kIHRoZSBI VFRQIGhlYWRlcjoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFy Z2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgogIFdXVy1BdXRoZW50aWNh dGU6IFdSQVAKPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjExIj48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uNC40Ij48L2E+PGgzPjQuNC4mbmJzcDsKQ2xpZW50IENhbGxzIFByb3RlY3Rl ZCBSZXNvdXJjZSBVc2luZyBVUkwgUXVlcnkgUGFyYW1ldGVyPC9oMz4KCjxwPlRoZSBQcm90ZWN0 ZWQgUmVzb3VyY2UgTUFZIGFsbG93IHRoZSBDbGllbnQgdG8gYWNjZXNzIHByb3RlY3RlZAogICAg ICAgIHJlc291cmNlcyBhdCB0aGUgUHJvdGVjdGVkIFJlc291cmNlIGJ5IGluY2x1ZGluZyB0aGUg Zm9sbG93aW5nIEhUVFAKICAgICAgICBVUkwgcXVlcnkgcGFyYW1ldGVyIGluIHRoZSBVUkw6Cjwv cD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+YWNjZXNzX3Rva2Vu PC9kdD4KPGRkPiBSRVFVSVJFRC4gVGhlIHZhbHVlIG9mIHRoZQogICAgICAgICAgICBBY2Nlc3Mg VG9rZW4KPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+Cgo8cD5JZiB0aGUgQWNjZXNzIFRva2VuIGhh cyBleHBpcmVkIG9yIGlzIGludmFsaWQsIHRoZSBQcm90ZWN0ZWQKICAgICAgICBSZXNvdXJjZSBN VVNUIHJldHVybjoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFy Z2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgogIEhUVFAgNDAxIFVuYXV0 aG9yaXplZAo8L3ByZT48L2Rpdj4KPHA+YW5kIHRoZSBIVFRQIGhlYWRlcjoKPC9wPjxkaXYgc3R5 bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJp Z2h0OiBhdXRvJz48cHJlPgogIFdXVy1BdXRoZW50aWNhdGU6IFdSQVAKPC9wcmU+PC9kaXY+Cjxh IG5hbWU9ImFuY2hvcjEyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC41Ij48L2E+PGgz PjQuNS4mbmJzcDsKQ2xpZW50IENhbGxzIFByb3RlY3RlZCBSZXNvdXJjZSBVc2luZyBQb3N0IFBh cmFtZXRlcjwvaDM+Cgo8cD5UaGUgUHJvdGVjdGVkIFJlc291cmNlIE1BWSBhbGxvdyB0aGUgQ2xp ZW50IHRvIGFjY2VzcyBwcm90ZWN0ZWQKICAgICAgICByZXNvdXJjZXMgYXQgdGhlIFByb3RlY3Rl ZCBSZXNvdXJjZSBieSBpbmNsdWRpbmcgdGhlIGZvbGxvd2luZwogICAgICAgIHBhcmFtZXRlciBp biB0aGUgYm9keSBvZiBhIEhUVFAgcG9zdCBtZXNzYWdlIGZvcm1hdHRlZCBhcwogICAgICAgIGFw cGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCBwZXIgPGEgaHJlZj0naHR0cDovL3d3dy53 My5vcmcvVFIvMTk5OS9SRUMtVzNDLlJFQy1odG1sNDAtMTk5ODA0MjQtMTk5OTEyMjQvaW50ZXJh Y3QvZm9ybXMuaHRtbCNoLTE3LjEzLjQuMSc+MTcuMTMuNDwvYT4KICAgICAgICBvZiA8YSBjbGFz cz0naW5mbycgaHJlZj0nI1czQy5SRUMtaHRtbDQwLTE5OTgwNDI0Jz5IVE1MIDQuMDE8c3Bhbj4g KDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SG9ycywgQS4sIEphY29icywgSS4sIGFuZCBELiBS YWdnZXR0LCAmbGRxdW87SFRNTCA0LjAgU3BlY2lmaWNhdGlvbiwmcmRxdW87IEFwcmlsJm5ic3A7 MTk5OC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtXM0MuUkVDJiM4MjA5O2h0bWw0MCYjODIw OTsxOTk4MDQyNF06CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8 ZHQ+YWNjZXNzX3Rva2VuPC9kdD4KPGRkPiBSRVFVSVJFRC4gVGhlIHZhbHVlIG9mIHRoZQogICAg ICAgICAgICBBY2Nlc3MgVG9rZW4KPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+Cgo8cD5JZiB0aGUg QWNjZXNzIFRva2VuIGhhcyBleHBpcmVkIG9yIGlzIGludmFsaWQsIHRoZSBQcm90ZWN0ZWQKICAg ICAgICBSZXNvdXJjZSBNVVNUIHJldHVybjoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxl OyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgog IEhUVFAgNDAxIFVuYXV0aG9yaXplZAo8L3ByZT48L2Rpdj4KPHA+YW5kIHRoZSBIVFRQIGhlYWRl cjoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6 IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgogIFdXVy1BdXRoZW50aWNhdGU6IFdSQVAK PC9wcmU+PC9kaXY+CjxhIG5hbWU9ImF1dG9ub21vdXMucHJvZmlsZXMiPjwvYT48YnIgLz48aHIg Lz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy IiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEg aHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1l PSJyZmMuc2VjdGlvbi41Ij48L2E+PGgzPjUuJm5ic3A7CkFjcXVpcmluZyBhbiBBY2Nlc3MgVG9r ZW46IEF1dG9ub21vdXMgQ2xpZW50IFByb2ZpbGVzPC9oMz4KCjxwPlRoZXNlIGFyZSB0aGUgcHJv ZmlsZXMgdGhlIENsaWVudCB1c2VzIHdoZW4gYWN0aW5nIGF1dG9ub21vdXNseS4KPC9wPgo8YSBu YW1lPSJwMSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjUuMSI+PC9hPjxoMz41LjEuJm5i c3A7CkNsaWVudCBBY2NvdW50IGFuZCBQYXNzd29yZCBQcm9maWxlPC9oMz4KCjxwPlRoaXMgcHJv ZmlsZSBpcyBzdWl0YWJsZSB3aGVuIHRoZSBDbGllbnQgaXMgYW4gYXBwbGljYXRpb24gY2FsbGlu ZwogICAgICAgIHRoZSBQcm90ZWN0ZWQgUmVzb3VyY2Ugb24gYmVoYWxmIG9mIGFuIG9yZ2FuaXph dGlvbiBhbmQgdGhlCiAgICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYWNjZXB0cyBhY2NvdW50 IHBhc3N3b3JkcyBmb3IgYXV0aGVudGljYXRpb24uCiAgICAgICAgVGhpcyBlbmFibGVzIHRoZSBB dXRob3JpemF0aW9uIFNlcnZlciB0byB1c2UgYW4gZXhpc3RpbmcKICAgICAgICBhdXRoZW50aWNh dGlvbiBtZWNoYW5pc20uIFRoaXMgcHJvZmlsZSBTSE9VTEQgTk9UIGJlIHVzZWQgd2hlbiB0aGUK ICAgICAgICBDbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBhIHVzZXIuIFByb2ZpbGVzIDxh IGNsYXNzPSdpbmZvJyBocmVmPScjcDMnPjYuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5Vc2VybmFtZSBhbmQgUGFzc3dvcmQgUHJvZmlsZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwv YT4sIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcDQnPjYuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs YXNzPSdpbmZvJz5XZWIgQXBwIFByb2ZpbGU8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IG9yCiAg ICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNwNSc+Ni4zPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPlJpY2ggQXBwIFByb2ZpbGU8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IGFy ZSBSRUNPTU1FTkRFRCB3aGVuIGEKICAgICAgICBDbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFsZiBv ZiBhIFVzZXIuCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxl IHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0i VE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3Rv YyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2Vj dGlvbi41LjEuMSI+PC9hPjxoMz41LjEuMS4mbmJzcDsKUHJvdmlzaW9uaW5nPC9oMz4KCjxwPlBy aW9yIHRvIGluaXRpYXRpbmcgdGhpcyBwcm90b2NvbCBwcm9maWxlLCB0aGUgQ2xpZW50IE1VU1Qg aGF2ZQogICAgICAgICAgb2J0YWluZWQgYW4gYWNjb3VudCBuYW1lIGFuZCBhY2NvdW50IHBhc3N3 b3JkIGZyb20gdGhlIEF1dGhvcml6YXRpb24KICAgICAgICAgIFNlcnZlci4KPC9wPgo8YSBuYW1l PSJwMXJlcXVlc3QiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi41LjEuMiI+PC9hPjxoMz41 LjEuMi4mbmJzcDsKQ2xpZW50IFJlcXVlc3RzIEFjY2VzcyBUb2tlbjwvaDM+Cgo8cD5UaGUgQ2xp ZW50IG1ha2VzIGFuIEhUVFBTIHJlcXVlc3QgdG8gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyJ3MK ICAgICAgICAgIEFjY2VzcyBUb2tlbiBVUkwgdXNpbmcgUE9TVC4gVGhlIHJlcXVlc3QgY29udGFp bnMgdGhlIGZvbGxvd2luZwogICAgICAgICAgcGFyYW1ldGVyczoKPC9wPgo8cD48L3A+CjxibG9j a3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD53cmFwX25hbWU8L2R0Pgo8ZGQ+IFJFUVVJUkVE LiBUaGUgYWNjb3VudAogICAgICAgICAgICAgIG5hbWUuCjwvZGQ+CjxkdD53cmFwX3Bhc3N3b3Jk PC9kdD4KPGRkPiBSRVFVSVJFRC4gVGhlIGFjY291bnQKICAgICAgICAgICAgICBwYXNzd29yZC4K PC9kZD4KPGR0PndyYXBfc2NvcGU8L2R0Pgo8ZGQ+IE9QVElPTkFMLiBUaGUgQXV0aG9yaXphdGlv bgogICAgICAgICAgICAgIFNlcnZlciBNQVkgZGVmaW5lIGF1dGhvcml6YXRpb24gc2NvcGUgdmFs dWVzIGZvciB0aGUgQ2xpZW50IHRvCiAgICAgICAgICAgICAgaW5jbHVkZS4KPC9kZD4KPGR0PkFk ZGl0aW9uYWwgcGFyYW1ldGVyczwvZHQ+CjxkZD5BbnkgYWRkaXRpb25hbAogICAgICAgICAgICAg IHBhcmFtZXRlcnMsIGFzIGRlZmluZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLgo8L2Rk Pgo8L2RsPjwvYmxvY2txdW90ZT4KCjxhIG5hbWU9ImFuY2hvcjE0Ij48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uNS4xLjMiPjwvYT48aDM+NS4xLjMuJm5ic3A7ClN1Y2Nlc3NmdWwgQWNjZXNz IFRva2VuIFJlc3BvbnNlIGZyb20gQXV0aG9yaXphdGlvbiAgU2VydmVyPC9oMz4KCjxwPklmIHN1 Y2Nlc3NmdWwsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciByZXR1cm5zOgo8L3A+PGRpdiBzdHls ZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmln aHQ6IGF1dG8nPjxwcmU+CiAgSFRUUCAyMDAgT0sKPC9wcmU+PC9kaXY+CjxwPndpdGggdGhlIFJl ZnJlc2ggVG9rZW4gYW5kIGFuIEFjY2VzcyBUb2tlbiBpbiB0aGUgcmVzcG9uc2UgYm9keS4KICAg ICAgICAgIFRoZSByZXNwb25zZSBib2R5IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVy czoKPC9wPgo8cD48L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD53cmFwX3Jl ZnJlc2hfdG9rZW48L2R0Pgo8ZGQ+IFJFUVVJUkVELiBUaGUKICAgICAgICAgICAgICBSZWZyZXNo IFRva2VuLgo8L2RkPgo8ZHQ+d3JhcF9hY2Nlc3NfdG9rZW48L2R0Pgo8ZGQ+IFJFUVVJUkVELiBU aGUgQWNjZXNzCiAgICAgICAgICAgICAgVG9rZW4uCjwvZGQ+CjxkdD53cmFwX2FjY2Vzc190b2tl bl9leHBpcmVzX2luPC9kdD4KPGRkPiBPUFRJT05BTC4KICAgICAgICAgICAgICBUaGUgbGlmZXRp bWUgb2YgdGhlIEFjY2VzcyBUb2tlbiBpbiBzZWNvbmRzLiBGb3IgZXhhbXBsZSwgMzYwMAogICAg ICAgICAgICAgIHJlcHJlc2VudHMgb25lIGhvdXIuCjwvZGQ+CjxkdD5BZGRpdGlvbmFsIHBhcmFt ZXRlcnM8L2R0Pgo8ZGQ+IEFueSBhZGRpdGlvbmFsCiAgICAgICAgICAgICAgcGFyYW1ldGVycywg YXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuCjwvZGQ+CjwvZGw+PC9ibG9j a3F1b3RlPgoKPHA+VGhlIENsaWVudCBtYXkgbm93IHVzZSB0aGUgQWNjZXNzIFRva2VuIHRvIGFj Y2VzcyB0aGUgUHJvdGVjdGVkCiAgICAgICAgICBSZXNvdXJjZSBwZXIgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNQcm90ZWN0ZWRSZXNvdXJjZSc+U2VjdGlvbiZuYnNwOzQ8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzaW5nIGEgUHJvdGVjdGVkIFJlc291cmNlPC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPgo8L3A+CjxhIG5hbWU9ImFuY2hvcjE1Ij48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uNS4xLjQiPjwvYT48aDM+NS4xLjQuJm5ic3A7ClVuc3VjY2Vzc2Z1bCBBY2Nl c3MgVG9rZW4gUmVzcG9uc2UgZnJvbSBBdXRob3JpemF0aW9uIFNlcnZlcjwvaDM+Cgo8cD5JZiB0 aGUgQ2xpZW50IGFjY291bnQgbmFtZSBhbmQgcGFzc3dvcmQgYXJlIGludmFsaWQsIHRoZQogICAg ICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXNwb25kIHdpdGg6CjwvcD48ZGl2IHN0 eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1y aWdodDogYXV0byc+PHByZT4KICBIVFRQIDQwMSBVbmF1dGhvcml6ZWQKPC9wcmU+PC9kaXY+Cjxw PmFuZCB0aGUgSFRUUCBoZWFkZXI6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lk dGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICBXV1ct QXV0aGVudGljYXRlOiBXUkFQCjwvcHJlPjwvZGl2Pgo8cD5UaGUgQ2xpZW50IE1VU1Qgb2J0YWlu IGEgdmFsaWQgYWNjb3VudCBuYW1lIGFuZCBwYXNzd29yZCBiZWZvcmUKICAgICAgICAgIHJldHJ5 aW5nIHRoZSByZXF1ZXN0Lgo8L3A+CjxhIG5hbWU9ImFuY2hvcjE2Ij48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uNS4xLjUiPjwvYT48aDM+NS4xLjUuJm5ic3A7CkNsaWVudCBSZWZyZXNoZXMg QWNjZXNzIFRva2VuPC9oMz4KCjxwPkF1dGhvcml6YXRpb24gU2VydmVycyBTSE9VTEQgaXNzdWUg QWNjZXNzIFRva2VucyB0aGF0IGV4cGlyZSBhbmQKICAgICAgICAgIHJlcXVpcmUgQ2xpZW50cyB0 byByZWZyZXNoIHRoZW0uIFVwb24gcmVjZWl2aW5nIHRoZSBIVFRQIDQwMQogICAgICAgICAgcmVz cG9uc2Ugd2hlbiBhY2Nlc3NpbmcgcHJvdGVjdGVkIHJlc291cmNlcyBwZXIgPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNQcm90ZWN0ZWRSZXNvdXJjZSc+U2VjdGlvbiZuYnNwOzQ8c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzaW5nIGEgUHJvdGVjdGVkIFJlc291cmNlPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPiwgdGhlIENsaWVudCBzaG91bGQgcmVxdWVzdCBhIG5ldwogICAg ICAgICAgQWNjZXNzIFRva2VuIGJ5IHJlcGVhdGluZyA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Ax cmVxdWVzdCc+U2VjdGlvbiZuYnNwOzUuMS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2lu Zm8nPkNsaWVudCBSZXF1ZXN0cyBBY2Nlc3MgVG9rZW48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ CjwvcD4KPGEgbmFtZT0icDIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi41LjIiPjwvYT48 aDM+NS4yLiZuYnNwOwpBc3NlcnRpb24gUHJvZmlsZTwvaDM+Cgo8YSBuYW1lPSJhbmNob3IxNyI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjUuMi4xIj48L2E+PGgzPjUuMi4xLiZuYnNwOwpQ cm92aXNpb25pbmc8L2gzPgoKPHA+UHJpb3IgdG8gaW5pdGlhdGluZyB0aGlzIHByb3RvY29sIHBy b2ZpbGUsIHRoZSBDbGllbnQgTVVTVCBoYXZlIGEKICAgICAgICAgIG1lY2hhbmlzbSBmb3Igb2J0 YWluZWQgYW4gYXNzZXJ0aW9uIGZyb20gYW4gYXNzZXJ0aW9uIGlzc3VlciB0aGF0CiAgICAgICAg ICBjYW4gYmUgcHJlc2VudGVkIHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBmb3IgYWNjZXNz IHRvIHRoZQogICAgICAgICAgUHJvdGVjdGVkIFJlc291cmNlLgo8L3A+CjxhIG5hbWU9InAyLmFz c2VydGlvbiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjUuMi4yIj48L2E+PGgzPjUuMi4y LiZuYnNwOwpDbGllbnQgT2J0YWlucyBBc3NlcnRpb248L2gzPgoKPHA+VGhlIENsaWVudCBvYnRh aW5zIGFuIGFzc2VydGlvbi4gVGhlIHByb2Nlc3MgZm9yIG9idGFpbmluZyB0aGUKICAgICAgICAg IGFzc2VydGlvbiBpcyBkZWZpbmVkIGJ5IHRoZSBhc3NlcnRpb24gaXNzdWVyIGFuZCB0aGUgQXV0 aG9yaXphdGlvbgogICAgICAgICAgU2VydmVyLCBhbmQgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMg c3BlY2lmaWNhdGlvbi4KPC9wPgo8YSBuYW1lPSJwMi5yZXF1ZXN0Ij48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uNS4yLjMiPjwvYT48aDM+NS4yLjMuJm5ic3A7CkNsaWVudCBSZXF1ZXN0cyBB Y2Nlc3MgVG9rZW48L2gzPgoKPHA+VGhlIENsaWVudCBtYWtlcyBhbiBIVFRQUyByZXF1ZXN0IHRv IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcidzCiAgICAgICAgICBBY2Nlc3MgVG9rZW4gVVJMIHVz aW5nIFBPU1QuIFRoZSByZXF1ZXN0IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcKICAgICAgICAgIHBh cmFtZXRlcnM6CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+ d3JhcF9hc3NlcnRpb25fZm9ybWF0PC9kdD4KPGRkPiBSRVFVSVJFRC4gVGhlCiAgICAgICAgICAg ICAgZm9ybWF0IG9mIHRoZSBhc3NlcnRpb24gYXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXphdGlv bgogICAgICAgICAgICAgIFNlcnZlci4KPC9kZD4KPGR0PndyYXBfYXNzZXJ0aW9uPC9kdD4KPGRk PiBSRVFVSVJFRC4gVGhlCiAgICAgICAgICAgICAgYXNzZXJ0aW9uLgo8L2RkPgo8ZHQ+d3JhcF9z Y29wZTwvZHQ+CjxkZD4gT1BUSU9OQUwuIFRoZSBBdXRob3JpemF0aW9uCiAgICAgICAgICAgICAg U2VydmVyIE1BWSBkZWZpbmUgYXV0aG9yaXphdGlvbiBzY29wZSB2YWx1ZXMgZm9yIHRoZSBDbGll bnQgdG8KICAgICAgICAgICAgICBpbmNsdWRlCjwvZGQ+CjxkdD5BZGRpdGlvbmFsICAgIHBhcmFt ZXRlcnM8L2R0Pgo8ZGQ+IEFueSBhZGRpdGlvbmFsCiAgICAgICAgICAgICAgcGFyYW1ldGVycywg YXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuCjwvZGQ+CjwvZGw+PC9ibG9j a3F1b3RlPgoKPGEgbmFtZT0iYW5jaG9yMTgiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi41 LjIuNCI+PC9hPjxoMz41LjIuNC4mbmJzcDsKU3VjY2Vzc2Z1bCBBY2Nlc3MgVG9rZW4gUmVzcG9u c2UgZnJvbSBBdXRob3JpemF0aW9uIFNlcnZlcjwvaDM+Cgo8cD5JZiBzdWNjZXNzZnVsLCB0aGUg QXV0aG9yaXphdGlvbiBTZXJ2ZXIgcmV0dXJuczoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRh YmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJl PgogIEhUVFAgMjAwIE9LCjwvcHJlPjwvZGl2Pgo8cD53aXRoIHRoZSBBY2Nlc3MgVG9rZW4gaW4g dGhlIHJlc3BvbnNlIGJvZHkuIFRoZSByZXNwb25zZSBib2R5CiAgICAgICAgICBjb250YWlucyB0 aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFzcz0i dGV4dCI+PGRsPgo8ZHQ+d3JhcF9hY2Nlc3NfdG9rZW48L2R0Pgo8ZGQ+IFJFUVVJUkVELiBUaGUg QWNjZXNzCiAgICAgICAgICAgICAgVG9rZW4uCjwvZGQ+CjxkdD53cmFwX2FjY2Vzc190b2tlbl9l eHBpcmVzX2luPC9kdD4KPGRkPiBPUFRJT05BTC4KICAgICAgICAgICAgICBUaGUgbGlmZXRpbWUg b2YgdGhlIEFjY2VzcyBUb2tlbiBpbiBzZWNvbmRzLiBGb3IgZXhhbXBsZSwgMzYwMAogICAgICAg ICAgICAgIHJlcHJlc2VudHMgb25lIGhvdXIuCjwvZGQ+CjxkdD5BZGRpdGlvbmFsICAgIHBhcmFt ZXRlcnM8L2R0Pgo8ZGQ+IEFueSBhZGRpdGlvbmFsCiAgICAgICAgICAgICAgcGFyYW1ldGVycywg YXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuCjwvZGQ+CjwvZGw+PC9ibG9j a3F1b3RlPgoKPHA+VGhlIENsaWVudCBtYXkgbm93IHVzZSB0aGUgQWNjZXNzIFRva2VuIHRvIGFj Y2VzcyB0aGUgUHJvdGVjdGVkCiAgICAgICAgICBSZXNvdXJjZSBwZXIgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNQcm90ZWN0ZWRSZXNvdXJjZSc+U2VjdGlvbiZuYnNwOzQ8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzaW5nIGEgUHJvdGVjdGVkIFJlc291cmNlPC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPi4KPC9wPgo8YSBuYW1lPSJhbmNob3IxOSI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjUuMi41Ij48L2E+PGgzPjUuMi41LiZuYnNwOwpVbnN1Y2Nlc3NmdWwgQWNj ZXNzIFRva2VuIFJlc3BvbnNlIGZyb20gQXV0aG9yaXphdGlvbiBTZXJ2ZXI8L2gzPgoKPHA+SWYg dGhlIGFzc2VydGlvbiBpcyBub3QgdmFsaWQsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNU CiAgICAgICAgICByZXNwb25kIHdpdGg6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICBI VFRQIDQwMSBVbmF1dGhvcml6ZWQKPC9wcmU+PC9kaXY+CjxwPmFuZCB0aGUgSFRUUCBoZWFkZXI6 CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAz ZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICBXV1ctQXV0aGVudGljYXRlOiBXUkFQCjwv cHJlPjwvZGl2Pgo8cD5UaGUgQ2xpZW50IE1VU1Qgb2J0YWluIGEgdmFsaWQgYXNzZXJ0aW9uIGJ5 IHJlcGVhdGluZyA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3AyLmFzc2VydGlvbic+U2VjdGlvbiZu YnNwOzUuMi4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNsaWVudCBPYnRhaW5z IEFzc2VydGlvbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gYmVmb3JlIHJldHJ5aW5nIHRoZSBy ZXF1ZXN0Lgo8L3A+CjxhIG5hbWU9ImFuY2hvcjIwIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uNS4yLjYiPjwvYT48aDM+NS4yLjYuJm5ic3A7CkNsaWVudCBSZWZyZXNoZXMgQWNjZXNzIFRv a2VuPC9oMz4KCjxwPkF1dGhvcml6YXRpb24gU2VydmVycyBTSE9VTEQgaXNzdWUgQWNjZXNzIFRv a2VucyB0aGF0IGV4cGlyZSBhbmQKICAgICAgICAgIHJlcXVpcmUgQ2xpZW50cyB0byByZWZyZXNo IHRoZW0uIFVwb24gcmVjZWl2aW5nIHRoZSBIVFRQIDQwMQogICAgICAgICAgcmVzcG9uc2Ugd2hl biBhY2Nlc3NpbmcgcHJvdGVjdGVkIHJlc291cmNlcyBwZXIgPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNQcm90ZWN0ZWRSZXNvdXJjZSc+U2VjdGlvbiZuYnNwOzQ8c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+QWNjZXNzaW5nIGEgUHJvdGVjdGVkIFJlc291cmNlPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPiwgdGhlIENsaWVudCBzaG91bGQgcmVxdWVzdCBhIG5ldwogICAgICAgICAgQWNj ZXNzIFRva2VuIGJ5IHJlcGVhdGluZyA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3AyLnJlcXVlc3Qn PlNlY3Rpb24mbmJzcDs1LjIuMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5DbGll bnQgUmVxdWVzdHMgQWNjZXNzIFRva2VuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBpZiB0aGUK ICAgICAgICAgIGFzc2VydGlvbiBpcyBzdGlsbCB2YWxpZCwgb3RoZXJ3aXNlIHRoZSBDbGllbnQg TVVTVCBvYnRhaW4gYSBuZXcsCiAgICAgICAgICB2YWxpZCBhc3NlcnRpb24gYnkgcmVwZWF0aW5n IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcDIuYXNzZXJ0aW9uJz5TZWN0aW9uJm5ic3A7NS4yLjI8 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q2xpZW50IE9idGFpbnMgQXNzZXJ0aW9u PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KPC9wPgo8YSBuYW1lPSJ1c2VyLnByb2ZpbGVzIj48 L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNz PSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90 YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNiI+PC9hPjxoMz42LiZuYnNwOwpBY3F1aXJpbmcg YW4gQWNjZXNzIFRva2VuOiBVc2VyIERlbGVnYXRpb24gUHJvZmlsZXM8L2gzPgoKPHA+VGhlc2Ug YXJlIHRoZSBwcm9maWxlcyB0aGUgQ2xpZW50IHVzZXMgd2hlbiBhY3Rpbmcgb24gYmVoYWxmIG9m IGEKICAgICAgVXNlci4KPC9wPgo8YSBuYW1lPSJwMyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0 aW9uLjYuMSI+PC9hPjxoMz42LjEuJm5ic3A7ClVzZXJuYW1lIGFuZCBQYXNzd29yZCBQcm9maWxl PC9oMz4KCjxwPlRoaXMgcHJvZmlsZSBpcyBzdWl0YWJsZSB3aGVyZSB0aGUgQ2xpZW50IGlzIGFu IGFwcGxpY2F0aW9uIHRoZQogICAgICAgIFVzZXIgaGFzIGluc3RhbGxlZCBvbiB0aGVpciBjb21w dXRlciBhbmQgdGhlIFVzZXIgdXNlcyBhIHVzZXJuYW1lIGFuZAogICAgICAgIHBhc3N3b3JkIHRv IGF1dGhlbnRpY2F0ZSB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIFRoaXMgcHJvZmlsZQog ICAgICAgIGVuYWJsZXMgYSBDbGllbnQgdG8gYWN0IG9uIGJlaGFsZiBvZiB0aGUgVXNlciB3aXRo b3V0IGhhdmluZyB0bwogICAgICAgIHBlcm1hbmVudGx5IHN0b3JlIHRoZSBVc2VyJ3MgdXNlcm5h bWUgYW5kIHBhc3N3b3JkLgo8L3A+CjxhIG5hbWU9ImFuY2hvcjIxIj48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uNi4xLjEiPjwvYT48aDM+Ni4xLjEuJm5ic3A7ClByb3Zpc2lvbmluZzwvaDM+ Cgo8cD5QcmlvciB0byBpbml0aWF0aW5nIHRoaXMgcHJvdG9jb2wgcHJvZmlsZSwgdGhlIEF1dGhv cml6YXRpb24KICAgICAgICAgIFNlcnZlciBNQVkgaGF2ZSByZXF1aXJlZCB0aGUgQ2xpZW50IHRv IGhhdmUgb2J0YWluZWQgYSBDbGllbnQKICAgICAgICAgIElkZW50aWZpZXIgZnJvbSB0aGUgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIuCjwvcD4KPGEgbmFtZT0icDMucGFzc3dvcmQiPjwvYT48YnIgLz48 aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+ PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBu YW1lPSJyZmMuc2VjdGlvbi42LjEuMiI+PC9hPjxoMz42LjEuMi4mbmJzcDsKQ2xpZW50IE9idGFp bnMgVXNlcm5hbWUgYW5kICAgICAgUGFzc3dvcmQ8L2gzPgoKPHA+VGhlIENsaWVudCBvYnRhaW5z IHRoZSBVc2VyJ3MgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIGZyb20gdGhlCiAgICAgICAgICB1c2Vy LiBUaGUgQ2xpZW50IE1VU1QgZGlzY2FyZCB0aGUgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIG9uY2Ug YW4KICAgICAgICAgIEFjY2VzcyBUb2tlbiBoYXMgYmVlbiBvYnRhaW5lZC4KPC9wPgo8YSBuYW1l PSJwMy5yZXF1ZXN0Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi4xLjMiPjwvYT48aDM+ Ni4xLjMuJm5ic3A7CkNsaWVudCBSZXF1ZXN0cyBBY2Nlc3MgVG9rZW48L2gzPgoKPHA+VGhlIENs aWVudCBtYWtlcyBhbiBIVFRQUyByZXF1ZXN0IHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcidz CiAgICAgICAgICBBY2Nlc3MgVG9rZW4gVVJMIHVzaW5nIFBPU1QuIFRoZSByZXF1ZXN0IGNvbnRh aW5zIHRoZSBmb2xsb3dpbmcKICAgICAgICAgIHBhcmFtZXRlcnM6CjwvcD4KPHA+PC9wPgo8Ymxv Y2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+d3JhcF9jbGllbnRfaWQ8L2R0Pgo8ZGQ+IFJF UVVJUkVELiBUaGUgQ2xpZW50CiAgICAgICAgICAgICAgSWRlbnRpZmllci4KPC9kZD4KPGR0Pndy YXBfdXNlcm5hbWU8L2R0Pgo8ZGQ+IFJFUVVJUkVELiBUaGUgVXNlcidzCiAgICAgICAgICAgICAg dXNlcm5hbWUuCjwvZGQ+CjxkdD53cmFwX3Bhc3N3b3JkPC9kdD4KPGRkPiBSRVFVSVJFRC4gVGhl IFVzZXIncwogICAgICAgICAgICAgIHBhc3N3b3JkLgo8L2RkPgo8ZHQ+d3JhcF9zY29wZTwvZHQ+ CjxkZD4gT1BUSU9OQUwuIFRoZSBBdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgU2VydmVyIE1B WSBkZWZpbmUgYXV0aG9yaXphdGlvbiBzY29wZSB2YWx1ZXMgZm9yIHRoZSBDbGllbnQgdG8KICAg ICAgICAgICAgICBpbmNsdWRlLgo8L2RkPgo8ZHQ+QWRkaXRpb25hbCBwYXJhbWV0ZXJzPC9kdD4K PGRkPiBBbnkgYWRkaXRpb25hbAogICAgICAgICAgICAgIHBhcmFtZXRlcnMsIGFzIGRlZmluZWQg YnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KCjxh IG5hbWU9ImFuY2hvcjIyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi4xLjQiPjwvYT48 aDM+Ni4xLjQuJm5ic3A7ClN1Y2Nlc3NmdWwgQWNjZXNzIFRva2VuIFJlc3BvbnNlIGZyb20gQXV0 aG9yaXphdGlvbiBTZXJ2ZXI8L2gzPgoKPHA+SWYgc3VjY2Vzc2Z1bCwgdGhlIEF1dGhvcml6YXRp b24gU2VydmVyIHJldHVybnM6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6 IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICBIVFRQIDIw MCBPSwo8L3ByZT48L2Rpdj4KPHA+d2l0aCB0aGUgQWNjZXNzIFRva2VuIGluIHRoZSByZXNwb25z ZSBib2R5LiBUaGUgcmVzcG9uc2UgYm9keQogICAgICAgICAgY29udGFpbnMgdGhlIGZvbGxvd2lu ZyBwYXJhbWV0ZXJzOgo8L3A+CjxwPjwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4K PGR0PndyYXBfYWNjZXNzX3Rva2VuPC9kdD4KPGRkPiBSRVFVSVJFRC4gVGhlIEFjY2VzcwogICAg ICAgICAgICAgIFRva2VuLgo8L2RkPgo8ZHQ+d3JhcF9hY2Nlc3NfdG9rZW5fZXhwaXJlc19pbjwv ZHQ+CjxkZD4gT1BUSU9OQUwuCiAgICAgICAgICAgICAgVGhlIGxpZmV0aW1lIG9mIHRoZSBBY2Nl c3MgVG9rZW4gaW4gc2Vjb25kcy4gRm9yIGV4YW1wbGUsIDM2MDAKICAgICAgICAgICAgICByZXBy ZXNlbnRzIG9uZSBob3VyLgo8L2RkPgo8ZHQ+QWRkaXRpb25hbCAgICBwYXJhbWV0ZXJzPC9kdD4K PGRkPiBBbnkgYWRkaXRpb25hbAogICAgICAgICAgICAgIHBhcmFtZXRlcnMsIGFzIGRlZmluZWQg YnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KCjxw PlRoZSBDbGllbnQgTVVTVCBkaXNjYXJkIHRoZSBVc2VyJ3MgdXNlcm5hbWUgYW5kIHBhc3N3b3Jk LiBUaGUKICAgICAgICAgIENsaWVudCBzZWN1cmVseSBzdG9yZXMgdGhlIFJlZnJlc2ggVG9rZW4g Zm9yIGxhdGVyIHVzZS4gVGhlIENsaWVudAogICAgICAgICAgbWF5IG5vdyB1c2UgdGhlIEFjY2Vz cyBUb2tlbiB0byBhY2Nlc3MgdGhlIFByb3RlY3RlZCBSZXNvdXJjZSBwZXIKICAgICAgICAgIDxh IGNsYXNzPSdpbmZvJyBocmVmPScjUHJvdGVjdGVkUmVzb3VyY2UnPlNlY3Rpb24mbmJzcDs0PHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2Vzc2luZyBhIFByb3RlY3RlZCBSZXNv dXJjZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjMiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjEuNSI+PC9hPjxoMz42LjEuNS4mbmJzcDsKVW5z dWNjZXNzZnVsIEFjY2VzcyBUb2tlbiBSZXNwb25zZSBmcm9tIEF1dGhvcml6YXRpb24gU2VydmVy PC9oMz4KCjxwPlRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHZlcmlmeSBVc2VyJ3MgdXNl cm5hbWUgYW5kCiAgICAgICAgICBwYXNzd29yZC4gSWYgdGhlIHZlcmlmaWNhdGlvbiBmYWlscywg dGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QKICAgICAgICAgIHJlc3BvbmQgd2l0aDoKPC9w PjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsg bWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgogIEhUVFAgNDAxIFVuYXV0aG9yaXplZAo8L3ByZT48 L2Rpdj4KPHA+YW5kIHRoZSBIVFRQIGhlYWRlcjoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRh YmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJl PgogIFdXVy1BdXRoZW50aWNhdGU6IFdSQVAKPC9wcmU+PC9kaXY+CjxwPlRoZSBDbGllbnQgbmVl ZHMgdG8gb2J0YWluIGEgdmFsaWQgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIGZyb20gdGhlCiAgICAg ICAgICBVc2VyIHBlciA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3AzLnBhc3N3b3JkJz5TZWN0aW9u Jm5ic3A7Ni4xLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q2xpZW50IE9idGFp bnMgVXNlcm5hbWUgYW5kICAgICAgUGFzc3dvcmQ8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IGJl Zm9yZSByZXRyeWluZyB0aGUKICAgICAgICAgIHJlcXVlc3QuCjwvcD4KPGEgbmFtZT0iYW5jaG9y MjQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjEuNiI+PC9hPjxoMz42LjEuNi4mbmJz cDsKVmVyaWZpY2F0aW9uIFVSTCBSZXNwb25zZSBmcm9tIEF1dGhvcml6YXRpb24gU2VydmVyPC9o Mz4KCjxwPklmIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBkZXRlcm1pbmVzIHRoYXQgdGhlIENs aWVudCBtYXkgYmUKICAgICAgICAgIG1hbGljaW91cywgdGhlIEF1dGhvcml6YXRpb24gU2VydmVy IE1BWSByZXF1aXJlIHRoZSBDbGllbnQgdG8KICAgICAgICAgIGluc3RydWN0IHRoZSBVc2VyIHRv IHZpc2l0IGEgVmVyaWZpY2F0aW9uIFVSTC4gVGhlIEF1dGhvcml6YXRpb24KICAgICAgICAgIFNl cnZlciBjb21tdW5pY2F0ZXMgaXRzIHJlcXVpcmVtZW50IGJ5IHJlc3BvbmRpbmcgdG8gdGhlIENs aWVudCdzCiAgICAgICAgICBBY2Nlc3MgVG9rZW4gcmVxdWVzdCB3aXRoIHRoZSBmb2xsb3dpbmc6 CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAz ZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICBIVFRQIDQwMCBCYWQgUmVxdWVzdAo8L3By ZT48L2Rpdj4KPHA+YW5kIHRoZSBib2R5IG9mIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciByZXNw b25zZSBjb250YWlucyB0aGUKICAgICAgICAgIGZvbGxvd2luZyBwYXJhbWV0ZXI6CjwvcD4KPHA+ PC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+d3JhcF92ZXJpZmljYXRpb25f dXJsPC9kdD4KPGRkPlJFUVVJUkVELiBUaGUKICAgICAgICAgICAgICB2ZXJpZmljYXRpb24gVVJM IHRoYXQgdGhlIENsaWVudCBNVVNUIGVpdGhlciBsb2FkIGluIHRoZSBVc2VyJ3MKICAgICAgICAg ICAgICBicm93c2VyLCBvciBkaXNwbGF5IGZvciB0aGUgVXNlciB0byBlbnRlciBpbnRvIGEgYnJv d3Nlci4KPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+Cgo8cD5UaGUgQ2xpZW50IE1VU1QgdGhlbiB3 YWl0IGZvciB0aGUgVXNlciB0byBpbmRpY2F0ZSB0aGV5IGhhdmUKICAgICAgICAgIHN1Y2Nlc3Nm dWxseSBjb21wbGV0ZWQgdGhlIHZlcmlmaWNhdGlvbiBwcm9jZXNzIGF0IHRoZSBBdXRob3JpemF0 aW9uCiAgICAgICAgICBTZXJ2ZXIgYW5kIGF0dGVtcHQgdG8gb2J0YWluIGFuIEFjY2VzcyBUb2tl biBSZWZyZXNoIFRva2VuIHBlciA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3AzLnJlcXVlc3QnPlNl Y3Rpb24mbmJzcDs2LjEuMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5DbGllbnQg UmVxdWVzdHMgQWNjZXNzIFRva2VuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBhZ2Fpbi4KPC9w Pgo8YSBuYW1lPSJhbmNob3IyNSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5 b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWdu PSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0Mm bmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjYuMS43Ij48 L2E+PGgzPjYuMS43LiZuYnNwOwpDQVBUQ0hBIFJlc3BvbnNlIGZyb20gQXV0aG9yaXphdGlvbiBT ZXJ2ZXI8L2gzPgoKPHA+SWYgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGRldGVybWluZXMgdGhh dCB0aGUgQ2xpZW50IG1heSBiZQogICAgICAgICAgbWFsaWNpb3VzLCB0aGUgQXV0aG9yaXphdGlv biBTZXJ2ZXIgTUFZIHJlcXVpcmUgdGhlIENsaWVudCB0byBoYXZlCiAgICAgICAgICB0aGUgVXNl ciBzb2x2ZSBhIENBUFRDSEEgUHV6emxlLiBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIKICAgICAg ICAgIGNvbW11bmljYXRlcyBpdHMgcmVxdWlyZW1lbnQgYnkgcmVzcG9uZGluZyB0byB0aGUgQ2xp ZW50J3MgQWNjZXNzCiAgICAgICAgICBUb2tlbiByZXF1ZXN0IHdpdGggdGhlIGZvbGxvd2luZzoK PC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNl bTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgogIEhUVFAgNDAwIEJhZCBSZXF1ZXN0CjwvcHJl PjwvZGl2Pgo8cD5hbmQgdGhlIGJvZHkgb2YgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHJlc3Bv bnNlIGNvbnRhaW5zIHRoZQogICAgICAgICAgZm9sbG93aW5nIHBhcmFtZXRlcjoKPC9wPgo8cD48 L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD53cmFwX2NhcHRjaGFfdXJsPC9k dD4KPGRkPlJFUVVJUkVELiBUaGUgVVJMIHRvCiAgICAgICAgICAgICAgdGhlIENBUFRDSEEgcHV6 emxlIGltYWdlLgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KCjxwPlRoZSBDbGllbnQgTVVTVCBw cmVzZW50IHRoZSBVc2VyIHdpdGggdGhlIENBUFRDSEEgcHV6emxlIGFuZAogICAgICAgICAgcHJv bXB0IGZvciBhIHNvbHV0aW9uLiBUaGUgQ2xpZW50IHRoZW4gTUFZIGF0dGVtcHQgdG8gb2J0YWlu IGFuCiAgICAgICAgICBBY2Nlc3MgVG9rZW4gcGVyIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcDMu cmVxdWVzdCc+U2VjdGlvbiZuYnNwOzYuMS4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2lu Zm8nPkNsaWVudCBSZXF1ZXN0cyBBY2Nlc3MgVG9rZW48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ IGFnYWluLCBpbmNsdWRpbmcKICAgICAgICAgIHRoZSBmb2xsb3dpbmcgYWRkaXRpb25hbCBwYXJh bWV0ZXI6CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+d3Jh cF9jYXB0Y2hhX3VybDwvZHQ+CjxkZD5SRVFVSVJFRC4gVGhlIFVSTCB0bwogICAgICAgICAgICAg IHRoZSBDQVBUQ0hBIHB1enpsZSByZWNlaXZlZCBmcm9tIHRoZSBBdXRob3JpemF0aW9uIFNlcnZl ci4KPC9kZD4KPGR0PndyYXBfY2FwdGNoYV9zb2x1dGlvbjwvZHQ+CjxkZD5SRVFVSVJFRC4gVGhl CiAgICAgICAgICAgICAgc29sdXRpb24gc3RyaW5nIHRvIHRoZSBDQVBUQ0hBIHB1enpsZSBhcyBk ZWZpbmVkIGJ5IHRoZQogICAgICAgICAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyLgo8L2RkPgo8 L2RsPjwvYmxvY2txdW90ZT4KCjxhIG5hbWU9ImFuY2hvcjI2Ij48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uNi4xLjgiPjwvYT48aDM+Ni4xLjguJm5ic3A7CkNsaWVudCBSZWZyZXNoZXMgQWNj ZXNzIFRva2VuPC9oMz4KCjxwPlJlZnJlc2hpbmcgYW4gQWNjZXNzIFRva2VuIGlzIHRoZSBzYW1l IGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcDMnPlNlY3Rpb24mbmJzcDs2LjE8c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+VXNlcm5hbWUgYW5kIFBhc3N3b3JkIFByb2ZpbGU8L3Nw YW4+PHNwYW4+KTwvc3Bhbj48L2E+LCA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3A0Jz5TZWN0aW9u Jm5ic3A7Ni4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPldlYiBBcHAgUHJvZmls ZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sIGFuZCA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3A1 Jz5TZWN0aW9uJm5ic3A7Ni4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlJpY2gg QXBwIFByb2ZpbGU8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiBBdXRob3JpemF0aW9uIFNlcnZl cnMgU0hPVUxEIGlzc3VlIEFjY2VzcwogICAgICAgICAgVG9rZW5zIHRoYXQgZXhwaXJlIGFuZCBy ZXF1aXJlIENsaWVudHMgdG8gcmVmcmVzaCB0aGVtLiBVcG9uCiAgICAgICAgICByZWNlaXZpbmcg dGhlIEhUVFAgNDAxIHJlc3BvbnNlIHdoZW4gYWNjZXNzaW5nIHByb3RlY3RlZCByZXNvdXJjZXMK ICAgICAgICAgIHBlciA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1Byb3RlY3RlZFJlc291cmNlJz5T ZWN0aW9uJm5ic3A7NDxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3Npbmcg YSBQcm90ZWN0ZWQgUmVzb3VyY2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCB0aGUgQ2xpZW50 IG1ha2VzIGFuCiAgICAgICAgICBIVFRQUyByZXF1ZXN0IHRvIHRoZSBBdXRob3JpemF0aW9uIFNl cnZlcidzIFJlZnJlc2ggVG9rZW4gVVJMIHVzaW5nCiAgICAgICAgICBQT1NULiBUaGUgcmVxdWVz dCBjb250YWlucyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6CjwvcD4KPHA+PC9wPgo8YmxvY2tx dW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+d3JhcF9yZWZyZXNoX3Rva2VuPC9kdD4KPGRkPlJF UVVJUkVELiBUaGUgUmVmcmVzaAogICAgICAgICAgICAgIFRva2VuIHRoYXQgd2FzIHJlY2VpdmVk IGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcDMucmVxdWVzdCc+U2VjdGlvbiZuYnNwOzYuMS4z PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNsaWVudCBSZXF1ZXN0cyBBY2Nlc3Mg VG9rZW48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+CjwvZGQ+CjxkdD5BZGRpdGlvbmFsIHBhcmFt ZXRlcnM6PC9kdD4KPGRkPkFueSBhZGRpdGlvbmFsCiAgICAgICAgICAgICAgcGFyYW1ldGVycywg YXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuCjwvZGQ+CjwvZGw+PC9ibG9j a3F1b3RlPgoKPGEgbmFtZT0iYW5jaG9yMjciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42 LjEuOSI+PC9hPjxoMz42LjEuOS4mbmJzcDsKU3VjY2Vzc2Z1bCBBY2Nlc3MgVG9rZW4gUmVmcmVz aDwvaDM+Cgo8cD5JZiBzdWNjZXNzZnVsLCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgcmV0dXJu czoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6 IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgogIEhUVFAgMjAwIE9LCjwvcHJlPjwvZGl2 Pgo8cD53aXRoIHRoZSBBY2Nlc3MgVG9rZW4gaW4gdGhlIHJlc3BvbnNlIGJvZHkuIFRoZSByZXNw b25zZSBib2R5CiAgICAgICAgICBjb250YWlucyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6Cjwv cD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+d3JhcF9hY2Nlc3Nf dG9rZW48L2R0Pgo8ZGQ+IFJFUVVJUkVELiBUaGUgQWNjZXNzCiAgICAgICAgICAgICAgVG9rZW4u CjwvZGQ+CjxkdD53cmFwX2FjY2Vzc190b2tlbl9leHBpcmVzX2luPC9kdD4KPGRkPiBPUFRJT05B TC4KICAgICAgICAgICAgICBUaGUgbGlmZXRpbWUgb2YgdGhlIEFjY2VzcyBUb2tlbiBpbiBzZWNv bmRzLiBGb3IgZXhhbXBsZSwgMzYwMAogICAgICAgICAgICAgIHJlcHJlc2VudHMgb25lIGhvdXIu CjwvZGQ+CjxkdD5BZGRpdGlvbmFsICAgIHBhcmFtZXRlcnM8L2R0Pgo8ZGQ+IEFueSBhZGRpdGlv bmFsCiAgICAgICAgICAgICAgcGFyYW1ldGVycywgYXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXIuCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPgoKPGEgbmFtZT0iYW5jaG9yMjgi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjEuMTAiPjwvYT48aDM+Ni4xLjEwLiZuYnNw OwpVbnN1Y2Nlc3NmdWwgQWNjZXNzIFRva2VuIFJlZnJlc2g8L2gzPgoKPHA+VGhlIEF1dGhvcml6 YXRpb24gU2VydmVyIE1VU1QgdmVyaWZ5IHRoZSBSZWZyZXNoIFRva2VuLiBJZiB0aGUKICAgICAg ICAgIHZlcmlmaWNhdGlvbiBmYWlscywgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgcmVz cG9uZCB3aXRoCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdp bi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICBIVFRQIDQwMSBVbmF1dGhv cml6ZWQKPC9wcmU+PC9kaXY+CjxwPmFuZCB0aGUgSFRUUCBoZWFkZXI6CjwvcD48ZGl2IHN0eWxl PSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdo dDogYXV0byc+PHByZT4KICBXV1ctQXV0aGVudGljYXRlOiBXUkFQCjwvcHJlPjwvZGl2Pgo8cD5U aGUgQ2xpZW50IE1VU1QgYWdhaW4gcmVxdWVzdCBhdXRob3JpemF0aW9uIGZyb20gdGhlIFVzZXIg YnkKICAgICAgICAgIHByb21wdGluZyBmb3IgdGhlIFVzZXIncyB1c2VybmFtZSBhbmQgcGFzc3dv cmQgcGVyIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcDMucGFzc3dvcmQnPlNlY3Rpb24mbmJzcDs2 LjEuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5DbGllbnQgT2J0YWlucyBVc2Vy bmFtZSBhbmQgICAgICBQYXNzd29yZDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gYmVmb3JlIHJl dHJ5aW5nIHRoZSByZXF1ZXN0Lgo8L3A+CjxhIG5hbWU9InA0Ij48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uNi4yIj48L2E+PGgzPjYuMi4mbmJzcDsKV2ViIEFwcCBQcm9maWxlPC9oMz4KCjxw PlRoaXMgcHJvZmlsZSBpcyBzdWl0YWJsZSB3aGVuIHRoZSBDbGllbnQgaXMgYSB3ZWIgYXBwbGlj YXRpb24KICAgICAgICBjYWxsaW5nIHRoZSBQcm90ZWN0ZWQgUmVzb3VyY2Ugb24gYmVoYWxmIG9m IGEgVXNlci4gVGhpcyBwcm9maWxlCiAgICAgICAgZW5hYmxlcyBhIENsaWVudCB0byBhY3Qgb24g YmVoYWxmIG9mIHRoZSBVc2VyIHdpdGhvdXQgYWNxdWlyaW5nIGEKICAgICAgICBVc2VyJ3MgY3Jl ZGVudGlhbHMuCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjkiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxl IHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0i VE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3Rv YyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2Vj dGlvbi42LjIuMSI+PC9hPjxoMz42LjIuMS4mbmJzcDsKUHJvdmlzaW9uaW5nPC9oMz4KCjxwPlBy aW9yIHRvIGluaXRpYXRpbmcgdGhpcyBwcm90b2NvbCBwcm9maWxlLCB0aGUgQ2xpZW50IE1VU1Qg aGF2ZQogICAgICAgICAgb2J0YWluZWQgYSBDbGllbnQgSWRlbnRpZmllciBhbmQgQ2xpZW50IFNl Y3JldCBmcm9tIHRoZQogICAgICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIFRoZSBBdXRob3Jp emF0aW9uIFNlcnZlciBNQVkgaGF2ZSBhbHNvCiAgICAgICAgICByZXF1aXJlZCB0aGUgQ2xpZW50 IHRvIHJlZ2lzdGVyIHRoZSBDYWxsYmFjayBVUkwuCjwvcD4KPGEgbmFtZT0icDQuYXV0aG9yaXph dGlvbiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0 ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48 L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjYuMi4yIj48L2E+PGgzPjYuMi4yLiZu YnNwOwpDbGllbnQgRGlyZWN0cyB0aGUgVXNlciB0byB0aGUgICAgICBBdXRob3JpemF0aW9uIFNl cnZlcjwvaDM+Cgo8cD5UaGUgQ2xpZW50IGluaXRpYXRlcyBhbiBhdXRob3JpemF0aW9uIHJlcXVl c3QgYnkgcmVkaXJlY3RpbmcgdGhlCiAgICAgICAgICBVc2VyJ3MgYnJvd3NlciB0byB0aGUgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIncyBVc2VyIEF1dGhvcml6YXRpb24gVVJMLAogICAgICAgICAgd2l0 aCB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFz cz0idGV4dCI+PGRsPgo8ZHQ+d3JhcF9jbGllbnRfaWQ8L2R0Pgo8ZGQ+IFJFUVVJUkVELiBUaGUg Q2xpZW50CiAgICAgICAgICAgICAgSWRlbnRpZmllci4KPC9kZD4KPGR0PndyYXBfY2FsbGJhY2sg ICAgPC9kdD4KPGRkPiBSRVFVSVJFRC4gVGhlCiAgICAgICAgICAgICAgQ2FsbGJhY2sgVVJMLiBB biBhYnNvbHV0ZSBVUkwgdG8gd2hpY2ggdGhlIEF1dGhvcml6YXRpb24gU2VydmVyCiAgICAgICAg ICAgICAgd2lsbCByZWRpcmVjdCB0aGUgVXNlciBiYWNrIGFmdGVyIHRoZSBVc2VyIGhhcyBhcHBy b3ZlZCB0aGUKICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVlc3QuIEF1dGhvcml6YXRp b24gU2VydmVycyBNQVkgcmVxdWlyZSB0aGF0CiAgICAgICAgICAgICAgdGhlIHdyYXBfY2FsbGJh Y2sgVVJMIG1hdGNoIHRoZSBwcmV2aW91c2x5IHJlZ2lzdGVyZWQgdmFsdWUgZm9yCiAgICAgICAg ICAgICAgdGhlIENsaWVudCBJZGVudGlmaWVyLgo8L2RkPgo8ZHQ+d3JhcF9jbGllbnRfc3RhdGU8 L2R0Pgo8ZGQ+T1BUSU9OQUwuIEFuIG9wYXF1ZQogICAgICAgICAgICAgIHZhbHVlIHRoYXQgQ2xp ZW50cyBjYW4gdXNlIHRvIG1haW50YWluIHN0YXRlIGFzc29jaWF0ZWQgd2l0aAogICAgICAgICAg ICAgIHRoaXMgcmVxdWVzdC4gSWYgdGhpcyB2YWx1ZSBpcyBwcmVzZW50LCB0aGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXIKICAgICAgICAgICAgICBNVVNUIHJldHVybiBpdCB0byB0aGUgQ2xpZW50J3Mg Q2FsbGJhY2sgVVJMLgo8L2RkPgo8ZHQ+d3JhcF9zY29wZTwvZHQ+CjxkZD4gT1BUSU9OQUwuIFRo ZSBBdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgU2VydmVyIE1BWSBkZWZpbmUgYXV0aG9yaXph dGlvbiBzY29wZSB2YWx1ZXMgZm9yIHRoZSBDbGllbnQgdG8KICAgICAgICAgICAgICBpbmNsdWRl Lgo8L2RkPgo8ZHQ+QWRkaXRpb25hbCBwYXJhbWV0ZXJzPC9kdD4KPGRkPiBBbnkgYWRkaXRpb25h bAogICAgICAgICAgICAgIHBhcmFtZXRlcnMsIGFzIGRlZmluZWQgYnkgdGhlIEF1dGhvcml6YXRp b24gU2VydmVyLgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KCjxhIG5hbWU9ImFuY2hvcjMwIj48 L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNz PSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90 YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi4yLjMiPjwvYT48aDM+Ni4yLjMuJm5ic3A7CkF1 dGhvcml6YXRpb24gU2VydmVyIENvbmZpcm1zIEF1dGhvcml6YXRpb24gUmVxdWVzdCB3aXRoIFVz ZXI8L2gzPgoKPHA+VXBvbiByZWNlaXZpbmcgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0IGZyb20g dGhlIENsaWVudCBieSBhCiAgICAgICAgICByZWRpcmVjdGlvbiBvZiB0aGUgVXNlcidzIGJyb3dz ZXIsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcgogICAgICAgICAgYXV0aGVudGljYXRlcyB0aGUg dXNlciwgcHJlc2VudHMgdGhlIFVzZXIgd2l0aCB0aGUgUHJvdGVjdGVkCiAgICAgICAgICBSZXNv dXJjZSBhY2Nlc3MgdGhhdCB3aWxsIGJlIGdyYW50ZWQgdG8gdGhlIENsaWVudCwgYW5kIHByb21w dHMgdGhlCiAgICAgICAgICBVc2VyIHRvIGNvbmZpcm0gdGhlIHJlcXVlc3QuCjwvcD4KPHA+SWYg dGhlIFVzZXIgZGVuaWVzIHRoZSByZXF1ZXN0LCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZ CiAgICAgICAgICBhbGxvdyB0aGUgVXNlciB0byByZXR1cm4gdG8gdGhlIENsaWVudCBDYWxsYmFj ayBVUkwgd2l0aCB0aGUKICAgICAgICAgIGZvbGxvd2luZyBwYXJhbWV0ZXJzIGFkZGVkOgo8L3A+ CjxwPjwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PndyYXBfZXJyb3JfcmVh c29uPC9kdD4KPGRkPiBSRVFVSVJFRC4gVmFsdWUgaXMKICAgICAgICAgICAgICB1c2VyX2Rlbmll ZAo8L2RkPgo8ZHQ+d3JhcF9jbGllbnRfc3RhdGU8L2R0Pgo8ZGQ+IFJFUVVJUkVEIGlmIHRoZQog ICAgICAgICAgICAgIENsaWVudCBzZW50IHRoZSB2YWx1ZSBpbiB0aGUgYXV0aG9yaXphdGlvbiBy ZXF1ZXN0IGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcDQuYXV0aG9yaXphdGlvbic+U2VjdGlv biZuYnNwOzYuMi4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNsaWVudCBEaXJl Y3RzIHRoZSBVc2VyIHRvIHRoZSAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyPC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KCjxwPklmIHRoZSBVc2VyIGFw cHJvdmVzIHRoZSByZXF1ZXN0LCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIKICAgICAgICAgIGdl bmVyYXRlcyBhIFZlcmlmaWNhdGlvbiBDb2RlIGFuZCBhc3NvY2lhdGVzIGl0IHdpdGggdGhlIENs aWVudAogICAgICAgICAgSWRlbnRpZmllciBhbmQgQ2FsbGJhY2sgVVJMLgo8L3A+CjxhIG5hbWU9 ImFuY2hvcjMxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi4yLjQiPjwvYT48aDM+Ni4y LjQuJm5ic3A7CkF1dGhvcml6YXRpb24gU2VydmVyIERpcmVjdHMgVXNlciBiYWNrIHRvIHRoZSBD bGllbnQ8L2gzPgoKPHA+SWYgdGhlIFVzZXIgYXBwcm92ZWQgdGhlIHJlcXVlc3QsIHRoZSBBdXRo b3JpemF0aW9uIFNlcnZlciBNVVNUCiAgICAgICAgICByZWRpcmVjdCB0aGUgVXNlciBiYWNrIHRv IHRoZSBDYWxsYmFjayBVUkwsIHdpdGggdGhlIGZvbGxvd2luZwogICAgICAgICAgcGFyYW1ldGVy cyBhZGRlZDoKPC9wPgo8cD48L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD53 cmFwX3ZlcmlmaWNhdGlvbl9jb2RlPC9kdD4KPGRkPiBSRVFVSVJFRC4gVGhlCiAgICAgICAgICAg ICAgVmVyaWZpY2F0aW9uIENvZGUuCjwvZGQ+CjxkdD53cmFwX2NsaWVudF9zdGF0ZTwvZHQ+Cjxk ZD4gUkVRVUlSRUQgaWYgdGhlCiAgICAgICAgICAgICAgQ2xpZW50IHNlbnQgdGhlIHZhbHVlIGlu IHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNwNC5h dXRob3JpemF0aW9uJz5TZWN0aW9uJm5ic3A7Ni4yLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+Q2xpZW50IERpcmVjdHMgdGhlIFVzZXIgdG8gdGhlICAgICAgQXV0aG9yaXphdGlv biBTZXJ2ZXI8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+CjwvZGQ+CjxkdD5BZGRpdGlvbmFsICAg IHBhcmFtZXRlcnM6PC9kdD4KPGRkPkFueSBhZGRpdGlvbmFsCiAgICAgICAgICAgICAgcGFyYW1l dGVycywgYXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuCjwvZGQ+CjwvZGw+ PC9ibG9ja3F1b3RlPgoKPGEgbmFtZT0icDQucmVxdWVzdCI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjYuMi41Ij48L2E+PGgzPjYuMi41LiZuYnNwOwpDbGllbnQgUmVxdWVzdHMgQWNjZXNz IFRva2VuPC9oMz4KCjxwPlRoZSBDbGllbnQgbWFrZXMgYW4gSFRUUFMgcmVxdWVzdCB0byB0aGUg QXV0aG9yaXphdGlvbiBTZXJ2ZXIncwogICAgICAgICAgQWNjZXNzIFRva2VuIFVSTCwgdXNpbmcg UE9TVC4gVGhlIHJlcXVlc3QgY29udGFpbnMgdGhlIGZvbGxvd2luZwogICAgICAgICAgcGFyYW1l dGVycyBpbiB0aGUgYm9keSBvZiB0aGUgcmVxdWVzdDoKPC9wPgo8cD48L3A+CjxibG9ja3F1b3Rl IGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD53cmFwX2NsaWVudF9pZDwvZHQ+CjxkZD4gUkVRVUlSRUQu IFRoZSBDbGllbnQKICAgICAgICAgICAgICBJZGVudGlmaWVyCjwvZGQ+CjxkdD53cmFwX2NsaWVu dF9zZWNyZXQ8L2R0Pgo8ZGQ+UkVRVUlSRUQuIFRoZSBDbGllbnQKICAgICAgICAgICAgICBTZWNy ZXQKPC9kZD4KPGR0PndyYXBfdmVyaWZpY2F0aW9uX2NvZGU8L2R0Pgo8ZGQ+IFJFUVVJUkVELiBU aGUKICAgICAgICAgICAgICBWZXJpZmljYXRpb24gQ29kZS4KPC9kZD4KPGR0PndyYXBfY2FsbGJh Y2s8L2R0Pgo8ZGQ+IFJFUVVJUkVELiBUaGUgQ2FsbGJhY2sKICAgICAgICAgICAgICBVUkwgdXNl ZCB0byBvYnRhaW4gdGhlIFZlcmlmaWNhdGlvbiBDb2RlLgo8L2RkPgo8ZHQ+QWRkaXRpb25hbCBw YXJhbWV0ZXJzOjwvZHQ+CjxkZD5BbnkgYWRkaXRpb25hbAogICAgICAgICAgICAgIHBhcmFtZXRl cnMsIGFzIGRlZmluZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLgo8L2RkPgo8L2RsPjwv YmxvY2txdW90ZT4KCjxhIG5hbWU9ImFuY2hvcjMyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uNi4yLjYiPjwvYT48aDM+Ni4yLjYuJm5ic3A7ClN1Y2Nlc3NmdWwgQWNjZXNzIFRva2VuIFJl c3BvbnNlIGZyb20gQXV0aG9yaXphdGlvbiBTZXJ2ZXI8L2gzPgoKPHA+QWZ0ZXIgcmVjZWl2aW5n IHRoZSBBY2Nlc3MgVG9rZW4gcmVxdWVzdCwgdGhlIEF1dGhvcml6YXRpb24KICAgICAgICAgIFNl cnZlciB2ZXJpZmllcyB0aGUgcmVxdWVzdCBhcyBmb2xsb3dzOgo8L3A+CjxwPjwvcD4KPGJsb2Nr cXVvdGUgY2xhc3M9InRleHQiPgo8cD50aGUgQ2xpZW50IFNlY3JldCBNVVNUIG1hdGNoIHRoZSBD bGllbnQgSWRlbnRpZmVyCjwvcD4KPHA+dGhlIENsaWVudCBJZGVudGlmaWVyIE1VU1QgbWF0Y2gg dGhlIENsaWVudCBJZGVudGlmaWVyIGZyb20KICAgICAgICAgICAgICB0aGUgYXV0aG9yaXphdGlv biByZWRpcmVjdAo8L3A+CjxwPnRoZSBWZXJpZmljYXRpb24gQ29kZSBNVVNUIG1hdGNoIHRoZSBD bGllbnQgSWRlbnRpZmllciBmcm9tCiAgICAgICAgICAgICAgdGhlIGF1dGhvcml6YXRpb24gcmVk aXJlY3QKPC9wPgo8cD50aGUgQ2FsbGJhY2sgVVJMIE1VU1QgbWF0Y2ggdGhlIENhbGxiYWNrIFVS TCBmcm9tIHRoZQogICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gcmVkaXJlY3QKPC9wPgo8cD5p ZiB0aGUgQ2FsbGJhY2sgVVJMIG9yIENhbGxiYWNrIFVSTCBwYXR0ZXJuIHdhcyByZWdpc3RlcmVk CiAgICAgICAgICAgICAgd2l0aCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIsIHRoZSBDYWxsYmFj ayBVUkwgTVVTVCBtYXRjaCB0aGUKICAgICAgICAgICAgICBDYWxsYmFjayBVUkwgb3IgQ2FsbGJh Y2sgVVJMIHBhdHRlcm4gYXMgZGVmaW5lZCBieSB0aGUKICAgICAgICAgICAgICBBdXRob3JpemF0 aW9uIFNlcnZlcgo8L3A+CjxwPnRoZSBWZXJpZmljYXRpb24gQ29kZSBNVVNUIG5vdCBoYXZlIGV4 cGlyZWQKPC9wPgo8L2Jsb2NrcXVvdGU+Cgo8cD5UaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUFZ IGFsc28gcmVxdWlyZSB0aGF0IGEgVmVyaWZpY2F0aW9uCiAgICAgICAgICBDb2RlIGlzIG5vdCBy ZXVzZWQuCjwvcD4KPHA+SWYgdmVyaWZpY2F0aW9uIGlzIHN1Y2Nlc3NmdWwsIHRoZSBBdXRob3Jp emF0aW9uIFNlcnZlcgogICAgICAgICAgcmV0dXJuczoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6 IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48 cHJlPgogIEhUVFAgMjAwIE9LCjwvcHJlPjwvZGl2Pgo8cD53aXRoIHRoZSBSZWZyZXNoIFRva2Vu IGFuZCB0aGUgQWNjZXNzIFRva2VuIGluIHRoZSByZXNwb25zZSBib2R5LgogICAgICAgICAgVGhl IHJlc3BvbnNlIGJvZHkgY29udGFpbnMgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzOgo8L3A+Cjxw PjwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PndyYXBfcmVmcmVzaF90b2tl bjwvZHQ+CjxkZD4gUkVRVUlSRUQuIFRoZQogICAgICAgICAgICAgIFJlZnJlc2ggVG9rZW4uCjwv ZGQ+CjxkdD53cmFwX2FjY2Vzc190b2tlbjwvZHQ+CjxkZD4gUkVRVUlSRUQuIFRoZSBBY2Nlc3MK ICAgICAgICAgICAgICBUb2tlbi4KPC9kZD4KPGR0PndyYXBfYWNjZXNzX3Rva2VuX2V4cGlyZXNf aW48L2R0Pgo8ZGQ+IE9QVElPTkFMLgogICAgICAgICAgICAgIFRoZSBsaWZldGltZSBvZiB0aGUg QWNjZXNzIFRva2VuIGluIHNlY29uZHMuIEZvciBleGFtcGxlLCAzNjAwCiAgICAgICAgICAgICAg cmVwcmVzZW50cyBvbmUgaG91ci4KPC9kZD4KPGR0PkFkZGl0aW9uYWwgcGFyYW1ldGVyczwvZHQ+ CjxkZD4gQW55IGFkZGl0aW9uYWwKICAgICAgICAgICAgICBwYXJhbWV0ZXJzLCBhcyBkZWZpbmVk IGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4KPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+Cgo8 cD5UaGUgQ2xpZW50IHNlY3VyZWx5IHN0b3JlcyB0aGUgUmVmcmVzaCBUb2tlbiBmb3IgbGF0ZXIg dXNlLiBUaGUKICAgICAgICAgIENsaWVudCBtYXkgbm93IHVzZSB0aGUgQWNjZXNzIFRva2VuIHRv IGFjY2VzcyB0aGUgUHJvdGVjdGVkIFJlc291cmNlCiAgICAgICAgICBwZXIgPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNQcm90ZWN0ZWRSZXNvdXJjZSc+U2VjdGlvbiZuYnNwOzQ8c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzaW5nIGEgUHJvdGVjdGVkIFJlc291cmNlPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPi4KPC9wPgo8YSBuYW1lPSJhbmNob3IzMyI+PC9hPjxiciAvPjxo ciAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48 YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5h bWU9InJmYy5zZWN0aW9uLjYuMi43Ij48L2E+PGgzPjYuMi43LiZuYnNwOwpVbnN1Y2Nlc3NmdWwg QWNjZXNzIFRva2VuIFJlc3BvbnNlIGZyb20gQXV0aG9yaXphdGlvbiBTZXJ2ZXI8L2gzPgoKPHA+ VGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgZmlyc3QgdmVyaWZ5IHRoZSBDbGllbnQgSWRl bnRpZmllcgogICAgICAgICAgYW5kIENsaWVudCBTZWNyZXQuIElmIHRoZXkgYXJlIGludmFsaWQs IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcgogICAgICAgICAgTVVTVCByZXNwb25kIHdpdGg6Cjwv cD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07 IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICBIVFRQIDQwMSBVbmF1dGhvcml6ZWQKPC9wcmU+ PC9kaXY+CjxwPmFuZCB0aGUgSFRUUCBoZWFkZXI6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0 YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHBy ZT4KICBXV1ctQXV0aGVudGljYXRlOiBXUkFQCjwvcHJlPjwvZGl2Pgo8cD5UaGUgQ2xpZW50IE1V U1Qgb2J0YWluIGEgdmFsaWQgQ2xpZW50IElkZW50aWZpZXIgYW5kIENsaWVudAogICAgICAgICAg U2VjcmV0IGJlZm9yZSByZXRyeWluZyB0aGUgcmVxdWVzdC4KPC9wPgo8cD5UaGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXIgTVVTVCB0aGVuIHZlcmlmeSB0aGF0IHRoZSBDYWxsYmFjayBVUkwKICAgICAg ICAgIGFuZCBWZXJpZmljYXRpb24gQ29kZSBhcmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBDbGllbnQg SWRlbnRpZmllci4gSWYKICAgICAgICAgIHRoZSB2ZXJpZmljYXRpb24gZmFpbHMsIHRoZSBBdXRo b3JpemF0aW9uIFNlcnZlciBNVVNUIHJlc3BvbmQKICAgICAgICAgIHdpdGg6CjwvcD48ZGl2IHN0 eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1y aWdodDogYXV0byc+PHByZT4KICBIVFRQIDQwMCBCYWQgUmVxdWVzdAo8L3ByZT48L2Rpdj4KPHA+ YW5kIHRoZSBib2R5IG9mIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciByZXNwb25zZSBjb250YWlu cyB0aGUKICAgICAgICAgIGZvbGxvd2luZyBwYXJhbWV0ZXJzOgo8L3A+CjxwPjwvcD4KPGJsb2Nr cXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PndyYXBfZXJyb3JfcmVhc29uPC9kdD4KPGRkPk9Q VElPTkFMLiBJZiBhbGwgdGhlCiAgICAgICAgICAgICAgcGFyYW1ldGVycyBhcmUgdmFsaWQgZXhj ZXB0IHRoYXQgdGhlIFZlcmlmaWNhdGlvbiBDb2RlIGhhcwogICAgICAgICAgICAgIGV4cGlyZWQg b3IgYmVlbiByZXZva2VkLCB0aGVuIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhpcwogICAgICAg ICAgICAgIHBhcmFtZXRlciBiZSBpbmNsdWRlZCBhbmQgaWYgc28sIHRoZW4gdGhlIHZhbHVlIE1V U1QgYmU6CjwvZGQ+CjxkdD48L2R0Pgo8ZGQ+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdp ZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CiBleHBp cmVkX3ZlcmlmaWNhdGlvbl9jb2RlCjwvcHJlPjwvZGl2Pgo8L2RkPgo8ZHQ+PC9kdD4KPGRkPlRo aXMgZW5hYmxlcyB0aGUgQ2xpZW50IHRvIGRldGVjdCBpdCBuZWVkcyBhIG5ldyBWZXJpZmljYXRp b24KICAgICAgICAgICAgICBDb2RlIGFuZCB0byBkaXJlY3QgdGhlIFVzZXIgdG8gdGhlIEF1dGhv cml6YXRpb24gU2VydmVyIHBlcgogICAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj cDQuYXV0aG9yaXphdGlvbic+U2VjdGlvbiZuYnNwOzYuMi4yPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPkNsaWVudCBEaXJlY3RzIHRoZSBVc2VyIHRvIHRoZSAgICAgIEF1dGhvcml6 YXRpb24gU2VydmVyPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPgo8L2RkPgo8ZHQ+PC9kdD4KPGRk PklmIHRoZSBDYWxsYmFjayBVUkwgaXMgaW52YWxpZCwgdGhlIHZhbHVlIE1VU1QgYmU6CjwvZGQ+ CjxkdD48L2R0Pgo8ZGQ+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJn aW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CiBpbnZhbGlkX2NhbGxiYWNr CjwvcHJlPjwvZGl2Pgo8L2RkPgo8ZHQ+QWRkaXRpb25hbCBwYXJhbWV0ZXJzPC9kdD4KPGRkPiBB bnkgYWRkaXRpb25hbAogICAgICAgICAgICAgIHBhcmFtZXRlcnMsIGFzIGRlZmluZWQgYnkgdGhl IEF1dGhvcml6YXRpb24gU2VydmVyLgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KCjxhIG5hbWU9 ImFuY2hvcjM0Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi4yLjgiPjwvYT48aDM+Ni4y LjguJm5ic3A7CkNsaWVudCBSZWZyZXNoZXMgQWNjZXNzIFRva2VuPC9oMz4KCjxwPlJlZnJlc2hp bmcgYW4gQWNjZXNzIFRva2VuIGlzIHRoZSBzYW1lIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj cDMnPlNlY3Rpb24mbmJzcDs2LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+VXNl cm5hbWUgYW5kIFBhc3N3b3JkIFByb2ZpbGU8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCA8YSBj bGFzcz0naW5mbycgaHJlZj0nI3A0Jz5TZWN0aW9uJm5ic3A7Ni4yPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPldlYiBBcHAgUHJvZmlsZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4s IGFuZCA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3A1Jz5TZWN0aW9uJm5ic3A7Ni4zPHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlJpY2ggQXBwIFByb2ZpbGU8L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+LiBBdXRob3JpemF0aW9uIFNlcnZlcnMgU0hPVUxEIGlzc3VlIEFjY2VzcwogICAg ICAgICAgVG9rZW5zIHRoYXQgZXhwaXJlIGFuZCByZXF1aXJlIENsaWVudHMgdG8gcmVmcmVzaCB0 aGVtLiBVcG9uCiAgICAgICAgICByZWNlaXZpbmcgdGhlIEhUVFAgNDAxIHJlc3BvbnNlIHdoZW4g YWNjZXNzaW5nIHByb3RlY3RlZCByZXNvdXJjZXMKICAgICAgICAgIHBlciA8YSBjbGFzcz0naW5m bycgaHJlZj0nI1Byb3RlY3RlZFJlc291cmNlJz5TZWN0aW9uJm5ic3A7NDxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3NpbmcgYSBQcm90ZWN0ZWQgUmVzb3VyY2U8L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+LCB0aGUgQ2xpZW50IG1ha2VzIGFuCiAgICAgICAgICBIVFRQUyBy ZXF1ZXN0IHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcidzIFJlZnJlc2ggVG9rZW4gVVJMIHVz aW5nCiAgICAgICAgICBQT1NULiBUaGUgcmVxdWVzdCBjb250YWlucyB0aGUgZm9sbG93aW5nIHBh cmFtZXRlcnM6CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+ d3JhcF9yZWZyZXNoX3Rva2VuPC9kdD4KPGRkPlJFUVVJUkVELiBUaGUgUmVmcmVzaAogICAgICAg ICAgICAgIFRva2VuIHRoYXQgd2FzIHJlY2VpdmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj cDQucmVxdWVzdCc+U2VjdGlvbiZuYnNwOzYuMi41PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9 J2luZm8nPkNsaWVudCBSZXF1ZXN0cyBBY2Nlc3MgVG9rZW48L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+CjwvZGQ+CjxkdD5BZGRpdGlvbmFsIHBhcmFtZXRlcnM6PC9kdD4KPGRkPkFueSBhZGRpdGlv bmFsCiAgICAgICAgICAgICAgcGFyYW1ldGVycywgYXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXIuCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPgoKPGEgbmFtZT0iYW5jaG9yMzUi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjIuOSI+PC9hPjxoMz42LjIuOS4mbmJzcDsK U3VjY2Vzc2Z1bCBBY2Nlc3MgVG9rZW4gUmVmcmVzaDwvaDM+Cgo8cD5JZiBzdWNjZXNzZnVsLCB0 aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgcmV0dXJuczoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6 IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48 cHJlPgogIEhUVFAgMjAwIE9LCjwvcHJlPjwvZGl2Pgo8cD53aXRoIHRoZSBBY2Nlc3MgVG9rZW4g aW4gdGhlIHJlc3BvbnNlIGJvZHkuIFRoZSByZXNwb25zZSBib2R5CiAgICAgICAgICBjb250YWlu cyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFz cz0idGV4dCI+PGRsPgo8ZHQ+d3JhcF9hY2Nlc3NfdG9rZW48L2R0Pgo8ZGQ+IFJFUVVJUkVELiBU aGUgQWNjZXNzCiAgICAgICAgICAgICAgVG9rZW4uCjwvZGQ+CjxkdD53cmFwX2FjY2Vzc190b2tl bl9leHBpcmVzX2luPC9kdD4KPGRkPiBPUFRJT05BTC4KICAgICAgICAgICAgICBUaGUgbGlmZXRp bWUgb2YgdGhlIEFjY2VzcyBUb2tlbiBpbiBzZWNvbmRzLiBGb3IgZXhhbXBsZSwgMzYwMAogICAg ICAgICAgICAgIHJlcHJlc2VudHMgb25lIGhvdXIuCjwvZGQ+CjxkdD5BZGRpdGlvbmFsICAgIHBh cmFtZXRlcnM8L2R0Pgo8ZGQ+IEFueSBhZGRpdGlvbmFsCiAgICAgICAgICAgICAgcGFyYW1ldGVy cywgYXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuCjwvZGQ+CjwvZGw+PC9i bG9ja3F1b3RlPgoKPGEgbmFtZT0iYW5jaG9yMzYiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi42LjIuMTAiPjwvYT48aDM+Ni4yLjEwLiZuYnNwOwpVbnN1Y2Nlc3NmdWwgQWNjZXNzIFRva2Vu IFJlZnJlc2g8L2gzPgoKPHA+VGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgdmVyaWZ5IHRo ZSBSZWZyZXNoIFRva2VuLiBJZiB0aGUKICAgICAgICAgIHZlcmlmaWNhdGlvbiBmYWlscywgdGhl IEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgcmVzcG9uZCB3aXRoCjwvcD48ZGl2IHN0eWxlPSdk aXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDog YXV0byc+PHByZT4KICBIVFRQIDQwMSBVbmF1dGhvcml6ZWQKPC9wcmU+PC9kaXY+CjxwPmFuZCB0 aGUgSFRUUCBoZWFkZXI6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7 IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICBXV1ctQXV0aGVu dGljYXRlOiBXUkFQCjwvcHJlPjwvZGl2Pgo8cD5UaGUgQ2xpZW50IE1VU1QgYWdhaW4gcmVxdWVz dCBhdXRob3JpemF0aW9uIGZyb20gdGhlIFVzZXIgcGVyCiAgICAgICAgICA8YSBjbGFzcz0naW5m bycgaHJlZj0nI3A0LmF1dGhvcml6YXRpb24nPlNlY3Rpb24mbmJzcDs2LjIuMjxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5DbGllbnQgRGlyZWN0cyB0aGUgVXNlciB0byB0aGUgICAg ICBBdXRob3JpemF0aW9uIFNlcnZlcjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCjwvcD4KPGEg bmFtZT0icDUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0 cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwv dGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjMiPjwvYT48aDM+Ni4zLiZu YnNwOwpSaWNoIEFwcCBQcm9maWxlPC9oMz4KCjxwPlRoaXMgcHJvZmlsZSBpcyBzdWl0YWJsZSB3 aGVyZSB0aGUgQ2xpZW50IGlzIGFuIGFwcGxpY2F0aW9uIHRoZQogICAgICAgIFVzZXIgaGFzIGlu c3RhbGxlZCBvbiB0aGVpciBjb21wdXRlciBhbmQgdGhlcmUgaXMgYSBicm93c2VyIGF2YWlsYWJs ZQogICAgICAgIGZvciB0aGUgQ2xpZW50IHRvIGxhdW5jaC4gVGhpcyBwcm9maWxlIGVuYWJsZXMg YSBDbGllbnQgdG8gYWN0IG9uCiAgICAgICAgYmVoYWxmIG9mIHRoZSBVc2VyIHJlZ2FyZGxlc3Mg b2YgaG93IHRoZSBVc2VyIGF1dGhlbnRpY2F0ZXMgdG8gdGhlCiAgICAgICAgU2VydmVyIGFuZCB3 aXRob3V0IGFjY2VzcyB0byB0aGUgVXNlcidzIGNyZWRlbnRpYWxzLgo8L3A+CjxhIG5hbWU9ImFu Y2hvcjM3Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi4zLjEiPjwvYT48aDM+Ni4zLjEu Jm5ic3A7ClByb3Zpc2lvbmluZzwvaDM+Cgo8cD5QcmlvciB0byBpbml0aWF0aW5nIHRoaXMgcHJv dG9jb2wgcHJvZmlsZSwgdGhlIENsaWVudCBNQVkgYmUKICAgICAgICAgIHJlcXVpcmVkIHRvIHJl Z2lzdGVyIHRoZSBDbGllbnQgSWRlbnRpZmllciBhbmQvb3IgdGhlIENhbGxiYWNrIFVSTAogICAg ICAgICAgd2l0aCB0aGUgU2VydmVyLgo8L3A+CjxhIG5hbWU9InA1LmF1dGhvcml6YXRpb24iPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjMuMiI+PC9hPjxoMz42LjMuMi4mbmJzcDsKQ2xp ZW50IERpcmVjdHMgdGhlIFVzZXIgdG8gdGhlICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXI8L2gz PgoKPHA+VGhlIENsaWVudCBpbml0aWF0ZXMgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0IGJ5IG9w ZW5pbmcgdGhlCiAgICAgICAgICBVc2VyJ3MgYnJvd3NlciB3aXRoIHRoZSBTZXJ2ZXIncyBVc2Vy IEF1dGhvcml6YXRpb24gVVJMLCBhbmQKICAgICAgICAgIGluY2x1ZGluZyB0aGUgZm9sbG93aW5n IHBhcmFtZXRlcnM6CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8 ZHQ+d3JhcF9jbGllbnRfaWQ8L2R0Pgo8ZGQ+IFJFUVVJUkVELiBUaGUgQ2xpZW50CiAgICAgICAg ICAgICAgSWRlbnRpZmllci4KPC9kZD4KPGR0PndyYXBfY2FsbGJhY2sgICAgPC9kdD4KPGRkPiBP UFRJT05BTC4gQSBDYWxsYmFjawogICAgICAgICAgICAgIFVSTCB3aGVyZSB0aGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXIgTUFZIHJlZGlyZWN0IHRoZSBVc2VyJ3MKICAgICAgICAgICAgICBicm93c2Vy IGFmdGVyIHRoZSBVc2VyIHJlc3BvbmRzIHRvIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICAg ICAgcmVxdWVzdC4KPC9kZD4KPGR0PndyYXBfY2xpZW50X3N0YXRlPC9kdD4KPGRkPk9QVElPTkFM LiBBbiBvcGFxdWUKICAgICAgICAgICAgICB2YWx1ZSB0aGF0IENsaWVudHMgY2FuIHVzZSB0byBt YWludGFpbiBzdGF0ZSBhc3NvY2lhdGVkIHdpdGgKICAgICAgICAgICAgICB0aGlzIHJlcXVlc3Qu IElmIHRoaXMgdmFsdWUgaXMgcHJlc2VudCwgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyCiAgICAg ICAgICAgICAgTVVTVCByZXR1cm4gaXQgdG8gdGhlIENsaWVudCdzIENhbGxiYWNrIFVSTC4KPC9k ZD4KPGR0PndyYXBfc2NvcGU8L2R0Pgo8ZGQ+IE9QVElPTkFMLiBUaGUgQXV0aG9yaXphdGlvbgog ICAgICAgICAgICAgIFNlcnZlciBNQVkgZGVmaW5lIGF1dGhvcml6YXRpb24gc2NvcGUgdmFsdWVz IGZvciB0aGUgQ2xpZW50IHRvCiAgICAgICAgICAgICAgaW5jbHVkZS4KPC9kZD4KPGR0PkFkZGl0 aW9uYWwgcGFyYW1ldGVyczwvZHQ+CjxkZD4gQW55IGFkZGl0aW9uYWwKICAgICAgICAgICAgICBw YXJhbWV0ZXJzLCBhcyBkZWZpbmVkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4KPC9kZD4K PC9kbD48L2Jsb2NrcXVvdGU+Cgo8YSBuYW1lPSJhbmNob3IzOCI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjYuMy4zIj48L2E+PGgzPjYuMy4zLiZuYnNwOwpBdXRob3JpemF0aW9uIFNlcnZl ciBDb25maXJtcyBBdXRob3JpemF0aW9uIFJlcXVlc3Qgd2l0aCBVc2VyPC9oMz4KCjxwPlVwb24g cmVjZWl2aW5nIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBmcm9tIHRoZSBDbGllbnQgYnkgd2F5 IG9mCiAgICAgICAgICB0aGUgVXNlcidzIGJyb3dzZXIsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZl ciBhdXRoZW50aWNhdGVzIHRoZSB1c2VyLAogICAgICAgICAgcHJlc2VudHMgdGhlIFVzZXIgd2l0 aCB0aGUgUHJvdGVjdGVkIFJlc291cmNlIGFjY2VzcyB0aGF0IHdpbGwgYmUKICAgICAgICAgIGdy YW50ZWQgdG8gdGhlIENsaWVudCwgYW5kIHByb21wdHMgdGhlIFVzZXIgdG8gY29uZmlybSB0aGUg cmVxdWVzdC4KICAgICAgICAgIElmIHRoZSBVc2VyIGFwcHJvdmVzIHRoZSByZXF1ZXN0LCB0aGUg QXV0aG9yaXphdGlvbiBTZXJ2ZXIgZ2VuZXJhdGVzCiAgICAgICAgICBhIFZlcmlmaWNhdGlvbiBD b2RlLiBJZiB0aGUgVXNlciBkZW5pZWQgYWNjZXNzLCB0aGUgQXV0aG9yaXphdGlvbgogICAgICAg ICAgU2VydmVyIE1BWSBzZXQgdGhlIFZlcmlmaWNhdGlvbiBDb2RlIHRvIHRoZSByZXNlcnZlZCB2 YWx1ZToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxl ZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgogIHVzZXJfZGVuaWVkCjwvcHJlPjwv ZGl2Pgo8cD5JdCBpcyBSRUNPTU1FTkRFRCB0aGUgVmVyaWZpY2F0aW9uIENvZGUgYmUgc2luZ2xl IHVzZSwgYW5kIGV4cGlyZQogICAgICAgICAgd2l0aGluIG1pbnV0ZXMgb2YgaXNzdWUuIFRoZXJl IGFyZSBhIG51bWJlciBvZiBtZWNoYW5pc21zIGZvciB0aGUKICAgICAgICAgIEF1dGhvcml6YXRp b24gU2VydmVyIHRvIHRyYW5zbWl0IHRoZSBWZXJpZmljYXRpb24gQ29kZSB0byB0aGUKICAgICAg ICAgIENsaWVudCwgc3BlY2lmaWVkIGJlbG93Lgo8L3A+CjxwPlJpY2ggQXBwbGljYXRpb24gaW50 ZXJhY3Rpb24gd2l0aCB0aGUgVXNlciBhbmQgdGhlIEF1dGhvcml6YXRpb24KICAgICAgICAgIFNl cnZlciBpcyBhbiBhcmVhIG9mIGFjdGl2ZSByZXNlYXJjaCBhbmQgZGV2ZWxvcG1lbnQuIElmIHRo ZSBSaWNoCiAgICAgICAgICBBcHBsaWNhdGlvbiBpcyBhYmxlIHRvIHJldHJpZXZlIHRoZSB2ZXJp ZmllciBkaXJlY3RseSBmcm9tIHRoZQogICAgICAgICAgY2FsbGJhY2sgVVJMIHJldHVybmVkIGJ5 IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciwgYW4gaW1wcm92ZWQgdXNlcgogICAgICAgICAgZXhw ZXJpZW5jZSBpcyBwb3NzaWJsZS4gSG93ZXZlciwgbm90IGFsbCBhcHBsaWNhdGlvbnMgYXJlIGFi bGUgdG8KICAgICAgICAgIGludGVyYWN0IHdpdGggdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGlu IHRoaXMgbWFubmVyLgo8L3A+CjxhIG5hbWU9ImFuY2hvcjM5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uNi4zLjMuMSI+PC9hPjxoMz42LjMuMy4xLiZuYnNwOwpBcHBsaWNhdGlvbnMgd2l0 aCBDYWxsYmFjayBVUkxzPC9oMz4KCjxwPlJpY2ggQXBwbGljYXRpb25zIG1heSBiZSBhYmxlIHRv IHJlY2VpdmUgY2FsbGJhY2sgVVJMcyBpbiBhbnkKICAgICAgICAgICAgb2Ygc2V2ZXJhbCB3YXlz LiBGb3IgZXhhbXBsZSwgdGhlIFJpY2ggQXBwbGljYXRpb24gbWF5IHJlZ2lzdGVyIGEKICAgICAg ICAgICAgY3VzdG9tIHByb3RvY29sIGhhbmRsZXIgd2l0aCB0aGUgYXBwbGljYXRpb24gcGxhdGZv cm0gc28gdGhhdCB0aGUKICAgICAgICAgICAgYXBwbGljYXRpb24gd2lsbCBiZSBpbnZva2VkIHdo ZW4gdGhlIGJyb3dzZXIgaXMgcmVkaXJlY3RlZCB0byB0aGUKICAgICAgICAgICAgY2FsbGJhY2sg VVJMLiBBbHRlcm5hdGl2ZWx5LCB0aGUgY2FsbGJhY2sgVVJMIG1heSBwb2ludCB0byBhIHdlYgog ICAgICAgICAgICBzaXRlIHdpdGggd2hpY2ggdGhlIFJpY2ggQXBwbGljYXRpb24gaGFzIGEgdHJ1 c3QgcmVsYXRpb25zaGlwLiBUaGUKICAgICAgICAgICAgd2ViIHNpdGUgY2FuIHRoZW4gcGFzcyB0 aGUgQ2FsbGJhY2sgVVJMIGRvd24gdG8gdGhlIFJpY2gKICAgICAgICAgICAgQXBwbGljYXRpb24g Zm9yIHByb2Nlc3NpbmcuIEZpbmFsbHksIHRoZSBDYWxsYmFjayBVUkwgbWF5IHBvaW50IHRvCiAg ICAgICAgICAgIGEgd2ViIHNpdGUgdGhhdCB3aWxsIGRpc3BsYXkgdGhlIENhbGxiYWNrIFVSTCB0 byB0aGUgc2NyZWVuIGFsb25nCiAgICAgICAgICAgIHdpdGggaW5zdHJ1Y3Rpb25zIGZvciB0aGUg dXNlciB0byBlbnRlciB0aGUgVmVyaWZpY2F0aW9uIENvZGUgaW50bwogICAgICAgICAgICB0aGUg YXBwbGljYXRpb24uCjwvcD4KPHA+Rm9yIFJpY2ggQXBwbGljYXRpb25zIHdpdGggYSBDYWxsYmFj ayBVUkwsIHRoZSBBdXRob3JpemF0aW9uCiAgICAgICAgICAgIFNlcnZlciBNVVNUIHJlZGlyZWN0 IHRoZSBVc2VyIGJhY2sgdG8gdGhlIENhbGxiYWNrIFVSTCwgd2l0aCB0aGUKICAgICAgICAgICAg Zm9sbG93aW5nIHBhcmFtZXRlcnMgYWRkZWQ6CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFz cz0idGV4dCI+PGRsPgo8ZHQ+d3JhcF92ZXJpZmljYXRpb25fY29kZTwvZHQ+CjxkZD4gUkVRVUlS RUQuIFRoZQogICAgICAgICAgICAgICAgVmVyaWZpY2F0aW9uIENvZGUKPC9kZD4KPGR0PndyYXBf Y2xpZW50X3N0YXRlPC9kdD4KPGRkPiBSRVFVSVJFRCBpZiB0aGUKICAgICAgICAgICAgICAgIENs aWVudCBzZW50IHRoZSB2YWx1ZSBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGluIDxhIGNs YXNzPSdpbmZvJyBocmVmPScjcDUuYXV0aG9yaXphdGlvbic+U2VjdGlvbiZuYnNwOzYuMy4yPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNsaWVudCBEaXJlY3RzIHRoZSBVc2VyIHRv IHRoZSAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPgo8 L2RkPgo8ZHQ+QWRkaXRpb25hbCAgICBwYXJhbWV0ZXJzPC9kdD4KPGRkPiBBbnkKICAgICAgICAg ICAgICAgIGFkZGl0aW9uYWwgcGFyYW1ldGVycywgYXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXph dGlvbgogICAgICAgICAgICAgICAgU2VydmVyLgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KCjxw PklmIHRoZSBVc2VyIGRlbmllZCBhY2Nlc3MsIHRoZSBTZXJ2ZXIgTUFZIHJlZGlyZWN0IHRoZSBV c2VyJ3MKICAgICAgICAgICAgYnJvd3NlciB0byB0aGUgQ2FsbGJhY2sgVVJMIHdpdGggdGhlIFZl cmlmaWNhdGlvbiBDb2RlIHNldCB0byB0aGUKICAgICAgICAgICAgcmVzZXJ2ZWQgdmFsdWU6Cjwv cD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07 IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICB1c2VyX2RlbmllZAo8L3ByZT48L2Rpdj4KPGEg bmFtZT0iYW5jaG9yNDAiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjMuMy4yIj48L2E+ PGgzPjYuMy4zLjIuJm5ic3A7CkFwcGxpY2F0aW9ucyB3aXRob3V0IENhbGxiYWNrIFVSTHM8L2gz PgoKPHA+UmljaCBBcHBsaWNhdGlvbnMgd2l0aG91dCBDYWxsYmFjayBVUkxzIG5lZWQgdG8gcmVj ZWl2ZSB0aGUKICAgICAgICAgICAgdmVyaWZpY2F0aW9uIGNvZGUgaW4gb3RoZXIgd2F5cy4gRm9y IFJpY2ggQXBwbGljYXRpb25zIHdpdGhvdXQgYQogICAgICAgICAgICBDYWxsYmFjayBVUkwsIHRo ZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHByZXNlbnQgdGhlCiAgICAgICAgICAgIFZlcmlm aWNhdGlvbiBDb2RlIG9uIHRoZSB3ZWIgcGFnZSBhbmQgaW5zdHJ1Y3QgdGhlIHVzZXIgdG8gZW50 ZXIKICAgICAgICAgICAgaXQgaW50byB0aGUgQ2xpZW50Lgo8L3A+CjxwPlRoZSBTZXJ2ZXIgTUFZ IGFsc28gYXBwZW5kIHRoZSBWZXJpZmljYXRpb24gQ29kZSB0byB0aGUgdGl0bGUKICAgICAgICAg ICAgb2YgdGhlIEhUTUwgcGFnZSBzbyB0aGF0IENsaWVudHMgdGhhdCBoYXZlIGFjY2VzcyB0byB0 aGUgdGl0bGUgb2YKICAgICAgICAgICAgdGhlIGJyb3dzZXIncyBjdXJyZW50IHBhZ2UgY2FuIG9i dGFpbiB0aGUgVmVyaWZpY2F0aW9uIENvZGUKICAgICAgICAgICAgd2l0aG91dCByZXF1aXJpbmcg dGhlIFVzZXIgZW50ZXIgdGhlIFZlcmlmaWNhdGlvbiBDb2RlIGludG8gdGhlCiAgICAgICAgICAg IENsaWVudC4gVGhlIENsaWVudCBjYW4gcGFyc2UgdGhlIHRpdGxlIGxvb2tpbmcgZm9yICJjb2Rl PSIgYW5kCiAgICAgICAgICAgIHRoZW4gdGhlIHJlc3Qgb2YgdGhlIHRpdGxlIGlzIHRoZSBWZXJp ZmljYXRpb24gQ29kZS4gSWYgYWRkaW5nIHRoZQogICAgICAgICAgICBWZXJpZmljYXRpb24gQ29k ZSB0byB0aGUgdGl0bGUgb2YgdGhlIEhUTUwgcGFnZSwgdGhlIFNlcnZlciBNVVNUCiAgICAgICAg ICAgIGFsc28gaW5jbHVkZSB0aGUgd3JhcF9jbGllbnRfc3RhdGUgcGFyYW1ldGVyIGlmIHNlbnQg ZnJvbSB0aGUKICAgICAgICAgICAgQ2xpZW50IGFzIHRoZSAic3RhdGU9IiBwYXJhbWV0ZXIuCjwv cD4KPHA+RWcuIEZvciBleGFtcGxlLmNvbSB3aGVyZSB0aGUgVmVyaWZpY2F0aW9uIENvZGUgPSBX RjM0RjdIRyBhbmQKICAgICAgICAgICAgQ2xpZW50IFN0YXRlID0gTk1NR0ZKSiwgdGhlIFNlcnZl ciB3b3VsZCBzZXQgdGhlIHRpdGxlIG9mIHRoZSBwYWdlCiAgICAgICAgICAgIHRvIHNvbWV0aGlu ZyBsaWtlOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4t bGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+ICZsdDt0aXRsZSZndDtTdWNjZXNz ZnVsIGRlbGVnYXRpb24sIGNvZGU9V0YzNEY3SEcKc3RhdGU9Tk1NR0ZKSiZsdDsvdGl0bGUmZ3Q7 PC9wcmU+PC9kaXY+CjxwPklmIHRoZSBVc2VyIGRlbmllZCBhY2Nlc3MsIHRoZSBTZXJ2ZXIgTUFZ IGFwcGVuZAogICAgICAgICAgICBjb2RlPXVzZXJfZGVuaWVkIHRvIHRoZSB0aXRsZSBvZiB0aGUg SFRNTCBwYWdlIHNvIHRoYXQgdGhlIENsaWVudAogICAgICAgICAgICBjYW4gZGV0ZWN0IHRoYXQg dGhlIFVzZXIgaGFzIGRlbmllZCBhY2Nlc3MuCjwvcD4KPGEgbmFtZT0icDUucmVxdWVzdCI+PC9h PjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2Vs bHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0i VE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFi bGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjYuMy40Ij48L2E+PGgzPjYuMy40LiZuYnNwOwpDbGll bnQgUmVxdWVzdHMgQWNjZXNzIFRva2VuPC9oMz4KCjxwPlRoZSBDbGllbnQgbWFrZXMgYW4gSFRU UFMgcmVxdWVzdCB0byB0aGUgU2VydmVyJ3MgQWNjZXNzIFRva2VuCiAgICAgICAgICBVUkwgdXNp bmcgUE9TVC4gVGhlIHJlcXVlc3QgY29udGFpbnMgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzOgo8 L3A+CjxwPjwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PndyYXBfY2xpZW50 X2lkPC9kdD4KPGRkPiBSRVFVSVJFRC4gVGhlIENsaWVudAogICAgICAgICAgICAgIElkZW50aWZp ZXIKPC9kZD4KPGR0PndyYXBfdmVyaWZpY2F0aW9uX2NvZGU8L2R0Pgo8ZGQ+IFJFUVVJUkVELiBU aGUKICAgICAgICAgICAgICBWZXJpZmljYXRpb24gQ29kZS4KPC9kZD4KPGR0PkFkZGl0aW9uYWwg cGFyYW1ldGVyczo8L2R0Pgo8ZGQ+QW55IGFkZGl0aW9uYWwKICAgICAgICAgICAgICBwYXJhbWV0 ZXJzLCBhcyBkZWZpbmVkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4KPC9kZD4KPC9kbD48 L2Jsb2NrcXVvdGU+Cgo8YSBuYW1lPSJwNS52ZXJpZmljYXRpb24iPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi42LjMuNSI+PC9hPjxoMz42LjMuNS4mbmJzcDsKU3VjY2Vzc2Z1bCBBY2Nlc3Mg VG9rZW4gUmVzcG9uc2UgZnJvbSBBdXRob3JpemF0aW9uIFNlcnZlcjwvaDM+Cgo8cD5UaGUgU2Vy dmVyIGNoZWNrcyB0aGUgVmVyaWZpY2F0aW9uIENvZGUgd2FzIHByZXZpb3VzbHkgaXNzdWVkIHRv CiAgICAgICAgICB0aGUgc2FtZSBDbGllbnQgSWRlbnRpZmllciwgaGFzIG5vdCBleHBpcmVkIGFu ZCBoYXMgbm90IGJlZW4gdXNlZC4KICAgICAgICAgIElmIHRoZXNlIGNvbmRpdGlvbnMgYXJlIG1l dCwgdGhlIFNlcnZlciBtYXJrcyB0aGUgVmVyaWZpY2F0aW9uIENvZGUKICAgICAgICAgIGFzIGJl aW5nIHVzZWQgYW5kIHJldHVybnM6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lk dGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICBIVFRQ IDIwMCBPSwo8L3ByZT48L2Rpdj4KPHA+d2l0aCB0aGUgUmVmcmVzaCBUb2tlbiBhbmQgYW4gQWNj ZXNzIFRva2VuIGluIHRoZSByZXNwb25zZSBib2R5LgogICAgICAgICAgVGhlIHJlc3BvbnNlIGJv ZHkgY29udGFpbnMgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzOgo8L3A+CjxwPjwvcD4KPGJsb2Nr cXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PndyYXBfcmVmcmVzaF90b2tlbjwvZHQ+CjxkZD4g UkVRVUlSRUQuIFRoZQogICAgICAgICAgICAgIFJlZnJlc2ggVG9rZW4uCjwvZGQ+CjxkdD53cmFw X2FjY2Vzc190b2tlbjwvZHQ+CjxkZD4gUkVRVUlSRUQuIFRoZSBBY2Nlc3MKICAgICAgICAgICAg ICBUb2tlbi4KPC9kZD4KPGR0PndyYXBfYWNjZXNzX3Rva2VuX2V4cGlyZXNfaW48L2R0Pgo8ZGQ+ IE9QVElPTkFMLgogICAgICAgICAgICAgIFRoZSBsaWZldGltZSBvZiB0aGUgQWNjZXNzIFRva2Vu IGluIHNlY29uZHMuIEZvciBleGFtcGxlLCAzNjAwCiAgICAgICAgICAgICAgcmVwcmVzZW50cyBv bmUgaG91ci4KPC9kZD4KPGR0PkFkZGl0aW9uYWwgcGFyYW1ldGVyczwvZHQ+CjxkZD4gQW55IGFk ZGl0aW9uYWwKICAgICAgICAgICAgICBwYXJhbWV0ZXJzLCBhcyBkZWZpbmVkIGJ5IHRoZSBBdXRo b3JpemF0aW9uIFNlcnZlci4KPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+Cgo8cD5UaGUgQ2xpZW50 IHNlY3VyZWx5IHN0b3JlcyB0aGUgUmVmcmVzaCBUb2tlbiBmb3IgbGF0ZXIgdXNlLiBUaGUKICAg ICAgICAgIENsaWVudCBtYXkgbm93IHVzZSB0aGUgQWNjZXNzIFRva2VuIHRvIGFjY2VzcyB0aGUg UHJvdGVjdGVkIFJlc291cmNlCiAgICAgICAgICBwZXIgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNQ cm90ZWN0ZWRSZXNvdXJjZSc+U2VjdGlvbiZuYnNwOzQ8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+QWNjZXNzaW5nIGEgUHJvdGVjdGVkIFJlc291cmNlPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPi4KPC9wPgo8YSBuYW1lPSJhbmNob3I0MSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0 aW9uLjYuMy42Ij48L2E+PGgzPjYuMy42LiZuYnNwOwpVbnN1Y2Nlc3NmdWwgQWNjZXNzIFRva2Vu IFJlc3BvbnNlIGZyb20gQXV0aG9yaXphdGlvbiBTZXJ2ZXI8L2gzPgoKPHA+VGhlIEF1dGhvcml6 YXRpb24gU2VydmVyIE1VU1QgZmlyc3QgdmVyaWZ5IHRoZSBDbGllbnQgSWRlbnRpZmllcgogICAg ICAgICAgYW5kIENsaWVudCBTZWNyZXQgcGVyIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcDUudmVy aWZpY2F0aW9uJz5TZWN0aW9uJm5ic3A7Ni4zLjU8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+U3VjY2Vzc2Z1bCBBY2Nlc3MgVG9rZW4gUmVzcG9uc2UgZnJvbSBBdXRob3JpemF0aW9u IFNlcnZlcjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uIElmCiAgICAgICAgICB0aGV5IGFyZSBp bnZhbGlkLCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXNwb25kIHdpdGg6CjwvcD48 ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1h cmdpbi1yaWdodDogYXV0byc+PHByZT4KICBIVFRQIDQwMSBVbmF1dGhvcml6ZWQKPC9wcmU+PC9k aXY+CjxwPmFuZCB0aGUgSFRUUCBoZWFkZXI6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJs ZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4K ICBXV1ctQXV0aGVudGljYXRlOiBXUkFQCjwvcHJlPjwvZGl2Pgo8cD5UaGUgQ2xpZW50IG5lZWRz IHRvIG9idGFpbiBhIG5ldyBWZXJpZmljYXRpb24gQ29kZSBwZXIgPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyNwNS5hdXRob3JpemF0aW9uJz5TZWN0aW9uJm5ic3A7Ni4zLjI8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+Q2xpZW50IERpcmVjdHMgdGhlIFVzZXIgdG8gdGhlICAgICAgQXV0 aG9yaXphdGlvbiBTZXJ2ZXI8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Lgo8L3A+CjxhIG5hbWU9 ImFuY2hvcjQyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi4zLjciPjwvYT48aDM+Ni4z LjcuJm5ic3A7CkNsaWVudCBSZWZyZXNoZXMgQWNjZXNzIFRva2VuPC9oMz4KCjxwPlJlZnJlc2hp bmcgYW4gQWNjZXNzIFRva2VuIGlzIHRoZSBzYW1lIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj cDMnPlNlY3Rpb24mbmJzcDs2LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+VXNl cm5hbWUgYW5kIFBhc3N3b3JkIFByb2ZpbGU8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCA8YSBj bGFzcz0naW5mbycgaHJlZj0nI3A0Jz5TZWN0aW9uJm5ic3A7Ni4yPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPldlYiBBcHAgUHJvZmlsZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4s IGFuZCA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3A1Jz5TZWN0aW9uJm5ic3A7Ni4zPHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlJpY2ggQXBwIFByb2ZpbGU8L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+LiBBdXRob3JpemF0aW9uIFNlcnZlcnMgU0hPVUxEIGlzc3VlIEFjY2VzcwogICAg ICAgICAgVG9rZW5zIHRoYXQgZXhwaXJlIGFuZCByZXF1aXJlIENsaWVudHMgdG8gcmVmcmVzaCB0 aGVtLiBVcG9uCiAgICAgICAgICByZWNlaXZpbmcgdGhlIEhUVFAgNDAxIHJlc3BvbnNlIHdoZW4g YWNjZXNzaW5nIHByb3RlY3RlZCByZXNvdXJjZXMKICAgICAgICAgIHBlciA8YSBjbGFzcz0naW5m bycgaHJlZj0nI1Byb3RlY3RlZFJlc291cmNlJz5TZWN0aW9uJm5ic3A7NDxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3NpbmcgYSBQcm90ZWN0ZWQgUmVzb3VyY2U8L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+LCB0aGUgQ2xpZW50IG1ha2VzIGFuCiAgICAgICAgICBIVFRQUyBy ZXF1ZXN0IHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcidzIFJlZnJlc2ggVG9rZW4gVVJMIHVz aW5nCiAgICAgICAgICBQT1NULiBUaGUgcmVxdWVzdCBjb250YWlucyB0aGUgZm9sbG93aW5nIHBh cmFtZXRlcnM6CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+ d3JhcF9yZWZyZXNoX3Rva2VuPC9kdD4KPGRkPlJFUVVJUkVELiBUaGUgUmVmcmVzaAogICAgICAg ICAgICAgIFRva2VuIHRoYXQgd2FzIHJlY2VpdmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj cDUucmVxdWVzdCc+U2VjdGlvbiZuYnNwOzYuMy40PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9 J2luZm8nPkNsaWVudCBSZXF1ZXN0cyBBY2Nlc3MgVG9rZW48L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+CjwvZGQ+CjxkdD5BZGRpdGlvbmFsIHBhcmFtZXRlcnM6PC9kdD4KPGRkPkFueSBhZGRpdGlv bmFsCiAgICAgICAgICAgICAgcGFyYW1ldGVycywgYXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXIuCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPgoKPGEgbmFtZT0iYW5jaG9yNDMi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjMuOCI+PC9hPjxoMz42LjMuOC4mbmJzcDsK U3VjY2Vzc2Z1bCBBY2Nlc3MgVG9rZW4gUmVmcmVzaDwvaDM+Cgo8cD5JZiBzdWNjZXNzZnVsLCB0 aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgcmV0dXJuczoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6 IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48 cHJlPgogIEhUVFAgMjAwIE9LCjwvcHJlPjwvZGl2Pgo8cD53aXRoIHRoZSBBY2Nlc3MgVG9rZW4g aW4gdGhlIHJlc3BvbnNlIGJvZHkuIFRoZSByZXNwb25zZSBib2R5CiAgICAgICAgICBjb250YWlu cyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFz cz0idGV4dCI+PGRsPgo8ZHQ+d3JhcF9hY2Nlc3NfdG9rZW48L2R0Pgo8ZGQ+IFJFUVVJUkVELiBU aGUgQWNjZXNzCiAgICAgICAgICAgICAgVG9rZW4uCjwvZGQ+CjxkdD53cmFwX2FjY2Vzc190b2tl bl9leHBpcmVzX2luPC9kdD4KPGRkPiBPUFRJT05BTC4KICAgICAgICAgICAgICBUaGUgbGlmZXRp bWUgb2YgdGhlIEFjY2VzcyBUb2tlbiBpbiBzZWNvbmRzLiBGb3IgZXhhbXBsZSwgMzYwMAogICAg ICAgICAgICAgIHJlcHJlc2VudHMgb25lIGhvdXIuCjwvZGQ+CjxkdD5BZGRpdGlvbmFsICAgIHBh cmFtZXRlcnM8L2R0Pgo8ZGQ+IEFueSBhZGRpdGlvbmFsCiAgICAgICAgICAgICAgcGFyYW1ldGVy cywgYXMgZGVmaW5lZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuCjwvZGQ+CjwvZGw+PC9i bG9ja3F1b3RlPgoKPGEgbmFtZT0iYW5jaG9yNDQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi42LjMuOSI+PC9hPjxoMz42LjMuOS4mbmJzcDsKVW5zdWNjZXNzZnVsIEFjY2VzcyBUb2tlbiBS ZWZyZXNoPC9oMz4KCjxwPlRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHZlcmlmeSB0aGUg UmVmcmVzaCBUb2tlbi4gSWYgdGhlCiAgICAgICAgICB2ZXJpZmljYXRpb24gZmFpbHMsIHRoZSBB dXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHJlc3BvbmQgd2l0aAo8L3A+PGRpdiBzdHlsZT0nZGlz cGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1 dG8nPjxwcmU+CiAgSFRUUCA0MDEgVW5hdXRob3JpemVkCjwvcHJlPjwvZGl2Pgo8cD5hbmQgdGhl IEhUVFAgaGVhZGVyOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBt YXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CiAgV1dXLUF1dGhlbnRp Y2F0ZTogV1JBUAo8L3ByZT48L2Rpdj4KPHA+VGhlIENsaWVudCBNVVNUIGFnYWluIHJlcXVlc3Qg YXV0aG9yaXphdGlvbiBmcm9tIHRoZSBVc2VyIHBlcgogICAgICAgICAgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNwNS5hdXRob3JpemF0aW9uJz5TZWN0aW9uJm5ic3A7Ni4zLjI8c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+Q2xpZW50IERpcmVjdHMgdGhlIFVzZXIgdG8gdGhlICAgICAg QXV0aG9yaXphdGlvbiBTZXJ2ZXI8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Lgo8L3A+CjxhIG5h bWU9IlBhcmFtQ29uIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNyI+PC9hPjxoMz43LiZu YnNwOwpQYXJhbWV0ZXIgQ29uc2lkZXJhdGlvbnM8L2gzPgoKPGEgbmFtZT0iYW5jaG9yNDUiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi43LjEiPjwvYT48aDM+Ny4xLiZuYnNwOwpBdXRob3Jp emF0aW9uIFNlcnZlciBSZXF1ZXN0IC8gUmVzcG9uc2UgUGFyYW1ldGVyICAgICAgIEVuY29kaW5n PC9oMz4KCjxwPkFsbCByZXF1ZXN0cyBtYWRlIGRpcmVjdGx5IHRvIHRoZSBBdXRob3JpemF0aW9u IFNlcnZlciB1c2UgdGhlIEhUVFAKICAgICAgICBQT1NUIG1ldGhvZCBhbmQgdGhlIHBhcmFtZXRl cnMgTVVTVCBiZSBpbiB0aGUgYm9keSBvZiB0aGUgbWVzc2FnZSBhbmQKICAgICAgICBmb3JtYXR0 ZWQgYXMgYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIHBlciA8YSBocmVmPSdodHRw Oi8vd3d3LnczLm9yZy9UUi8xOTk5L1JFQy1XM0MuUkVDLWh0bWw0MC0xOTk4MDQyNC0xOTk5MTIy NC9pbnRlcmFjdC9mb3Jtcy5odG1sI2gtMTcuMTMuNC4xJz4xNy4xMy40PC9hPgogICAgICAgIG9m IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjVzNDLlJFQy1odG1sNDAtMTk5ODA0MjQnPkhUTUwgNC4w MTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Ib3JzLCBBLiwgSmFjb2JzLCBJLiwg YW5kIEQuIFJhZ2dldHQsICZsZHF1bztIVE1MIDQuMCBTcGVjaWZpY2F0aW9uLCZyZHF1bzsgQXBy aWwmbmJzcDsxOTk4Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1czQy5SRUMmIzgyMDk7aHRt bDQwJiM4MjA5OzE5OTgwNDI0XS4KPC9wPgo8cD5BbnkgcGFyYW1ldGVycyBpbiB0aGUgcmVzcG9u c2UgZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVAogICAgICAgIGJlIGluIHRoZSBi b2R5IG9mIHRoZSBtZXNzYWdlIGFuZCBmb3JtYXR0ZWQgYXMKICAgICAgICBhcHBsaWNhdGlvbi94 LXd3dy1mb3JtLXVybGVuY29kZWQgcGVyIDxhIGhyZWY9J2h0dHA6Ly93d3cudzMub3JnL1RSLzE5 OTkvUkVDLVczQy5SRUMtaHRtbDQwLTE5OTgwNDI0LTE5OTkxMjI0L2ludGVyYWN0L2Zvcm1zLmh0 bWwjaC0xNy4xMy40LjEnPjE3LjEzLjQ8L2E+CiAgICAgICAgb2YgPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyNXM0MuUkVDLWh0bWw0MC0xOTk4MDQyNCc+SFRNTCA0LjAxPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPkhvcnMsIEEuLCBKYWNvYnMsIEkuLCBhbmQgRC4gUmFnZ2V0dCwgJmxk cXVvO0hUTUwgNC4wIFNwZWNpZmljYXRpb24sJnJkcXVvOyBBcHJpbCZuYnNwOzE5OTguPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPiBbVzNDLlJFQyYjODIwOTtodG1sNDAmIzgyMDk7MTk5ODA0MjRd Lgo8L3A+CjxhIG5hbWU9ImFuY2hvcjQ2Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5 PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIg YWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNy4y Ij48L2E+PGgzPjcuMi4mbmJzcDsKUGFyYW1ldGVyIFNpemU8L2gzPgoKPHA+PC9wPgo8YmxvY2tx dW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+SFRUUCBIZWFkZXJzPC9kdD4KPGRkPiBXZWIgc2Vy dmVycyBvZnRlbiBpbXBvc2UgYQogICAgICAgICAgICBtYXhpbXVtIG9uIHRoZSBjb21iaW5lZCBz aXplIG9mIGFsbCBIVFRQIGhlYWRlcnMgcmFuZ2luZyBmcm9tIDhLQgogICAgICAgICAgICB0byAx NktCLiBUaGUgc2l6ZSBvZiB0aGUgQWNjZXNzIFRva2VuIHNob3VsZCBiZSBzbWFsbCBlbm91Z2gg dG8KICAgICAgICAgICAgZW5zdXJlIHRoZSB0b3RhbCBzaXplIG9mIHRoZSBIVFRQIGhlYWRlcnMg ZG9lcyBub3QgZXhjZWVkIHRoZQogICAgICAgICAgICBsaW1pdHMgb2Ygd2ViIHNlcnZlcnMuCjwv ZGQ+CjxkdD5VUkxzPC9kdD4KPGRkPiBXZWIgc2VydmVycyBhbmQgYnJvd3NlcnMgb2Z0ZW4KICAg ICAgICAgICAgaW1wb3NlIGEgbWF4aW11bSBvbiB0aGUgdG90YWwgbGVuZ3RoIG9mIHRoZSBVUkwg b2YgYXMgbG93IGFzIDIwODMKICAgICAgICAgICAgYnl0ZXMuIFRoZSBsZW5ndGggb2YgVVJMcyBl eHBvc2VkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQKICAgICAgICAgICAgdGhlIGxl bmd0aCBvZiBwYXJhbWV0ZXJzIHBhc3NlZCBvbiBhIFVSTCBzaG91bGQgYmUgbWluaW1pemVkIHNv CiAgICAgICAgICAgIHRoYXQgdGhlIHRvdGFsIGxlbmd0aCBkb2VzIG5vdCBleGNlZWQgdGhpcyBs aW1pdC4KPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+Cgo8YSBuYW1lPSJhbmNob3I0NyI+PC9hPjxi ciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9D YnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+ CjxhIG5hbWU9InJmYy5zZWN0aW9uLjcuMyI+PC9hPjxoMz43LjMuJm5ic3A7CkFjY2VzcyBUb2tl biBGb3JtYXQ8L2gzPgoKPHA+T0F1dGggV1JBUCBkb2VzIG5vdCBzcGVjaWZ5IHRoZSBmb3JtYXQg b2YgdGhlIEFjY2VzcyBUb2tlbi4gVGhlCiAgICAgICAgZm9ybWF0IGlzIG11dHVhbGx5IGFncmVl ZCB0byBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRoZQogICAgICAgIFByb3RlY3Rl ZCBSZXNvdXJjZSBhbmQgaXMgb3BhcXVlIHRvIHRoZSBDbGllbnQuIFRoZSBBY2Nlc3MgVG9rZW4K ICAgICAgICBmb3JtYXQgTVVTVCBjb25zaXN0IG9mIGxlZ2FsIGNoYXJhY3RlcnMgaW4gYW4gSFRU UCBoZWFkZXIgcGVyCiAgICAgICAgW1JlZmVyZW5jZSBuZWVkZWRdCjwvcD4KPHA+VGhlIFNpbXBs ZSBXZWIgVG9rZW4gKFNXVCkgYW5kIEpTT04gV2ViIFRva2VuIChKV1QpIGFyZSBwb3NzaWJsZQog ICAgICAgIEFjY2VzcyBUb2tlbiBmb3JtYXRzLgo8L3A+CjxwPltUQkQ6IGVudHJvcHkgcmVjb21t ZW5kYXRpb25zIGZvciBBY2Nlc3MgVG9rZW4gc28gdGhhdCBpdCByZW1haW5zCiAgICAgICAgc2Vj dXJlIGR1cmluZyBpdHMgbGlmZXRpbWVdCjwvcD4KPGEgbmFtZT0iYW5jaG9yNDgiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi43LjQiPjwvYT48aDM+Ny40LiZuYnNwOwpSZWZyZXNoIFRva2Vu IEZvcm1hdDwvaDM+Cgo8cD5PQXV0aCBXUkFQIGRvZXMgbm90IHNwZWNpZnkgdGhlIGZvcm1hdCBv ZiB0aGUgUmVmcmVzaCBUb2tlbi4gVGhlCiAgICAgICAgUmVmcmVzaCBUb2tlbiBpcyBib3RoIGdl bmVyYXRlZCBhbmQgY29uc3VtZWQgYnkgdGhlIEF1dGhvcml6YXRpb24KICAgICAgICBTZXJ2ZXIg YW5kIGlzIG9wYXF1ZSB0byB0aGUgQ2xpZW50IGFuZCBuZXZlciBleHBvc2VkIHRvIHRoZSBQcm90 ZWN0ZWQKICAgICAgICBSZXNvdXJjZS4gVGhlIFJlZnJlc2ggVG9rZW4gaXMgYSBsb25nIGxpdmVk IGNyZWRlbnRpYWwsIGFuZCBzaG91bGQKICAgICAgICBjb250YWluIGVub3VnaCBlbnRyb3B5IHRo YXQgaXQgY2Fubm90IGJlIGd1ZXNzZWQuIFRoZSBzaXplIGxpbWl0YXRpb25zCiAgICAgICAgb2Yg dGhlIEFjY2VzcyBUb2tlbiBhcmUgbm90IGFwcGxpY2FibGUgdG8gdGhlIFJlZnJlc2ggVG9rZW4g YXMgdGhlCiAgICAgICAgUmVmcmVzaCBUb2tlbiBpcyBhbHdheXMgaW4gdGhlIGJvZHkgb2YgYW4g SFRUUCBtZXNzYWdlLgo8L3A+CjxhIG5hbWU9ImFuY2hvcjQ5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uNy41Ij48L2E+PGgzPjcuNS4mbmJzcDsKQWRkaXRpb25hbCBBdXRob3JpemF0aW9u IFNlcnZlciBQYXJhbWV0ZXJzPC9oMz4KCjxwPlRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBtYXkg ZGVmaW5lIGFkZGl0aW9uYWwgcGFyYW1ldGVycyB0byBiZQogICAgICAgIGluY2x1ZGVkIGluIGFy ZSByZXR1cm5lZCBmcm9tIGNhbGxzIHRvIHRoZSBBY2Nlc3MgVG9rZW4gVVJMIG9yIFVzZXIKICAg ICAgICBBdXRob3JpemF0aW9uIFVSTC4gUGFyYW1ldGVycyB0aGF0IHN0YXJ0IHdpdGggd3JhcF8g YXJlIHJlc2VydmVkIGFuZAogICAgICAgIG1heSBub3QgYmUgdXNlZC4KPC9wPgo8YSBuYW1lPSJh bmNob3I1MCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjcuNiI+PC9hPjxoMz43LjYuJm5i c3A7ClBhcmFtZXRlciBOYW1lcyBhbmQgT3JkZXI8L2gzPgoKPHA+QWxsIHBhcmFtZXRlciBuYW1l cyBhcmUgY2FzZSBzZW5zaXRpdmUuIFRoZSBwYXJhbWV0ZXJzIG15IGFwcGVhciBpbgogICAgICAg IGFueSBvcmRlci4gVW5yZWNvZ25pemVkIHBhcmFtZXRlcnMgYXJlIGFsbG93ZWQsIGJ1dCBNVVNU IGJlCiAgICAgICAgaWdub3JlZC4KPC9wPgo8YSBuYW1lPSJJQU5BIj48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uOCI+PC9hPjxoMz44LiZuYnNwOwpJQU5BIENvbnNpZGVyYXRpb25zPC9oMz4K CjxwPlRoaXMgbWVtbyBpbmNsdWRlcyBubyByZXF1ZXN0IHRvIElBTkEuCjwvcD4KPGEgbmFtZT0i U2VjdXJpdHkiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0 cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwv dGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi45Ij48L2E+PGgzPjkuJm5ic3A7 ClNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC9oMz4KCjxwPlRCRDogbmVlZCB0byBwdXQgaW4gYWxs IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IKICAgICAgaW1wbGVtZW50b3JzLgo8L3A+ CjxhIG5hbWU9InJmYy5yZWZlcmVuY2VzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5 PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIg YWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTAi PjwvYT48aDM+MTAuJm5ic3A7ClJlZmVyZW5jZXM8L2gzPgoKPGEgbmFtZT0icmZjLnJlZmVyZW5j ZXMxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGgzPjEwLjEuJm5ic3A7Tm9ybWF0aXZlIFJlZmVyZW5jZXM8L2gzPgo8dGFi bGUgd2lkdGg9Ijk5JSIgYm9yZGVyPSIwIj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZh bGlnbj0idG9wIj48YSBuYW1lPSJSRkMyMTE5Ij5bUkZDMjExOV08L2E+PC90ZD4KPHRkIGNsYXNz PSJhdXRob3ItdGV4dCI+PGEgaHJlZj0ibWFpbHRvOnNvYkBoYXJ2YXJkLmVkdSI+QnJhZG5lciwg Uy48L2E+LCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjEx OSI+S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudCBMZXZl bHM8L2E+LCZyZHF1bzsgQkNQJm5ic3A7MTQsIFJGQyZuYnNwOzIxMTksIE1hcmNoJm5ic3A7MTk5 NyAoPGEgaHJlZj0iZnRwOi8vZnRwLmlzaS5lZHUvaW4tbm90ZXMvcmZjMjExOS50eHQiPlRYVDwv YT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvaHRtbC9yZmMy MTE5Lmh0bWwiPkhUTUw8L2E+LCA8YSBocmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJs aWMvcmZjL3htbC9yZmMyMTE5LnhtbCI+WE1MPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNz PSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzI2MDYiPltSRkMyNjA2XTwv YT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86ZGVlM0B1cy5p Ym0uY29tIj5FYXN0bGFrZSwgRC48L2E+IGFuZCA8YSBocmVmPSJtYWlsdG86YnVnbGFkeUBmdXNj aGlhLm5ldCI+QS4gUGFuaXR6PC9hPiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzI2MDYiPlJlc2VydmVkIFRvcCBMZXZlbCBETlMgTmFtZXM8L2E+LCZyZHF1 bzsgQkNQJm5ic3A7MzIsIFJGQyZuYnNwOzI2MDYsIEp1bmUmbmJzcDsxOTk5ICg8YSBocmVmPSJm dHA6Ly9mdHAuaXNpLmVkdS9pbi1ub3Rlcy9yZmMyNjA2LnR4dCI+VFhUPC9hPikuPC90ZD48L3Ry Pgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzI2 MTciPltSRkMyNjE3XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJt YWlsdG86am9obkBtYXRoLm53dS5lZHUiPkZyYW5rcywgSi48L2E+LCA8YSBocmVmPSJtYWlsdG86 cGJha2VyQHZlcmlzaWduLmNvbSI+SGFsbGFtLUJha2VyLCBQLjwvYT4sIDxhIGhyZWY9Im1haWx0 bzpqZWZmQEFiaVNvdXJjZS5jb20iPkhvc3RldGxlciwgSi48L2E+LCA8YSBocmVmPSJtYWlsdG86 bGF3cmVuY2VAYWdyYW5hdC5jb20iPkxhd3JlbmNlLCBTLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpw YXVsbGVAbWljcm9zb2Z0LmNvbSI+TGVhY2gsIFAuPC9hPiwgTHVvdG9uZW4sIEEuLCBhbmQgPGEg aHJlZj0ibWFpbHRvOnN0ZXdhcnRAT3Blbk1hcmtldC5jb20iPkwuIFN0ZXdhcnQ8L2E+LCAmbGRx dW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjYxNyI+SFRUUCBBdXRo ZW50aWNhdGlvbjogQmFzaWMgYW5kIERpZ2VzdCBBY2Nlc3MgQXV0aGVudGljYXRpb248L2E+LCZy ZHF1bzsgUkZDJm5ic3A7MjYxNywgSnVuZSZuYnNwOzE5OTkgKDxhIGhyZWY9ImZ0cDovL2Z0cC5p c2kuZWR1L2luLW5vdGVzL3JmYzI2MTcudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJodHRwOi8veG1s LnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMjYxNy5odG1sIj5IVE1MPC9hPiwgPGEg aHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMjYxNy54bWwi PlhNTDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0i dG9wIj48YSBuYW1lPSJXM0MuUkVDLWh0bWw0MC0xOTk4MDQyNCI+W1czQy5SRUMtaHRtbDQwLTE5 OTgwNDI0XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Ib3JzLCBBLiwgSmFjb2Jz LCBJLiwgYW5kIEQuIFJhZ2dldHQsICZsZHF1bzs8YSBocmVmPSJodHRwOi8vd3d3LnczLm9yZy9U Ui8xOTk4L1JFQy1odG1sNDAtMTk5ODA0MjQiPkhUTUwgNC4wIFNwZWNpZmljYXRpb248L2E+LCZy ZHF1bzsgV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSBSZWNvbW1lbmRhdGlvbiZuYnNwO1JFQy1o dG1sNDAtMTk5ODA0MjQsIEFwcmlsJm5ic3A7MTk5OCAoPGEgaHJlZj0iaHR0cDovL3d3dy53My5v cmcvVFIvMTk5OC9SRUMtaHRtbDQwLTE5OTgwNDI0Ij5IVE1MPC9hPikuPC90ZD48L3RyPgo8L3Rh YmxlPgoKPGEgbmFtZT0icmZjLnJlZmVyZW5jZXMyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPjEwLjIuJm5ic3A7SW5m b3JtYXRpdmUgUmVmZXJlbmNlczwvaDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiPgo8 dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IkktRC5uYXJ0 ZW4taWFuYS1jb25zaWRlcmF0aW9ucy1yZmMyNDM0YmlzIj5bSS1ELm5hcnRlbi1pYW5hLWNvbnNp ZGVyYXRpb25zLXJmYzI0MzRiaXNdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPk5h cnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQsICZsZHF1bzs8YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uYXJ0ZW4taWFuYS1jb25zaWRlcmF0aW9ucy1y ZmMyNDM0YmlzLTA5LnR4dCI+R3VpZGVsaW5lcyBmb3IgV3JpdGluZyBhbiBJQU5BIENvbnNpZGVy YXRpb25zIFNlY3Rpb24gaW4gUkZDczwvYT4sJnJkcXVvOyBkcmFmdC1uYXJ0ZW4taWFuYS1jb25z aWRlcmF0aW9ucy1yZmMyNDM0YmlzLTA5ICh3b3JrIGluIHByb2dyZXNzKSwgTWFyY2gmbmJzcDsy MDA4ICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1u YXJ0ZW4taWFuYS1jb25zaWRlcmF0aW9ucy1yZmMyNDM0YmlzLTA5LnR4dCI+VFhUPC9hPikuPC90 ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9 Ik9BU0lTLnNhbWwtY29yZS0yLjAtb3MiPltPQVNJUy5zYW1sLWNvcmUtMi4wLW9zXTwvYT48L3Rk Pgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86Y2FudG9yLjJAb3N1LmVk dSI+Q2FudG9yLCBTLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpKb2huLktlbXBAbm9raWEuY29tIj5L ZW1wLCBKLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpycGhpbHBvdHRAcnNhc2VjdXJpdHkuY29tIj5Q aGlscG90dCwgUi48L2E+LCBhbmQgPGEgaHJlZj0ibWFpbHRvOmV2ZS5tYWxlckBzdW4uY29tIj5F LiBNYWxlcjwvYT4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy9z ZWN1cml0eS9zYW1sL3YyLjAvc2FtbC1jb3JlLTIuMC1vcy5wZGYiPkFzc2VydGlvbnMgYW5kIFBy b3RvY29sIGZvciB0aGUgT0FTSVMgU2VjdXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZQog ICAgICAgICAgICAoU0FNTCkgVjIuMDwvYT4sJnJkcXVvOyBPQVNJUyBTdGFuZGFyZCZuYnNwO3Nh bWwtY29yZS0yLjAtb3MsIE1hcmNoJm5ic3A7MjAwNS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9 ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iT0F1dGggQ29yZSAxLjAiPltPQXV0 aCBDb3JlIDEuMF08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+SGFtbWVyLUxhaGF2 LCBFLiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhh bW1lci1vYXV0aC0wOCI+T0F1dGggQ29yZSAxLjAgUHJvdG9jb2w8L2E+LiZyZHF1bzs8L3RkPjwv dHI+CjwvdGFibGU+Cgo8YSBuYW1lPSJhbmNob3I1MyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0 aW9uLkEiPjwvYT48aDM+QXBwZW5kaXggQS4mbmJzcDsKQ2xpZW50IEFjY291bnQgYW5kIFBhc3N3 b3JkIFByb2ZpbGUgRXhhbXBsZTwvaDM+Cgo8cD5JbiB0aGlzIGV4YW1wbGUsIGNybS5leGFtcGxl LmNvbSBpcyBhbiBhcHBsaWNhdGlvbiBzZXJ2ZXIgdGhhdCBoYXMgYQogICAgICBQcm90ZWN0ZWQg UmVzb3VyY2UgYXQgaHR0cHM6Ly9jcm0uZXhhbXBsZS5jb20vZGF0YS4gRGF0YUR1bXBlciBpcyBh bgogICAgICBhcHBsaWNhdGlvbiBhY3RpbmcgYXMgYSBDbGllbnQgdGhhdCBwZXJpb2RpY2FsbHkg Y2FsbHMKICAgICAgaHR0cHM6Ly9jcm0uZXhhbXBsZS5jb20vZGF0YS4gVGhlIFByb3RlY3RlZCBS ZXNvdXJjZSB0cnVzdHMgdGhlCiAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyIGF1dGguZXhhbXBs ZS5uZXQgdG8gZGV0ZXJtaW5lIGlmIGEgQ2xpZW50IGhhcwogICAgICBhY2Nlc3MuCjwvcD4KPGEg bmFtZT0iYW5jaG9yNTQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjEiPjwvYT48aDM+ QS4xLiZuYnNwOwpQcm92aXNpb25pbmc8L2gzPgoKPHA+VGhlIEF1dGhvcml6YXRpb24gU2VydmVy IGRvY3VtZW50YXRpb24gZGVmaW5lcyB0aGUgQWNjZXNzIFRva2VuIFVSTAogICAgICAgIGFzOgo8 L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2Vt OyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CiBodHRwczovL2F1dGguZXhhbXBsZS5uZXQvYWNj ZXNzX3Rva2VuCjwvcHJlPjwvZGl2Pgo8cD5UaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaGFzIGRl ZmluZWQgdGhhdCB0aGUgcGFyYW1ldGVyIEF1ZGllbmNlIGJlCiAgICAgICAgaW5jbHVkZWQgaW4g Y2FsbHMgdG8gdGhlIEFjY2VzcyBUb2tlbiBVUkwuCjwvcD4KPHA+VGhlIENsaWVudCBoYXMgYmVl biBwcm92aXNpb25lZCB3aXRoIHRoZSBmb2xsb3dpbmc6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5 OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+ PHByZT4KIENsaWVudCBBY2NvdW50OiBkYXRhZHVtcGVyIENsaWVudCBQYXNzd29yZDogajJodzdH UHNsMAo8L3ByZT48L2Rpdj4KPHA+VGhlIFByb3RlY3RlZCBSZXNvdXJjZSBhbmQgdGhlIEF1dGhv cml6YXRpb24gU2VydmVyIGhhdmUgYWdyZWVkIHRvCiAgICAgICAgdXNlIGEgU2ltcGxlIFdlYiBU b2tlbiAoU1dUKSBmb3IgdGhlIEFjY2VzcyBUb2tlbiB3aXRoIHRoZSByZXNlcnZlZAogICAgICAg IGF0dHJpYnV0ZXMgSXNzdWVyLCBBdWRpZW5jZSwgRXhwaXJlc09uIGFuZCB0aGUgcHVibGljIGF0 dHJpYnV0ZQogICAgICAgIG5ldC5leGFtcGxlLmF1dGguYWNjb3VudCBhbmQgaGF2ZSBleGNoYW5n ZWQgdGhlIGZvbGxvd2luZyBITUFDIGtleQogICAgICAgIHZhbHVlIChleHByZXNzZWQgaW4gYmFz ZSA2NCk6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1s ZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KM2lLNVpZQW9CUXVPcVNnRi9ZcWxE dzcwSEtSbWJ5WGtybDVmNFNKNFRvYz0KPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjU1Ij48 L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNz PSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90 YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4yIj48L2E+PGgzPkEuMi4mbmJzcDsKQ2xpZW50 IFJlcXVlc3RzIEFjY2VzcyBUb2tlbjwvaDM+Cgo8cD5UaGUgQ2xpZW50IG1ha2VzIGFuIEhUVFBT IFBPU1QgdG86CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdp bi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KaHR0cHM6Ly9hdXRoLmV4YW1w bGUubmV0L2FjY2Vzc190b2tlbgo8L3ByZT48L2Rpdj4KPHA+V2l0aCB0aGUgZm9sbG93aW5nIG1l c3NhZ2UgYm9keToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFy Z2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgp3cmFwX25hbWU9ZGF0YWR1 bXBlciZhbXA7d3JhcF9wYXNzd29yZD1qMmh3N0dQc2wwJmFtcDtBdWRpZW5jZT1jcm0uZXhhbXBs ZS5jb20KPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjU2Ij48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uQS4zIj48L2E+PGgzPkEuMy4mbmJzcDsKU3VjY2Vzc2Z1bCBBY2Nlc3MgVG9rZW4g UmVzcG9uc2UgZnJvbSBBdXRob3JpemF0aW9uIFNlcnZlcjwvaDM+Cgo8cD5UaGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXIgY2hlY2tzIHRoYXQgdGhlIENsaWVudCBQYXNzd29yZCBqMmh3N0dQc2wwCiAg ICAgICAgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBDbGllbnQgTmFtZSBkYXRhZHVtcGVyIGFuZCB0 aGF0IHRoZSBDbGllbnQgaXMKICAgICAgICBhdXRob3JpemVkIHRvIGFjY2VzcyBjcm0uZXhhbXBs ZS5jb20uIFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBub3RlcwogICAgICAgIHRoZSB0aW1lIGlz IDIwMTAtMDItMDNUMDQ6MDU6MDZaLCB3aGljaCBpcyAxMjY1MTk4NzA2IHNlY29uZHMgc2luY2UK ICAgICAgICAxOTcwLTAxLTAxVDA6MDowWi4gVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHdvdWxk IGxpa2UgdGhlIEFjY2VzcwogICAgICAgIFRva2VuIHRvIGV4cGlyZSBpbiBhbiBob3VyLCBzbyAz NjAwIGlzIGFkZGVkIHRvIHRoZSBjdXJyZW50IHRpbWUuIFRoZQogICAgICAgIEF1dGhvcml6YXRp b24gU2VydmVyIHRoZW4gdXNlcyB0aGUgdmFsdWVzOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTog dGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxw cmU+Cm5ldC5leGFtcGxlLmF1dGguYWNjb3VudDoKZGF0YWR1bXBlciBFeHBpcmVzT246IDEyNjUy MDIzMDYgKDEyNjUxOTg3MDYgKyAzNjAwKQpBdWRpZW5jZTogY3JtLmV4YW1wbGUuY29tCklzc3Vl cjogYXV0aC5leGFtcGxlLm5ldAo8L3ByZT48L2Rpdj4KPHA+YW5kIHRoZSBhZ3JlZWQgSE1BQyBr ZXkgdG8gZ2VuZXJhdGUgdGhlIGZvbGxvd2luZyBTV1Q6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5 OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+ PHByZT4KbmV0LmV4YW1wbGUuYXV0aC5hY2NvdW50PWRhdGFkdW1wZXImYW1wO0V4cGlyZXNPbj0x MjY1MjAyMzA2JmFtcDtBdWRpZW5jZT1jcm0uCmV4YW1wbGUuY29tJmFtcDtJc3N1ZXI9YXV0aC5l eGFtcGxlLm5ldCZhbXA7SE1BQ1NIQTI1Nj1OOSUyRiUyRjB0U29zNzhNZTM2JTJCaQpvQkgwc0ZL ZmQ3ZUNzVVJsRUloZW9VYkNKayUzRAo8L3ByZT48L2Rpdj4KPHA+VGhlIEF1dGhvcml6YXRpb24g U2VydmVyIHRoZW4gcmVzcG9uZHMgdG8gdGhlIENsaWVudHMgSFRUUFMgcmVxdWVzdAogICAgICAg IHdpdGg6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1s ZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KSFRUUCAyMDAgT0sKPC9wcmU+PC9k aXY+CjxwPmFuZCB0aGUgQWNjZXNzIFRva2VuIGFuZCBsaWZldGltZSBvZiB0aGUgQWNjZXNzIFRv a2VuIGFzCiAgICAgICAgYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIGRhdGEgaW4g dGhlIGJvZHkgb2YgdGhlIG1lc3NhZ2UgYXMKICAgICAgICBzdWNoOgo8L3A+PGRpdiBzdHlsZT0n ZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6 IGF1dG8nPjxwcmU+CndyYXBfYWNjZXNzX3Rva2VuPW5ldC5leGFtcGxlLmF1dGguYWNjb3VudCUz RGRhdGFkdW1wZXIlMjZFeHBpcmVzT24lM0QKMTI2NTIwMjMwNiUyNkF1ZGllbmNlJTNEY3JtLmV4 YW1wbGUuY29tJTI2SXNzdWVyJTNEYXV0aC5leGFtcGxlLm5ldCUyNgpITUFDU0hBMjU2JTNETjkl MjUyRiUyNTJGMHRTb3M3OE1lMzYlMjUyQmlvQkgwc0ZLZmQ3ZUNzVVJsRUloZW9VYkNKayUyCjUz RCZhbXA7d3JhcF9hY2Nlc3NfdG9rZW5fZXhwaXJlc19pbj0zNjAwPC9wcmU+PC9kaXY+CjxhIG5h bWU9ImFuY2hvcjU3Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS40Ij48L2E+PGgzPkEu NC4mbmJzcDsKQ2xpZW50IENhbGxzIFByb3RlY3RlZCBSZXNvdXJjZTwvaDM+Cgo8cD5UaGUgQ2xp ZW50IG5vdyBoYXMgYW4gQWNjZXNzIFRva2VuIHZhbGlkIGZvciBhbiBob3VyLiBUaGUgQ2xpZW50 CiAgICAgICAgbWFrZXMgYW4gQVBJIGNhbGwgdG86CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0 YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHBy ZT4KaHR0cHM6Ly9jcm0uZXhhbXBsZS5jb20vZGF0YQo8L3ByZT48L2Rpdj4KPHA+aW5jbHVkaW5n IHRoZSBmb2xsb3dpbmcgSFRUUCBoZWFkZXI6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJs ZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4K QXV0aG9yaXphdGlvbjogV1JBUCBhY2Nlc3NfdG9rZW49Im5ldC5leGFtcGxlLmF1dGguYWNjb3Vu dD1kYXRhZHVtcGVyJmFtcDsKRXhwaXJlc09uPTEyNjUyMDIzMDYmYW1wO0F1ZGllbmNlPWNybS5l eGFtcGxlLmNvbSZhbXA7SXNzdWVyPWF1dGguZXhhbXBsZS5uZXQmYW1wOwpITUFDU0hBMjU2PU45 JTJGJTJGMHRTb3M3OE1lMzYlMkJpb0JIMHNGS2ZkN2VDc1VSbEVJaGVvVWJDSmslM0QiCjwvcHJl PjwvZGl2Pgo8cD5UaGUgUHJvdGVjdGVkIFJlc291cmNlcyB2ZXJpZmllcyB0aGUgU1dUIGFuZCBw ZXJmb3JtcyB0aGUgQ2xpZW50J3MKICAgICAgICByZXF1ZXN0IHBlciB0aGUgYXV0aG9yaXphdGlv biBhdHRyaWJ1dGVzIGluIHRoZSBTV1QuCjwvcD4KPGEgbmFtZT0iYW5jaG9yNTgiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi5CIj48L2E+PGgzPkFwcGVuZGl4IEIuJm5ic3A7CldlYiBBcHAg UHJvZmlsZSBFeGFtcGxlPC9oMz4KCjxwPkluIHRoaXMgZXhhbXBsZSwgSmFuZSwgdGhlIFVzZXIs IGxpc3RlbnMgdG8gbXVzaWMgZnJvbQogICAgICBtdXNpYy5leGFtcGxlLmNvbSBhbmQgdXBkYXRl cyBoZXIgc3RhdHVzIGF0IHN0YXR1cy5leGFtcGxlLmNvbS4gV2hlbgogICAgICBsaXN0ZW5pbmcg dG8gbXVzaWMsIEphbmUgd291bGQgbGlrZSBoZXIgc3RhdHVzIHRvIGJlIHVwZGF0ZWQgYXQgdGhl CiAgICAgIHN0YXJ0IG9mIGVhY2ggc29uZy4gRnJvbSBhbiBPQXV0aCBXUkFQIHBlcnNwZWN0aXZl LCB0aGUgQ2xpZW50IGlzCiAgICAgIG11c2ljLmV4YW1wbGUuY29tLCB0aGUgUHJvdGVjdGVkIFJl c291cmNlIGlzCiAgICAgIGh0dHBzOi8vc3RhdHVzLmV4YW1wbGUuY29tL3VwZGF0ZSwgYW5kIGF1 dGguZXhhbXBsZS5jb20gaXMgdGhlCiAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyIHRydXN0ZWQg Ynkgc3RhdHVzLmV4YW1wbGUuY29tLgo8L3A+CjxhIG5hbWU9ImFuY2hvcjU5Ij48L2E+PGJyIC8+ PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWci PjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEg bmFtZT0icmZjLnNlY3Rpb24uQi4xIj48L2E+PGgzPkIuMS4mbmJzcDsKUHJvdmlzaW9uaW5nPC9o Mz4KCjxwPlRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBkb2N1bWVudGF0aW9uIGRlZmluZXMgdGhl IGZvbGxvd2luZwogICAgICAgIFVSTHM6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KIFVz ZXIgQXV0aG9yaXphdGlvbiBVUkw6ICBodHRwczovL2F1dGguZXhhbXBsZS5jb20vdXNlcl9hdXRo b3JpemF0aW9uCiBBY2Nlc3MgVG9rZW4gVVJMOiAgICAgICAgaHR0cHM6Ly9hdXRoLmV4YW1wbGUu Y29tL2FjY2Vzc190b2tlbgogUmVmcmVzaCBUb2tlbiBVUkw6ICAgICAgIGh0dHBzOi8vYXV0aC5l eGFtcGxlLmNvbS9yZWZyZXNoX3Rva2VuCjwvcHJlPjwvZGl2Pgo8cD5UaGUgQXV0aG9yaXphdGlv biBTZXJ2ZXIgaGFzIGRlZmluZWQgdGhhdCBpZiB0aGUgQ2xpZW50IHdhbnRzCiAgICAgICAgYXV0 aG9yaXphdGlvbiB0byB1cGRhdGUgYSBVc2VyJ3Mgc3RhdHVzLCB0aGF0IHRoZSBDbGllbnQgaW5j bHVkZSB0aGUKICAgICAgICB3cmFwX3Njb3BlIHBhcmFtZXRlciB3aXRoIHRoZSB2YWx1ZSBzdGF0 dXNfdXBkYXRlIHdoZW4gcmVxdWVzdGluZwogICAgICAgIGF1dGhvcml6YXRpb24uCjwvcD4KPHA+ VGhlIENsaWVudCBoYXMgYmVlbiBwcm92aXNpb25lZCB3aXRoOgo8L3A+PGRpdiBzdHlsZT0nZGlz cGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1 dG8nPjxwcmU+CkNsaWVudCBJZGVudGlmaWVyOiBtdXNpYy5leGFtcGxlLmNvbQpDbGllbnQgU2Vj cmV0OiA3RjI5ODZERjIzNDI5MTRBCjwvcHJlPjwvZGl2Pgo8cD5UaGUgQ2xpZW50IGhhcyByZWdp c3RlcmVkIHRoZSBDYWxsYmFjayBVUkw6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KaHR0 cHM6Ly9tdXNpYy5leGFtcGxlLmNvbS9hdXRoX2NhbGxiYWNrCjwvcHJlPjwvZGl2Pgo8cD5UaGUg UHJvdGVjdGVkIFJlc291cmNlIGFuZCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaGF2ZSBhZ3Jl ZWQgdG8KICAgICAgICB1c2UgYSBTaW1wbGUgV2ViIFRva2VuIChTV1QpIGZvciB0aGUgQWNjZXNz IFRva2VuIHdpdGggdGhlIHJlc2VydmVkCiAgICAgICAgYXR0cmlidXRlcyBJc3N1ZXIsIEF1ZGll bmNlLCBFeHBpcmVzT24gYW5kIHRoZSBwdWJsaWMgYXR0cmlidXRlcwogICAgICAgIGNvbS5leGFt cGxlLmF1dGguYWNjb3VudCwgY29tLmV4YW1wbGUuYXV0aC5jbGllbnQgYW5kCiAgICAgICAgY29t LmV4YW1wbGUuYXV0aC5zY29wZS4gVGhleSBoYXZlIGV4Y2hhbmdlZCB0aGUgZm9sbG93aW5nIEhN QUMga2V5CiAgICAgICAgdmFsdWUgKGV4cHJlc3NlZCBpbiBiYXNlIDY0KToKPC9wPjxkaXYgc3R5 bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJp Z2h0OiBhdXRvJz48cHJlPgpadDlKbEwxUXZQWVJTQ0s5UGdTanJ4UlVCV2U3bGJFWXNaQ2RNK3NK Q0Y0PQo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iYW5jaG9yNjAiPjwvYT48YnIgLz48aHIgLz4KPHRh YmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFz cz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0i I3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMu c2VjdGlvbi5CLjIiPjwvYT48aDM+Qi4yLiZuYnNwOwpDbGllbnQgRGlyZWN0cyB0aGUgVXNlciB0 byB0aGUgU2VydmVyPC9oMz4KCjxwPkphbmUgaW5mb3JtcyBtdXNpYy5leGFtcGxlLmNvbSB0aGF0 IHNoZSB3b3VsZCBsaWtlIGhlciBzdGF0dXMgYXQKICAgICAgICBzdGF0dXMuZXhhbXBsZS5jb20g dG8gYmUgdXBkYXRlZCB3aGVuIGEgbmV3IHNvbmcgc3RhcnRzIHBsYXlpbmcuIFRoZQogICAgICAg IG11c2ljLmV4YW1wbGUuY29tIHdlYnNpdGUgbWFpbnRhaW5zIHVzZXIgc2Vzc2lvbnMgd2l0aCBh IFVSTCBwYXJhbWV0ZXIKICAgICAgICBuYW1lZCBzZXNzaW9uIHdoaWNoIGhhcyB0aGUgdmFsdWUg Vm4zSUcyRlJBTFNFUVgyTnhyIGF0IHRoaXMgdGltZSBmb3IKICAgICAgICBKYW5lLiBUaGUgQ2xp ZW50IHdpbGwgdXNlIHdyYXBfY2xpZW50X3N0YXRlIHRvIG1haW50YWluIHRoZSBzZXNzaW9uCiAg ICAgICAgdmFsdWUuIFRoZSBDbGllbnQgcmVkaXJlY3RzIEphbmUncyBicm93c2VyIHRvIHRoZSBB dXRob3JpemF0aW9uCiAgICAgICAgU2VydmVyJ3MgVXNlciBBdXRob3JpemF0aW9uIFVSTCBhcHBl bmRpbmcgcGFyYW1ldGVycyBmb3IgdGhlIENsaWVudAogICAgICAgIElkZW50aWZpZXIsIENhbGxi YWNrIFVSTCwgQ2xpZW50IHN0YXRlIGFuZCBhdXRob3JpemF0aW9uIHNjb3BlLgo8L3A+PGRpdiBz dHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4t cmlnaHQ6IGF1dG8nPjxwcmU+Cmh0dHBzOi8vYXV0aC5leGFtcGxlLmNvbS91c2VyX2F1dGhvcml6 YXRpb24/d3JhcF9jbGllbnRfaWQ9bXVzaWMuZXhhbXAKbGUuY29tJmFtcDt3cmFwX2NhbGxiYWNr PWh0dHAlM0ElMkYlMkZtdXNpYy5leGFtcGxlLmNvbSUyRmF1dGhfY2FsbGJhY2smYW1wO3dyCmFw X2NsaWVudF9zdGF0ZT1WbjNJRzJGUkFMU0VRWDJOeHImYW1wO3dyYXBfc2NvcGU9c3RhdHVzX3Vw ZGF0ZQo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iYW5jaG9yNjEiPjwvYT48YnIgLz48aHIgLz4KPHRh YmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFz cz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0i I3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMu c2VjdGlvbi5CLjMiPjwvYT48aDM+Qi4zLiZuYnNwOwpBdXRob3JpemF0aW9uIFNlcnZlciBDb25m aXJtcyBEZWxlZ2F0aW9uIFJlcXVlc3Qgd2l0aCBVc2VyPC9oMz4KCjxwPlRoZSBBdXRob3JpemF0 aW9uIFNlcnZlciB2ZXJpZmllcyB0aGUgc3VwcGxpZWQgQ2xpZW50IElkZW50aWZpZXIKICAgICAg ICBtdXNpYy5leGFtcGxlLmNvbSBoYXMgYmVlbiByZWdpc3RlcmVkIGFuZCBoYXMgdGhlIENhbGxi YWNrIFVSTAogICAgICAgIGh0dHBzOi8vbXVzaWMuZXhhbXBsZS5jb20vYXV0aF9jYWxsYmFjay4g VGhlIEF1dGhvcml6YXRpb24gU2VydmVyCiAgICAgICAgYXV0aGVudGljYXRlcyB0aGF0IHRoZSBV c2VyIGl0IGlzIGRlYWxpbmcgd2l0aCBpcyBKYW5lLCBhbmQgdGhlbiBhc2tzCiAgICAgICAgSmFu ZSB0byBhdXRob3JpemUgbXVzaWMuZXhhbXBsZS5jb20gdG8gdXBkYXRlIEphbmUncyBzdGF0dXMg YXQKICAgICAgICBzdGF0dXMuZXhhbXBsZS5jb20uIEphbmUgYXBwcm92ZXMgdGhlIHJlcXVlc3Qg YW5kIHRoZSBBdXRob3JpemF0aW9uCiAgICAgICAgU2VydmVyIGdlbmVyYXRlcyBhIFZlcmlmaWNh dGlvbiBDb2RlIHdpdGggdGhlIHZhbHVlIDQ2WUVYUWpWaXQ2VDNuUTgsCiAgICAgICAgc3RvcmVz IGl0IHdpdGggdGhlIENsaWVudCBJZGVudGlmaWVyLCBDYWxsYmFjayBVUmwgYW5kIHRoZSBjdXJy ZW50CiAgICAgICAgdGltZS4KPC9wPgo8YSBuYW1lPSJhbmNob3I2MiI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLkIuNCI+PC9hPjxoMz5CLjQuJm5ic3A7ClNlcnZlciBEaXJlY3RzIFVzZXIg YmFjayB0byB0aGUgQ2xpZW50PC9oMz4KCjxwPlRoZSBTZXJ2ZXIgcmVkaXJlY3RzIEphbmUgYmFj ayB0byB0aGUgQ2xpZW50J3MgQ2FsbGJhY2sgVVJMIHdpdGgKICAgICAgICB0aGUgVmVyaWZpY2F0 aW9uIENvZGUgYW5kIENsaWVudCBTdGF0ZSBhcHBlbmRlZDoKPC9wPjxkaXYgc3R5bGU9J2Rpc3Bs YXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRv Jz48cHJlPgpodHRwczovL211c2ljLmV4YW1wbGUuY29tL2F1dGhfY2FsbGJhY2s/d3JhcF92ZXJp ZmljYXRpb25fY29kZT00NllFWFFqClZpdDZUM25ROCZhbXA7d3JhcF9jbGllbnRfc3RhdGU9Vm4z SUcyRlJBTFNFUVgyTnhyCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNob3I2MyI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLkIuNSI+PC9hPjxoMz5CLjUuJm5ic3A7CkNsaWVudCBSZXF1ZXN0 cyBBY2Nlc3MgVG9rZW48L2gzPgoKPHA+VGhlIENsaWVudCBtYWtlcyBhbiBIVFRQUyBQT1NUIHJl cXVlc3QgdG86CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdp bi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KaHR0cHM6Ly9hdXRoLmV4YW1w bGUuY29tL2FjY2Vzc190b2tlbgo8L3ByZT48L2Rpdj4KPHA+V2l0aCB0aGUgZm9sbG93aW5nIG1l c3NhZ2UgYm9keToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFy Z2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgp3cmFwX2NsaWVudF9pZD1t dXNpYy5leGFtcGxlLmNvbSZhbXA7d3JhcF9jbGllbnRfc2VjcmV0PTdGMjk4NkRGMjM0MjkxNEEm YW1wO3cKcmFwX3ZlcmlmaWNhdGlvbl9jb2RlPTQ2WUVYUWpWaXQ2VDNuUTgmYW1wO3dyYXBfY2Fs bGJhY2s9aHR0cCUzQSUyRiUyRm11c2kKYy5leGFtcGxlLmNvbSUyRmF1dGhfY2FsbGJhY2sKPC9w cmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjY0Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u Qi42Ij48L2E+PGgzPkIuNi4mbmJzcDsKU3VjY2Vzc2Z1bCBBY2Nlc3MgVG9rZW4gUmVzcG9uc2Ug ZnJvbSBBdXRob3JpemF0aW9uIFNlcnZlcjwvaDM+Cgo8cD5UaGUgQXV0aG9yaXphdGlvbiBTZXJ2 ZXIgdmVyaWZpZXMgdGhhdCB0aGUgVmVyaWZpY2F0aW9uIENvZGUgaXMKICAgICAgICBzdGlsbCB2 YWxpZCwgaGFzIG5vdCBiZWVuIHVzZWQsIGFuZCBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIENsaWVu dCBJRCwKICAgICAgICBDbGllbnQgU2VjcmV0IGFuZCBDYWxsYmFjayBVUkwgUGFzc3dvcmQuIFRo ZSBBdXRob3JpemF0aW9uIFNlcnZlciB0aGVuCiAgICAgICAgZ2VuZXJhdGVzIGEgUmVmcmVzaCBU b2tlbiB3aXRoIHRoZSB2YWx1ZToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0 aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgpNZmRXVGMr djlNWGhwYytkL2NzcktGTVBmajFSeVNtNkN6SWptVEJHTjZ3PQo8L3ByZT48L2Rpdj4KPHA+VGhl IEF1dGhvcml6YXRpb24gU2VydmVyIG5vdGVzIHRoZSB0aW1lIGlzIDIwMTAtMDEtMDJUMDM6MDQ6 MDVaLAogICAgICAgIHdoaWNoIGlzIDEyNjI0MzAyNDUgc2Vjb25kcyBzaW5jZSAxOTcwLTAxLTAx VDA6MDowWi4gVGhlIEF1dGhvcml6YXRpb24KICAgICAgICBTZXJ2ZXIgdGhlbiB1c2VzIHRoZSB2 YWx1ZXM6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1s ZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KY29tLmV4YW1wbGUuYXV0aC5zY29w ZTogc3RhdHVzX3VwZGF0ZWEKY29tLmV4YW1wbGUuYXV0aC5hY2NvdW50OiBKYW5lCmNvbS5leGFt cGxlLmF1dGguY2xpZW50OiBtdXNpYy5leGFtcGxlLmNvbQpFeHBpcmVzT246IDEyNjI0MzM4NDUg KDEyNjI0MzAyNDUgKyAzNjAwIHNlY29uZHMgbGF0ZXIpCkF1ZGllbmNlOiBzdGF0dXMuZXhhbXBs ZS5jb20KSXNzdWVyOiBhdXRoLmV4YW1wbGUuY29tCjwvcHJlPjwvZGl2Pgo8cD5hbmQgdGhlIGFn cmVlZCBITUFDIGtleSB0byBnZW5lcmF0ZSB0aGUgZm9sbG93aW5nIFNXVDoKPC9wPjxkaXYgc3R5 bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJp Z2h0OiBhdXRvJz48cHJlPgpjb20uZXhhbXBsZS5hdXRoLnNjb3BlPXN0YXR1c191cGRhdGUmYW1w O2NvbS5leGFtcGxlLmF1dGguYWNjb3VudD1KYW5lJmFtcDtjb20KLmV4YW1wbGUuYXV0aC5jbGll bnQ9bXVzaWMuZXhhbXBsZS5jb20mYW1wO0V4cGlyZXNPbj0xMjYyNDMzODQ1JmFtcDtBdWRpZW5j ZT1zCnRhdHVzLmV4YW1wbGUuY29tJmFtcDtJc3N1ZXI9YXV0aC5leGFtcGxlLmNvbSZhbXA7SE1B Q1NIQTI1Nj0zeFpBWXpKUnRZQ1Fna0FGMwppcUVscDFEaHlLa1BocTk0N2owNE5jRG9jUSUzRAo8 L3ByZT48L2Rpdj4KPHA+VGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRoZW4gcmVzcG9uZHMgdG8g dGhlIENsaWVudHMgSFRUUFMgcmVxdWVzdAogICAgICAgIHdpdGg6CjwvcD48ZGl2IHN0eWxlPSdk aXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDog YXV0byc+PHByZT4KSFRUUCAyMDAgT0sKPC9wcmU+PC9kaXY+CjxwPmFuZCB0aGUgUmVmcmVzaCBU b2tlbiwgQWNjZXNzIFRva2VuIGFuZCBsaWZldGltZSBvZiB0aGUgQWNjZXNzCiAgICAgICAgVG9r ZW4gYXMgYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIGRhdGEgaW4gdGhlIGJvZHkg b2YgdGhlCiAgICAgICAgbWVzc2FnZSBhcyBzdWNoOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTog dGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxw cmU+CndyYXBfcmVmcmVzaF90b2tlbj1NZmRXVGMlMkJ2OU1YaHBjJTJCZCUyRmNzcktGTVBmajFS eVNtNkN6SWptVEJHTjZ3JTMKRCZhbXA7d3JhcF9hY2Nlc3NfdG9rZW49Y29tLmV4YW1wbGUuYXV0 aC5zY29wZSUzRHN0YXR1c191cGRhdGUlMjZjb20uZXhhbXAKbGUuYXV0aC5hY2NvdW50JTNESmFu ZSUyNmNvbS5leGFtcGxlLmF1dGguY2xpZW50JTNEbXVzaWMuZXhhbXBsZS5jb20lMgo2RXhwaXJl c09uJTNEMTI2MjQzMzg0NSUyNkF1ZGllbmNlJTNEc3RhdHVzLmV4YW1wbGUuY29tJTI2SXNzdWVy JTNEYXV0CmguZXhhbXBsZS5jb20lMjZITUFDU0hBMjU2JTNEM3haQVl6SlJ0WUNRZ2tBRjNpcUVs cDFEaHlLa1BocTk0N2owNE5jRG8KY1ElMjUzRCZhbXA7d3JhcF9hY2Nlc3NfdG9rZW5fZXhwaXJl c19pbj0zNjAwCjwvcHJlPjwvZGl2Pgo8cD5UaGUgQ2xpZW50IG5vdyBoYXMgYSBSZWZyZXNoIFRv a2VuIGFuZCBBY2Nlc3MgVG9rZW4gdmFsaWQgZm9yIGFuCiAgICAgICAgaG91ci4gVGhlIENsaWVu dCBzdG9yZXMgdGhlIFJlZnJlc2ggVG9rZW4gZm9yIGxhdGVyIHVzZS4KPC9wPgo8YSBuYW1lPSJh bmNob3I2NSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkIuNyI+PC9hPjxoMz5CLjcuJm5i c3A7CkNsaWVudCBDYWxscyBQcm90ZWN0ZWQgUmVzb3VyY2U8L2gzPgoKPHA+QSBmZXcgbWludXRl cyBsYXRlciwgbXVzaWMuZXhhbXBsZS5jb20gc3RhcnRzIHBsYXlpbmcgYSBuZXcgc29uZwogICAg ICAgIGZvciBKYW5lLiBUaGUgQ2xpZW50IHVwZGF0ZXMgSmFuZSdzIHN0YXR1cyBhdCBzdGF0dXMu ZXhhbXBsZS5jb20gYnkKICAgICAgICBtYWtpbmcgYW4gQVBJIGNhbGwgdG86CjwvcD48ZGl2IHN0 eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1y aWdodDogYXV0byc+PHByZT4KaHR0cHM6Ly9zdGF0dXMuZXhhbXBsZS5jb20vdXBkYXRlCjwvcHJl PjwvZGl2Pgo8cD5pbmNsdWRpbmcgdGhlIGZvbGxvd2luZyBIVFRQIGhlYWRlcjoKPC9wPjxkaXYg c3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2lu LXJpZ2h0OiBhdXRvJz48cHJlPgpBdXRob3JpemF0aW9uOiBXUkFQIGFjY2Vzc190b2tlbj0iY29t LmV4YW1wbGUuYXV0aC5zY29wZT1zdGF0dXNfdXBkYXRlCiZhbXA7Y29tLmV4YW1wbGUuYXV0aC5h Y2NvdW50PUphbmUmYW1wO2NvbS5leGFtcGxlLmF1dGguY2xpZW50PW11c2ljLmV4YW1wbGUuYwpv bSZhbXA7RXhwaXJlc09uPTEyNjI0MzM4NDUmYW1wO0F1ZGllbmNlPXN0YXR1cy5leGFtcGxlLmNv bSZhbXA7SXNzdWVyPWF1dGguZXhhbXBsCmUuY29tJmFtcDtITUFDU0hBMjU2PTN4WkFZekpSdFlD UWdrQUYzaXFFbHAxRGh5S2tQaHE5NDdqMDROY0RvY1ElM0QiCjwvcHJlPjwvZGl2Pgo8cD5UaGUg UHJvdGVjdGVkIFJlc291cmNlcyB2ZXJpZmllcyB0aGUgU1dULCBjb25maXJtcyB0aGUKICAgICAg ICBhdXRob3JpemF0aW9uIGNvbnRhaW5lZCBpbiB0aGUgU1dULCBhbmQgdXBkYXRlcyBKYW5lJ3Mg c3RhdHVzLgo8L3A+CjxhIG5hbWU9ImFuY2hvcjY2Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uQi44Ij48L2E+PGgzPkIuOC4mbmJzcDsKQ2xpZW50IFJlZnJlc2hlcyBBY2Nlc3MgVG9rZW48 L2gzPgoKPHA+QW4gaG91ciBwYXNzZXMgYnkgYW5kIG11c2ljLmV4YW1wbGUuY29tIHN0YXJ0cyBw bGF5aW5nIGFub3RoZXIgbmV3CiAgICAgICAgc29uZyBmb3IgSmFuZS4gVGhlIENsaWVudCBhZ2Fp biBtYWtlcyBhbiBBUEkgY2FsbCB0bwogICAgICAgIHN0YXR1cy5leGFtcGxlLmNvbSBpbmNsdWRp bmcgdGhlIHNhbWUgSFRUUCBBdXRob3JpemF0aW9uIGhlYWRlci4KICAgICAgICBVbmxpa2UgcHJl dmlvdXMgY2FsbHMgd2hlcmUgdGhlIHN0YXR1cyB1cGRhdGUgd2FzIHBlcmZvcm1lZCwgdGhlCiAg ICAgICAgUHJvdGVjdGVkIFJlc291cmNlIHJldHVybnMgdGhlIGZvbGxvd2luZyBlcnJvciByZXNw b25zZToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxl ZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgpIVFRQIDQwMSBVbmF1dGhvcml6ZWQK PC9wcmU+PC9kaXY+CjxwPmFuZCB0aGUgSFRUUCBoZWFkZXI6CjwvcD48ZGl2IHN0eWxlPSdkaXNw bGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0 byc+PHByZT4KV1dXLUF1dGhlbnRpY2F0ZTogV1JBUAo8L3ByZT48L2Rpdj4KPHA+VGhlIENsaWVu dCBkZXRlcm1pbmVzIGl0IHByb2JhYmx5IG5lZWRzIGEgbmV3IEFjY2VzcyBUb2tlbiwKICAgICAg ICByZXRyaWV2ZXMgdGhlIFJlZnJlc2ggVG9rZW4gYW5kIG1ha2VzIGFuIEhUVFBTIFBPU1QgdG86 CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAz ZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KaHR0cHM6Ly9hdXRoLmV4YW1wbGUuY29tL3Jl ZnJlc2hfdG9rZW4KPC9wcmU+PC9kaXY+CjxwPmluY2x1ZGluZyB0aGUgQ2xpZW50IElkZW50aWZp ZXIsIENsaWVudCBTZWNyZXQgYW5kIFJlZnJlc2ggVG9rZW4gaW4KICAgICAgICB0aGUgbWVzc2Fn ZSBib2R5IGFzOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJn aW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CndyYXBfY2xpZW50X2lkPW11 c2ljLmV4YW1wbGUuY29tJmFtcDt3cmFwX2NsaWVudF9zZWNyZXQ9N0YyOTg2REYyMzQyOTE0QSZh bXA7dwpyYXBfcmVmcmVzaF90b2tlbj1NZmRXVGMlMkJ2OU1YaHBjJTJCZCUyRmNzcktGTVBmajFS eVNtNkN6SWptVEJHTjZ3JTNECjwvcHJlPjwvZGl2Pgo8cD5UaGUgQXV0aG9yaXphdGlvbiBTZXJ2 ZXIgbG9va3MgdXAgdGhlIGRhdGEgYXNzb2NpYXRlZCB3aXRoIHRoZQogICAgICAgIFJlZnJlc2gg VG9rZW4sIGRldGVybWluZXMgbXVzaWMuZXhhbXBsZS5jb20gaXMgc3RpbGwgYXV0aG9yaXplZCB0 bwogICAgICAgIHVwZGF0ZSBKYW5lJ3Mgc3RhdHVzLCBhbmQgZGV0ZXJtaW5lcyBpdCB3aWxsIGdl bmVyYXRlIGEgbmV3IEFjY2VzcwogICAgICAgIFRva2VuIGZvciB0aGUgQ2xpZW50IHRoYXQgZXhw aXJlcyBpbiBhbiBob3VyLiBUaGUgdGltZSBpcyBub3cKICAgICAgICAyMDEwLTAxLTAyVDA0OjE1 OjIzWiwgd2hpY2ggcmVzdWx0cyBpbiBhbiBBY2Nlc3MgVG9rZW4gZXhwaXJ5IHRpbWUgb2YKICAg ICAgICAxMjYyNDM4MTIzIHNlY29uZHMgc2luY2UgMTk3MC0wMS0wMVQwOjA6MFouIFRoZSBBdXRo b3JpemF0aW9uIFNlcnZlcgogICAgICAgIGdlbmVyYXRlcyBhIG5ldyBBY2Nlc3MgVG9rZW4gYW5k IHJldHVybnMgaXQgaW4gdGhlIGJvZHkgb2YgdGhlIG1lc3NhZ2UKICAgICAgICBhczoKPC9wPjxk aXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFy Z2luLXJpZ2h0OiBhdXRvJz48cHJlPgp3cmFwX2FjY2Vzc190b2tlbj1jb20uZXhhbXBsZS5hdXRo LnNjb3BlPXN0YXR1c191cGRhdGUmYW1wO2NvbS5leGFtcGxlLmF1dApoLmFjY291bnQ9SmFuZSZh bXA7Y29tLmV4YW1wbGUuYXV0aC5jbGllbnQ9bXVzaWMuZXhhbXBsZS5jb20mYW1wO0V4cGlyZXNP bj0xMjYKMjQzODEyMyZhbXA7QXVkaWVuY2U9c3RhdHVzLmV4YW1wbGUuY29tJmFtcDtJc3N1ZXI9 YXV0aC5leGFtcGxlLmNvbSZhbXA7SE1BQ1NIQTI1Ngo9QVQ0VEZDaEhneXlsSXRFV0FqSzdNRlJK dXZVUzNXTFZ6TyUyRjY4Z3ZJUlFJJTNEJmFtcDt3cmFwX2FjY2Vzc190b2tlbl9leApwaXJlc19p bj0zNjAwCjwvcHJlPjwvZGl2Pgo8cD5UaGUgQ2xpZW50IHRha2VzIHRoZSBuZXcgQWNjZXNzIFRv a2VuIGFuZCB1c2VzIGl0IHRvIHN1Y2Nlc3NmdWxseQogICAgICAgIHVwZGF0ZSBKYW5lJ3Mgc3Rh dHVzIGF0IHN0YXR1cy5leGFtcGxlLmNvbS4KPC9wPgo8YSBuYW1lPSJyZmMuYXV0aG9ycyI+PC9h PjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2Vs bHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0i VE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFi bGU+CjxoMz5BdXRob3JzJyBBZGRyZXNzZXM8L2gzPgo8dGFibGUgd2lkdGg9Ijk5JSIgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPgo8dHI+PHRkIGNsYXNzPSJhdXRo b3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+RGljayBIYXJkdCAo ZWRpdG9yKTwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+ Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPk1pY3Jvc29mdDwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFz cz0iYXV0aG9yIiBhbGlnbj0icmlnaHQiPkVtYWlsOiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0 aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+ZGljay5oYXJk dEBnbWFpbC5jb208L2E+PC90ZD48L3RyPgo8dHIgY2VsbHBhZGRpbmc9IjMiPjx0ZD4mbmJzcDs8 L3RkPjx0ZD4mbmJzcDs8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJz cDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5BbGxlbiBUb208L3RkPjwvdHI+Cjx0cj48 dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0 Ij5ZYWhvbyE8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvciIgYWxpZ249InJpZ2h0Ij5F bWFpbDombmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86 YXRvbUB5YWhvby1pbmMuY29tIj5hdG9tQHlhaG9vLWluYy5jb208L2E+PC90ZD48L3RyPgo8dHIg Y2VsbHBhZGRpbmc9IjMiPjx0ZD4mbmJzcDs8L3RkPjx0ZD4mbmJzcDs8L3RkPjwvdHI+Cjx0cj48 dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0 Ij5CcmlhbiBFYXRvbjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNw OzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkdvb2dsZTwvdGQ+PC90cj4KPHRyPjx0ZCBj bGFzcz0iYXV0aG9yIiBhbGlnbj0icmlnaHQiPkVtYWlsOiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0i YXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpiZWF0b25AZ29vZ2xlLmNvbSI+YmVhdG9uQGdv b2dsZS5jb208L2E+PC90ZD48L3RyPgo8dHIgY2VsbHBhZGRpbmc9IjMiPjx0ZD4mbmJzcDs8L3Rk Pjx0ZD4mbmJzcDs8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8 L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5ZYXJvbiBHb2xhbmQ8L3RkPjwvdHI+Cjx0cj48 dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0 Ij5NaWNyb3NvZnQ8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvciIgYWxpZ249InJpZ2h0 Ij5FbWFpbDombmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWls dG86eWFyb25nQG1pY3Jvc29mdC5jb20iPnlhcm9uZ0BtaWNyb3NvZnQuY29tPC9hPjwvdGQ+PC90 cj4KPC90YWJsZT4KPC9ib2R5PjwvaHRtbD4KCg== --000e0cd11250c06a6104839980f5-- From uidude@google.com Tue Apr 6 17:25:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C6A3A62C1 for ; Tue, 6 Apr 2010 17:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.511 X-Spam-Level: X-Spam-Status: No, score=-105.511 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6BMX10vZvgB for ; Tue, 6 Apr 2010 17:25:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3F6AB3A672F for ; Tue, 6 Apr 2010 17:25:15 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [10.3.21.3]) by smtp-out.google.com with ESMTP id o370PAJA022648 for ; Tue, 6 Apr 2010 17:25:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270599910; bh=XkypenS4FMoDBUN5tmIrdt7puyU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=KrxzDUcxiIdVKbP6XIhg+c4BC+CorjUJ92ZsCwmAtIJdcCqUQPjh8aD+DO1v6GW1G +imPq4jjD9qTPVqprLyjw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=cvEDUzZ0vXXzHjVugilKIYjPrJ1kYEfhPShI+eKDB1KXBYQu65FNXn3BipS/gEEHU 6iNOYxcCHzvBFKcg/ckqg== Received: from qyk5 (qyk5.prod.google.com [10.241.83.133]) by hpaq3.eem.corp.google.com with ESMTP id o370OsjT027757 for ; Wed, 7 Apr 2010 02:25:09 +0200 Received: by qyk5 with SMTP id 5so587152qyk.3 for ; Tue, 06 Apr 2010 17:25:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.194 with HTTP; Tue, 6 Apr 2010 17:24:48 -0700 (PDT) In-Reply-To: References: From: Evan Gilbert Date: Tue, 6 Apr 2010 17:24:48 -0700 Received: by 10.229.230.4 with SMTP id jk4mr2842227qcb.1.1270599908504; Tue, 06 Apr 2010 17:25:08 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016364ec7a832bff204839a985d X-System-Of-Record: true Cc: Eran Hammer-Lahav , OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 00:25:19 -0000 --0016364ec7a832bff204839a985d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 6, 2010 at 2:44 PM, Eran Hammer-Lahav wrote: > > > > On 4/6/10 7:04 AM, "Evan Gilbert" wrote: > > > > > > > On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav > > wrote: > >> Hi Evan, > >> > >> On 4/5/10 4:28 PM, "Evan Gilbert" wrote: > >> > >>> 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > >>> We should have an OPTIONAL username parameter: > >>> username > >>> The resource owner's username. The authorization server MUST only > send > >>> back > >>> refresh tokens or access tokens for this user. > >>> > >>> This is useful for clients where a user is already logged into a 3rd > party > >>> web > >>> site with a specific account, and the client wants the authorization to > >>> match > >>> the specific user. > >> > >> I think introducing the concept of user identity is more complex than > just a > >> username parameter. I agree that it can be useful but we need a more > >> detailed discussion about this before we add it. > > > > I agree issues around user identity are complex. > > > > Would it help to spin up a separate discussion thread on this one issue? > > That's one way. A more developed proposal is another. > Hah, ok :) Can you give more feedback about what kind of information would help clarify? Te exact meaning of the username needs to be tied to some identity system (similiar to the username + password profile), and I wasn't sure how to expand upon it. Proposal: In 2.4.1 & 2.4.2, add the following OPTIONAL parameter username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username. > EHL > > --0016364ec7a832bff204839a985d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 6, 2010 at 2:44 PM, Eran Ham= mer-Lahav <eran@hueniverse.com> wrote:



On 4/6/10 7:04 AM, "Evan Gilbert" <uidude@google.com> wrote:

>
>
> On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>> Hi Evan,
>>
>> On 4/5/10 4:28 PM, "Evan Gilbert" <uidude@google.com> wrote:
>>
>>> 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
>>> We should have an OPTIONAL username parameter:
>>> username
>>> =A0=A0The resource owner's username. The authorization ser= ver MUST only send
>>> back
>>> refresh tokens or access tokens for this user.
>>>
>>> This is useful for clients where a user is already logged into= a 3rd party
>>> web
>>> site with a specific account, and the client wants the authori= zation to
>>> match
>>> the specific user.
>>
>> I think introducing the concept of user identity is more complex t= han just a
>> username parameter. I agree that it can be useful but we need a mo= re
>> detailed discussion about this before we add it.
>
> I agree issues around user identity are complex.
>
> Would it help to spin up a separate discussion thread on this one issu= e?

That's one way. A more developed proposal is another.

Hah, ok :)

Can you give more feedbac= k about what kind of information would help clarify? Te exact meaning of th= e username needs to be tied to some identity system (similiar to the userna= me + password profile), and I wasn't sure how to expand upon it.

Proposal:
In 2.4.1 & 2.4.2, add the follo= wing OPTIONAL parameter
<= span style=3D"border-collapse:separate;font-family:arial">username
=A0=A0The resource owner's username. The authorization server MUS= T only send back refresh tokens or access tokens for the user identified by= username.
=


<= /span>

EHL


--0016364ec7a832bff204839a985d-- From igor.faynberg@alcatel-lucent.com Tue Apr 6 21:16:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DF43A6A63 for ; Tue, 6 Apr 2010 21:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWJtEtlaiWrC for ; Tue, 6 Apr 2010 21:16:47 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id CD4803A6A29 for ; Tue, 6 Apr 2010 21:16:46 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o374Gdbo005873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 23:16:39 -0500 (CDT) Received: from [135.244.33.38] (faynberg.lra.lucent.com [135.244.33.38]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o374Gc0e028903; Tue, 6 Apr 2010 23:16:38 -0500 (CDT) Message-ID: <4BBC0727.1080702@alcatel-lucent.com> Date: Wed, 07 Apr 2010 00:16:39 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 04:16:48 -0000 Yes, if we go with RFC 2617, then--and please correct me if I am wrong--it looks to me that *realm* here means pretty much the same thing as *Kerberos realm*. I strongly agree on getting the definition clear, and I agree that nothing should be "opaque." (I as puzzled by the quoted exchange, and I decided that I am simply ignorant about the terminology and should wait until it is clarified. In this group there is a good mix of people with different backgrounds, and so sorting out the terminology seems to be the most important thing to accomplish.) Igor Eran Hammer-Lahav wrote: > RFC 2617 defines what a realm is - a set of resources sharing the same set > of credentials. It saves the client the need to prompt the user again for > their credentials when browsing a site across resources. Because sending > credentials to the wrong place is dangerous, realms are hard to use because > the client must take into account more than just the same realm but also the > domain name, etc. > > Most of the example people gave for their use of scope where in practice a > segment ('photos', 'contacts', etc.). Usually each of these groups use > different APIs (a single API call that can bring both a photo and contact, > but only a photo if using a limited token without contact access, is rare). > > This is why I suggested using realm as a well defined subset of what people > here refer to as 'scope'. > > I don't like the idea of defining a parameter that requires internal > structure as opaque and leaving it up to the individual services to define. > This doesn't help interop. If you have to define the structure of the scope > parameter, you might as well define the parameter as well. > > The argument that having a consistent parameter with an opaque value help > libraries is silly. Good libraries will pass along any custom parameters > they found to the higher level. This adds nothing but is likely to cause > problems when people code libraries with scope structure specific to one > company. It will also cause confusion when two scopes mean completely > different things across services. > > > EHL > > > On 4/6/10 8:03 AM, "Dick Hardt" wrote: > > >> On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote: >> >> >>> >>> On 4/2/10 3:27 PM, "Dick Hardt" wrote: >>> >>> >>>> There are times when a resource may have different scope for different kinds >>>> of access. realm != scope >>>> >>> No. Realm is a subset. It is what people define as the protected segment >>> name. >>> >> Different Protected Resources could require the same scope, so I see realm >> and scope as being orthogonal. >> >> >>> For any other scope attribute we need to first define it. >>> >> Why? Scope will often be application specific. >> >> >> > > From igor.faynberg@alcatel-lucent.com Tue Apr 6 21:31:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279103A67EC for ; Tue, 6 Apr 2010 21:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s09KEbxJkz9 for ; Tue, 6 Apr 2010 21:31:57 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 018AB3A6A6D for ; Tue, 6 Apr 2010 21:31:55 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o374Vaet011796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 23:31:36 -0500 (CDT) Received: from [135.244.33.38] (faynberg.lra.lucent.com [135.244.33.38]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o374VZUP004525; Tue, 6 Apr 2010 23:31:35 -0500 (CDT) Message-ID: <4BBC0AA8.2010708@alcatel-lucent.com> Date: Wed, 07 Apr 2010 00:31:36 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Marius Scurtescu References: <27B54FC8-6C50-4283-89AF-6EB44A6FD006@facebook.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: OAuth WG Subject: [OAUTH-WG] More on definitions (was Re: Scope using Realm idea) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 04:31:58 -0000 I've been reading this with much interest, but I am getting hopelessly lost because of the usage of the word API. Somehow, to me -- for many years--it meant the format of procedure calls, or, more general, procedure signatures in standard libraries. I remember David at the last meeting clarified to me that by "API" he meant HTTP headers. I don't mind broadening the term, but do we have a definition for it? Igor Marius Scurtescu wrote: > On Tue, Apr 6, 2010 at 2:42 PM, Eran Hammer-Lahav wrote: > >> The question is how your APIs are structure. Do you have APIs that require >> multiple “scopes” in a single call? >> > > Things can get even more complicated. When the user grants access for > the client, the approval page should list all the scopes the client is > requesting. This is the set of scopes needed by the client for *all* > the API calls. Each API will need a subset of this approved, larger > set. > > With that in mind, it would be useful to be able to down-scope access > tokens when using the refresh token, this way the client can send the > smallest set of scopes with each API call. > > But again, for all the above, the client must have intimate knowledge > of the APIs (aka protected resources) and what scopes are required, > the OAuth 2.0 libraries used by the client can treat the scopes as > opaque strings IMO. > > Marius > > >> EHL >> >> >> On 4/6/10 8:29 AM, "Luke Shepard" wrote: >> >> For Facebook at least, we are currently planning to use scope as a >> comma-separated list of permissions from this set: >> http://wiki.developers.facebook.com/index.php/Extended_permissions >> >> For instance: >> >> oauth_scope=read_stream,email,photo_upload >> >> I'm not sure if that maps to realm exactly. >> >> On Apr 6, 2010, at 8:03 AM, Dick Hardt wrote: >> >> >>> On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote: >>> >>> >>>> >>>> On 4/2/10 3:27 PM, "Dick Hardt" wrote: >>>> >>>> >>>>> There are times when a resource may have different scope for different >>>>> kinds >>>>> of access. realm != scope >>>>> >>>> No. Realm is a subset. It is what people define as the protected segment >>>> name. >>>> >>> Different Protected Resources could require the same scope, so I see realm >>> and scope as being orthogonal. >>> >>> >>>> For any other scope attribute we need to first define it. >>>> >>> Why? Scope will often be application specific. >>> >>> _______________________________________________ >>> OAuth mailing 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 beaton@google.com Tue Apr 6 22:13:55 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74EAF3A6A7A for ; Tue, 6 Apr 2010 22:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88dhPBCIT8jl for ; Tue, 6 Apr 2010 22:13:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 48EED3A6A6C for ; Tue, 6 Apr 2010 22:13:49 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o375DjJf025759 for ; Tue, 6 Apr 2010 22:13:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270617225; bh=8jMiIVnUmBcKUo0iQIDwB0X+1kQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=npQ+xtGStOfZMUV+eHvmbmz6S5YlVy1Jeg6yhG6UurmoDO1YesopkSpqiO7rt8u68 bHvT8+gwuQk1h2fPB0ogQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=L1dd8tB4rF2U6gKRLxvk8QySbgz/XkOcjNcHV33VJd6wxOdOBejYQOnOJmkFfJJmF m1LUNfOAq1QYNqL9x3Y7w== Received: from vws5 (vws5.prod.google.com [10.241.21.133]) by kpbe18.cbf.corp.google.com with ESMTP id o375Dg2V028366 for ; Tue, 6 Apr 2010 22:13:44 -0700 Received: by vws5 with SMTP id 5so59987vws.8 for ; Tue, 06 Apr 2010 22:13:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.2 with HTTP; Tue, 6 Apr 2010 22:13:41 -0700 (PDT) In-Reply-To: <2EB1540C-6B2C-4053-8153-545E80A90968@gmail.com> References: <2EB1540C-6B2C-4053-8153-545E80A90968@gmail.com> Date: Tue, 6 Apr 2010 22:13:41 -0700 Received: by 10.220.121.145 with SMTP id h17mr4137725vcr.174.1270617221482; Tue, 06 Apr 2010 22:13:41 -0700 (PDT) Message-ID: From: Brian Eaton To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Eran Hammer-Lahav , OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 05:13:55 -0000 On Tue, Apr 6, 2010 at 11:15 AM, David Recordon wrote: > There is potential for leakage if the client then redirects the user to > another SSL URL. This doesn't feel like a common pattern and the client > would generally be redirecting to a page which they control after receiving > the access token. > From 15.1.3 of RFC 2616: > Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP > request if the referring page was transferred with a secure protocol. There are several ways tokens passed on URLs tend to leak. I think I listed them all in the security considerations. [1] If the callback URL points to a page that links to third-party content, the third-party content will get a copy of the URL, including the access token, via the referer header. Search for 'referer' in the browsersec wiki [2] for the gory details. If the callback URL is an open redirector, it might be tricked into sending the access token to an untrusted third-party. If the web server logs requests, the access token will end up in the web server logs. Passing the token on the fragment mitigates all of those risks. Callback URL whitelisting is also important. Time-limited access tokens are a final layer of defense. There are some intrinsic risks here - I'd like to make sure that we treat lightweight javascript clients (no secrets, transient data access, authenticated only by callback URL) different than full-fledged web servers (can keep secrets, permanent data access.) Note that it's pretty easy for a web server to pass an access token down into a javascript widget. So I think there's a clear upgrade path from the one mode to the other. Cheers, Brian [1] http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations [2] http://code.google.com/p/browsersec/wiki/Part1#Hypertext_Transfer_Protocol From beaton@google.com Tue Apr 6 22:33:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB6B3A6877 for ; Tue, 6 Apr 2010 22:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obCiSwJ7l8bQ for ; Tue, 6 Apr 2010 22:33:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C9E983A67EB for ; Tue, 6 Apr 2010 22:33:40 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [10.3.21.6]) by smtp-out.google.com with ESMTP id o375XY9P011572 for ; Wed, 7 Apr 2010 07:33:34 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270618414; bh=jOc0n8KAAlXe29jpYkQYbokzaTI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=W4nKYcoTDMilbiPqZpFP9hIrhB1q0b78kkFuHOGjR+lQ/UH6m1ogcsXD+HcxUXC98 YzEPECj5/HANJ9/NzOrig== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=VKEt9JZcDhPhbFuymEbqpPf+ma5eS/Ik4bF3nqG1Mg6oOWLk/ydxiwnFl9hxnEk1i v9NGa2/Pp1TeChmikjSMA== Received: from vws19 (vws19.prod.google.com [10.241.21.147]) by hpaq6.eem.corp.google.com with ESMTP id o375XXJu017858 for ; Wed, 7 Apr 2010 07:33:33 +0200 Received: by vws19 with SMTP id 19so348123vws.29 for ; Tue, 06 Apr 2010 22:33:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.2 with HTTP; Tue, 6 Apr 2010 22:33:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Apr 2010 22:33:32 -0700 Received: by 10.220.107.137 with SMTP id b9mr4061834vcp.227.1270618412663; Tue, 06 Apr 2010 22:33:32 -0700 (PDT) Message-ID: From: Brian Eaton To: Luke Shepard Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Renaming expires to expires_in? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 05:33:48 -0000 On Tue, Apr 6, 2010 at 8:24 AM, Luke Shepard wrote: > Just curious, where did "duration" come from? > I hate to be picky, but I feel like "expires_in" is more clear than > "duration" ... if only because other protocols (OAuth 1.0a, OpenID, Facebook > auth) use "expires". "duration" is pretty vague. "expires" or "expires_in" are both fine by me. From eran@hueniverse.com Tue Apr 6 23:07:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59003A6807 for ; Tue, 6 Apr 2010 23:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjjEZgd81Xdg for ; Tue, 6 Apr 2010 23:07:31 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A6B6B3A67E3 for ; Tue, 6 Apr 2010 23:07:31 -0700 (PDT) Received: (qmail 14019 invoked from network); 7 Apr 2010 06:07:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Apr 2010 06:07:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Apr 2010 23:07:27 -0700 From: Eran Hammer-Lahav To: Evan Gilbert Date: Tue, 6 Apr 2010 23:07:24 -0700 Thread-Topic: [OAUTH-WG] Comments on Web Callback & Client Flow Thread-Index: AcrV6MqcWg8mVxnvTTSH/GdUTcfIMwAL8y5M Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 06:07:33 -0000 On 4/6/10 5:24 PM, "Evan Gilbert" wrote: > Proposal: > In 2.4.1 & 2.4.2, add the following OPTIONAL parameter > username > =A0=A0The resource owner's username. The authorization server MUST only s= end back > refresh tokens or access tokens for the user identified by username. What are the security implications? How can the client know that the token it got is really for that user? EHL From uidude@google.com Tue Apr 6 23:15:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6313A6767 for ; Tue, 6 Apr 2010 23:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.326 X-Spam-Level: X-Spam-Status: No, score=-101.326 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nYeOjiGNWU8 for ; Tue, 6 Apr 2010 23:15:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 080983A66B4 for ; Tue, 6 Apr 2010 23:15:12 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o376F66e011557 for ; Wed, 7 Apr 2010 08:15:07 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270620907; bh=zot9jaFpIaROGOESVN06xwTIhq0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=M5d/BpRq0wq+mE+d1B/tk3eScaJ2y56LAvIaZ2dL0BHges1fr7DHhFvc1vCOyBr7j YFvjuQglffyiFnuyFjusQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=d4sFhyov/bTuYjnoyc2KBiCUrpRGERpZEb9mPFbnWtwY5xgjtqeUKiIhDnmM0VFWx jntweM+ZKrJQ1/pmcWohg== Received: from qyk26 (qyk26.prod.google.com [10.241.83.154]) by wpaz33.hot.corp.google.com with ESMTP id o376F4ef016038 for ; Tue, 6 Apr 2010 23:15:06 -0700 Received: by qyk26 with SMTP id 26so760066qyk.19 for ; Tue, 06 Apr 2010 23:15:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.194 with HTTP; Tue, 6 Apr 2010 23:14:43 -0700 (PDT) In-Reply-To: References: From: Evan Gilbert Date: Tue, 6 Apr 2010 23:14:43 -0700 Received: by 10.229.242.3 with SMTP id lg3mr878260qcb.102.1270620904695; Tue, 06 Apr 2010 23:15:04 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001485eba704ab29f404839f7bf4 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 06:15:14 -0000 --001485eba704ab29f404839f7bf4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav wrote: > > > > On 4/6/10 5:24 PM, "Evan Gilbert" wrote: > > > Proposal: > > In 2.4.1 & 2.4.2, add the following OPTIONAL parameter > > username > > The resource owner's username. The authorization server MUST only send > back > > refresh tokens or access tokens for the user identified by username. > > What are the security implications? How can the client know that the token > it got is really for that user? > Think the client has to trust the auth server, in the same way as with the username + password profile. The auth server can always send back a scope for a different user. Worst case is that there is an identity mismatch between client and the identity implicit in the authorization token. This mismatch is already possible, and I don't think the username parameter makes the problem worse. > EHL > > --001485eba704ab29f404839f7bf4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 6, 2010 at 11:07 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:



On 4/6/10 5:24 PM, "Evan Gilbert" <uidude@google.com> wrote:

> Proposal:
> In 2.4.1 & 2.4.2, add the following OPTIONAL parameter
> username
> =A0=A0The resource owner's username. The authorization server MUST= only send back
> refresh tokens or access tokens for the user identified by username.
What are the security implications? How can the client know that the = token
it got is really for that user?

Think t= he client has to trust the auth server, in the same way as with the usernam= e + password profile. The auth server can always send back a scope for a di= fferent user.

Worst case is that there is an identity mismatch betwee= n client and the identity implicit in the authorization token. This mismatc= h is already possible, and I don't think the username parameter makes t= he problem worse.


EHL


--001485eba704ab29f404839f7bf4-- From eran@hueniverse.com Wed Apr 7 00:08:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3FC23A681D for ; Wed, 7 Apr 2010 00:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9UlCHZ-8-BW for ; Wed, 7 Apr 2010 00:08:31 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A46B23A6774 for ; Wed, 7 Apr 2010 00:08:31 -0700 (PDT) Received: (qmail 16178 invoked from network); 7 Apr 2010 07:08:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Apr 2010 07:08:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Apr 2010 00:08:27 -0700 From: Eran Hammer-Lahav To: Evan Gilbert Date: Wed, 7 Apr 2010 00:08:22 -0700 Thread-Topic: [OAUTH-WG] Comments on Web Callback & Client Flow Thread-Index: AcrWGawx4WxfkiE1Q96aR1ABor+cggAB296n Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E17D7631E24eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:08:32 -0000 --_000_C7E17D7631E24eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What about an attacker changing the username similar to the way a callback = can be changed? EHL On 4/6/10 11:14 PM, "Evan Gilbert" wrote: On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav wr= ote: On 4/6/10 5:24 PM, "Evan Gilbert" wrote: > Proposal: > In 2.4.1 & 2.4.2, add the following OPTIONAL parameter > username > The resource owner's username. The authorization server MUST only send = back > refresh tokens or access tokens for the user identified by username. What are the security implications? How can the client know that the token it got is really for that user? Think the client has to trust the auth server, in the same way as with the = username + password profile. The auth server can always send back a scope f= or a different user. Worst case is that there is an identity mismatch between client and the ide= ntity implicit in the authorization token. This mismatch is already possibl= e, and I don't think the username parameter makes the problem worse. EHL --_000_C7E17D7631E24eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Comments on Web Callback & Client Flow What about an attacker changing the username similar to the way a cal= lback can be changed?

EHL


On 4/6/10 11:14 PM, "Evan Gilbert" <uidude@google.com> wrote:



On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:



On 4/6/10 5:24 PM, "Evan Gilbert" <uidude@google.com> wrote:

> Proposal:
> In 2.4.1 & 2.4.2, add the following OPTIONAL parameter
> username
> =A0=A0The resource owner's username. The authorization server MUST onl= y send back
> refresh tokens or access tokens for the user identified by username.
What are the security implications? How can the client know that the token<= BR> it got is really for that user?

EHL



--_000_C7E17D7631E24eranhueniversecom_-- From leifj@mnt.se Wed Apr 7 00:20:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5133A689F for ; Wed, 7 Apr 2010 00:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr3ZR82q4K-i for ; Wed, 7 Apr 2010 00:20:48 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id C4E9A3A68C1 for ; Wed, 7 Apr 2010 00:20:32 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o377KPhE014001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Apr 2010 09:20:27 +0200 (CEST) Message-ID: <4BBC3239.7020505@mnt.se> Date: Wed, 07 Apr 2010 09:20:25 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 193.10.252.66 Subject: Re: [OAUTH-WG] Scope using Realm idea X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:20:51 -0000 On 04/06/2010 11:50 PM, Eran Hammer-Lahav wrote: > That's only when you need to trust the client. If your requirements demand registration, discovery is mostly pointless (other than dynamic configuration). > At the risk of comparing apples and pears - many large-scale SAML deployments rely on discovery even though the domain of discoverable entities is provided by a registry. It isn't pointless :-) Cheers Leif From greg@blinkbox.com Wed Apr 7 03:33:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF043A68C0 for ; Wed, 7 Apr 2010 03:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW8jM7QBBe+v for ; Wed, 7 Apr 2010 03:33:29 -0700 (PDT) Received: from blinkbox.com (mail.blinkbox.com [80.169.194.210]) by core3.amsl.com (Postfix) with ESMTP id C89E23A6882 for ; Wed, 7 Apr 2010 03:33:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Importance: normal Priority: normal Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2010 11:33:22 +0100 Message-ID: <9D8B012531C07B45913FFB083D82BF530150BE98@rpc.blinkbox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Error in example in section 3.4.1.1 of draft-hammer-oauth-10 thread-index: AcrWPb9ae0yI2aMURvyBSMlmv5iszw== From: "Greg Beech" To: Subject: [OAUTH-WG] Error in example in section 3.4.1.1 of draft-hammer-oauth-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 10:34:43 -0000 Hi I noticed that there is an error in the example for section 3.4.1.1 in the latest OAuth draft. The example of building a signature base string uses the following request as an example (note the extraneous query parameters at the bottom): GET /request?b5=3D%3D%253D&a3=3Da&c%40=3D&a2=3Dr%20b HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Authorization: OAuth realm=3D"Example", oauth_consumer_key=3D"9djdj82h48djs9d2", oauth_token=3D"kkk9d7dh3k39sjv7", oauth_signature_method=3D"HMAC-SHA1", oauth_timestamp=3D"137131201", oauth_nonce=3D"7d8f3e4a", oauth_signature=3D"djosJKDKJSD8743243%2Fjdk33klY%3D" c2&a3=3D2+q I believe that this should be as follows, which will cause the documented signature base string to be constructed: GET /request?b5=3D%3D%253D&a3=3Da&c%40=3D&a2=3Dr%20b&c2=3D&a3=3D2+q = HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Authorization: OAuth realm=3D"Example", oauth_consumer_key=3D"9djdj82h48djs9d2", oauth_token=3D"kkk9d7dh3k39sjv7", oauth_signature_method=3D"HMAC-SHA1", oauth_timestamp=3D"137131201", oauth_nonce=3D"7d8f3e4a", oauth_signature=3D"djosJKDKJSD8743243%2Fjdk33klY%3D" Apologies if this is a duplicate comment; I searched the archives but could not find any reference to this issue. -- Greg =20 Blinkbox Entertainment Ltd - The best movies & TV online | Greg Beech | Senior Development Engineer Lead | +44 20 7092 8700 | +44 = 7970 480901 =20 From eran@hueniverse.com Wed Apr 7 03:47:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B85C3A694F for ; Wed, 7 Apr 2010 03:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkx+-gvw34X9 for ; Wed, 7 Apr 2010 03:47:05 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E3D413A6861 for ; Wed, 7 Apr 2010 03:47:04 -0700 (PDT) Received: (qmail 18821 invoked from network); 7 Apr 2010 10:47:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Apr 2010 10:47:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 7 Apr 2010 03:46:04 -0700 From: Eran Hammer-Lahav To: Greg Beech , OAuth WG Date: Wed, 7 Apr 2010 03:46:00 -0700 Thread-Topic: [OAUTH-WG] Error in example in section 3.4.1.1 of draft-hammer-oauth-10 Thread-Index: AcrWPb9ae0yI2aMURvyBSMlmv5iszwAAcN+u Message-ID: In-Reply-To: <9D8B012531C07B45913FFB083D82BF530150BE98@rpc.blinkbox.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E1B07831E5Aeranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Error in example in section 3.4.1.1 of draft-hammer-oauth-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 10:47:10 -0000 --_000_C7E1B07831E5Aeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While odd, this is a perfectly legal GET request with a form-encoded body. EHL On 4/7/10 3:33 AM, "Greg Beech" wrote: Hi I noticed that there is an error in the example for section 3.4.1.1 in the latest OAuth draft. The example of building a signature base string uses the following request as an example (note the extraneous query parameters at the bottom): GET /request?b5=3D%3D%253D&a3=3Da&c%40=3D&a2=3Dr%20b HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Authorization: OAuth realm=3D"Example", oauth_consumer_key=3D"9djdj82h48djs9d2", oauth_token=3D"kkk9d7dh3k39sjv7", oauth_signature_method=3D"HMAC-SHA1", oauth_timestamp=3D"137131201", oauth_nonce=3D"7d8f3e4a", oauth_signature=3D"djosJKDKJSD8743243%2Fjdk33klY%3D" c2&a3=3D2+q I believe that this should be as follows, which will cause the documented signature base string to be constructed: GET /request?b5=3D%3D%253D&a3=3Da&c%40=3D&a2=3Dr%20b&c2=3D&a3=3D2+q HT= TP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Authorization: OAuth realm=3D"Example", oauth_consumer_key=3D"9djdj82h48djs9d2", oauth_token=3D"kkk9d7dh3k39sjv7", oauth_signature_method=3D"HMAC-SHA1", oauth_timestamp=3D"137131201", oauth_nonce=3D"7d8f3e4a", oauth_signature=3D"djosJKDKJSD8743243%2Fjdk33klY%3D" Apologies if this is a duplicate comment; I searched the archives but could not find any reference to this issue. -- Greg Blinkbox Entertainment Ltd - The best movies & TV online | Greg Beech | Senior Development Engineer Lead | +44 20 7092 8700 | +44 7970= 480901 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C7E1B07831E5Aeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Error in example in section 3.4.1.1 of draft-hammer-o= auth-10 While odd, this is a perfectly legal GET request with a form-encoded = body.

EHL


On 4/7/10 3:33 AM, "Greg Beech" <greg@blinkbox.com> wrote:

Hi

I noticed that there is an error in the example for section 3.4.1.1 in
the latest OAuth draft. The example of building a signature base string
uses the following request as an example (note the extraneous query
parameters at the bottom):

     GET /request?b5=3D%3D%253D&a3=3Da&c%4= 0=3D&a2=3Dr%20b HTTP/1.1
     Host: example.com
     Content-Type: application/x-www-form-urlencod= ed
     Authorization: OAuth realm=3D"Example&qu= ot;,
            &nb= sp;       oauth_consumer_key=3D"9dj= dj82h48djs9d2",
            &nb= sp;       oauth_token=3D"kkk9d7dh3k= 39sjv7",
            &nb= sp;       oauth_signature_method=3D"= ;HMAC-SHA1",
            &nb= sp;       oauth_timestamp=3D"137131= 201",
            &nb= sp;       oauth_nonce=3D"7d8f3e4a&q= uot;,
            &nb= sp;       oauth_signature=3D"djosJK= DKJSD8743243%2Fjdk33klY%3D"

     c2&a3=3D2+q

I believe that this should be as follows, which will cause the
documented signature base string to be constructed:

     GET /request?b5=3D%3D%253D&a3=3Da&c%4= 0=3D&a2=3Dr%20b&c2=3D&a3=3D2+q HTTP/1.1
     Host: example.com
     Content-Type: application/x-www-form-urlencod= ed
     Authorization: OAuth realm=3D"Example&qu= ot;,
            &nb= sp;       oauth_consumer_key=3D"9dj= dj82h48djs9d2",
            &nb= sp;       oauth_token=3D"kkk9d7dh3k= 39sjv7",
            &nb= sp;       oauth_signature_method=3D"= ;HMAC-SHA1",
            &nb= sp;       oauth_timestamp=3D"137131= 201",
            &nb= sp;       oauth_nonce=3D"7d8f3e4a&q= uot;,
            &nb= sp;       oauth_signature=3D"djosJK= DKJSD8743243%2Fjdk33klY%3D"

Apologies if this is a duplicate comment; I searched the archives but
could not find any reference to this issue.

--
Greg





Blinkbox Entertainment Ltd - The best movies & TV online |
Greg Beech | Senior Development Engineer Lead | +44 20 7092 8700 | +44 7970= 480901

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

--_000_C7E1B07831E5Aeranhueniversecom_-- From leifj@mnt.se Wed Apr 7 04:20:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9CF3A68B8 for ; Wed, 7 Apr 2010 04:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VXDMRD8ZCXE for ; Wed, 7 Apr 2010 04:20:37 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id BA56A3A6A98 for ; Wed, 7 Apr 2010 04:20:25 -0700 (PDT) Received: from [192.36.125.216] (dhcp-216.pilsnet.sunet.se [192.36.125.216] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o37BKDWt017507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Apr 2010 13:20:15 +0200 (CEST) Message-ID: <4BBC6A6D.7020105@mnt.se> Date: Wed, 07 Apr 2010 13:20:13 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 193.10.252.66 Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 11:20:40 -0000 > Go implement whatever you want. But the spec should set the highest > practical bar it can, and requiring HTTPS is trivial. > > As a practical note, if the WG reaches consensus to drop the MUST, I would > ask the chairs to ask the security area and IESG to provide guidance whether > they would approve such document. The IESG did not approve OAuth 1.0a for > publication as an RFC until this was changed to a MUST (for PLAINTEXT) among > other comments, and that with a strong warning. > > There is also an on going effort to improve cookie security. Do we really > want OAuth to become the next weakest link? I emphatically agree. I suspect that a lot of confusion on this thread is caused by confusing implementation requirements with deployment requirements btw. Cheers Leif From rbarnes@bbn.com Wed Apr 7 07:09:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4296A3A6931 for ; Wed, 7 Apr 2010 07:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGtq8pzs1PCH for ; Wed, 7 Apr 2010 07:09:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2F8463A67E9 for ; Wed, 7 Apr 2010 07:09:13 -0700 (PDT) Received: from [192.1.255.171] (port=54877 helo=col-dhcp-192-1-255-171.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzVwL-000CgO-R5; Wed, 07 Apr 2010 10:09:10 -0400 Message-Id: <500DAF88-2DA3-479A-9849-F465F74EE753@bbn.com> From: Richard Barnes To: Leif Johansson In-Reply-To: <4BBC6A6D.7020105@mnt.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Apr 2010 10:09:12 -0400 References: <4BBC6A6D.7020105@mnt.se> X-Mailer: Apple Mail (2.936) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:09:20 -0000 To re-iterate and clarify Leif's second point, I would be in favor of making TLS: -- REQUIRED for implementations to support (== MUST) -- RECOMMENDED for deployments to use (== SHOULD) This a pretty universal pattern in IETF protocols. --Richard On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote: > >> Go implement whatever you want. But the spec should set the highest >> practical bar it can, and requiring HTTPS is trivial. >> >> As a practical note, if the WG reaches consensus to drop the MUST, >> I would >> ask the chairs to ask the security area and IESG to provide >> guidance whether >> they would approve such document. The IESG did not approve OAuth >> 1.0a for >> publication as an RFC until this was changed to a MUST (for >> PLAINTEXT) among >> other comments, and that with a strong warning. >> >> There is also an on going effort to improve cookie security. Do we >> really >> want OAuth to become the next weakest link? > > I emphatically agree. > > I suspect that a lot of confusion on this thread is caused by > confusing implementation requirements with deployment requirements > btw. > > Cheers Leif > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From uidude@google.com Wed Apr 7 08:26:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AEC128C149 for ; Wed, 7 Apr 2010 08:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.666 X-Spam-Level: X-Spam-Status: No, score=-105.666 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nn56CcjIrRT for ; Wed, 7 Apr 2010 08:26:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5598428B797 for ; Wed, 7 Apr 2010 08:23:03 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o37FMulq018426 for ; Wed, 7 Apr 2010 08:22:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270653778; bh=KHVNCRGd40Ln0vebH5t+TS7T5qU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=g7Mz2rZmQf+XhJbu15mlS6sLZoNx6ihk+d6u1BkSu0vlLiFmJJKtq9TXPd3FOR/T9 2RNdz5aVzYrV2/RYMWDiw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=VoLc+Ei41EQy30yhkdHNGx+4o9kAhARdQ0c/iLtb3k/aSKapQhY6eonpeHUq9bhdC ncC7b4lJ/E7dFVvAKoKVg== Received: from qyk4 (qyk4.prod.google.com [10.241.83.132]) by kpbe18.cbf.corp.google.com with ESMTP id o37FMmLc010790 for ; Wed, 7 Apr 2010 08:22:55 -0700 Received: by qyk4 with SMTP id 4so1184845qyk.17 for ; Wed, 07 Apr 2010 08:22:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.194 with HTTP; Wed, 7 Apr 2010 08:22:35 -0700 (PDT) In-Reply-To: References: From: Evan Gilbert Date: Wed, 7 Apr 2010 08:22:35 -0700 Received: by 10.229.181.16 with SMTP id bw16mr14407602qcb.0.1270653775259; Wed, 07 Apr 2010 08:22:55 -0700 (PDT) Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00163630fd5fe8294c0483a722ee X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 15:26:14 -0000 --00163630fd5fe8294c0483a722ee Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav wrote: > What about an attacker changing the username similar to the way a > callback can be changed? > I don't think there is a danger here. We still use all of the safeguards in place from the rest of the flow - adding this parameter never log you in when omitting the parameter would not have. It will just create more error responses. > > EHL > > > > On 4/6/10 11:14 PM, "Evan Gilbert" wrote: > > > > On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav > wrote: > > > > > On 4/6/10 5:24 PM, "Evan Gilbert" wrote: > > > Proposal: > > In 2.4.1 & 2.4.2, add the following OPTIONAL parameter > > username > > The resource owner's username. The authorization server MUST only send > back > > refresh tokens or access tokens for the user identified by username. > > What are the security implications? How can the client know that the token > it got is really for that user? > > > Think the client has to trust the auth server, in the same way as with the > username + password profile. The auth server can always send back a scope > for a different user. > > Worst case is that there is an identity mismatch between client and the > identity implicit in the authorization token. This mismatch is already > possible, and I don't think the username parameter makes the problem worse. > > > EHL > > > > --00163630fd5fe8294c0483a722ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 7, 2010 at 12:08 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
What about an attacker changing the username similar to the way a cal= lback can be changed?

I don't think there is a danger here.

We still use all of= the safeguards in place from the rest of the flow - adding this parameter = never log you in when omitting the parameter would not have. It will just c= reate more error responses.
=A0

EHL



On 4/6/10 11:14 PM, "Evan Gilbert" <uidude@google.com> wrote:



On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:



On 4/6/10 5:24 PM, "Evan Gilbert" <uidude@google.com> wrote:

> Proposal:
> In 2.4.1 & 2.4.2, add the following OPTIONAL parameter
> username
> =A0=A0The resource owner's username. The authorization server MUST= only send back
> refresh tokens or access tokens for the user identified by username.
What are the security implications? How can the client know that the token<= br> it got is really for that user?

Think the client has to trust the auth server, in the same way as with the = username + password profile. The auth server can always send back a scope f= or a different user.

Worst case is that there is an identity mismatch between client and the ide= ntity implicit in the authorization token. This mismatch is already possibl= e, and I don't think the username parameter makes the problem worse.

EHL




--00163630fd5fe8294c0483a722ee-- From jpanzer@google.com Wed Apr 7 09:29:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE2D3A67F6 for ; Wed, 7 Apr 2010 09:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=2.578, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1uDRYnwPQbW for ; Wed, 7 Apr 2010 09:29:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 525083A6954 for ; Wed, 7 Apr 2010 09:29:48 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o37GTeoT011374 for ; Wed, 7 Apr 2010 09:29:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270657781; bh=8zqNPAU16Pl06rauTF8D0v22mik=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tt8LoHVLjNToh+HXJH4HMDq272dT+EJehCNAO8+JPBqt8HpZ9Pz//z0liBXoIWCeh UhE+zJtwRX69mXW3S/duA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=BFyYcwh0ivSH40/ujeLwQFCPXP+94PEXTD0eNjml4iUiSgFqD00jTb+H8OBEKey4q CZPmSES/krcV0Hs0sEOkg== Received: from pwj1 (pwj1.prod.google.com [10.241.219.65]) by wpaz29.hot.corp.google.com with ESMTP id o37GTdOY009438 for ; Wed, 7 Apr 2010 09:29:39 -0700 Received: by pwj1 with SMTP id 1so1215167pwj.37 for ; Wed, 07 Apr 2010 09:29:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.14 with HTTP; Wed, 7 Apr 2010 09:29:18 -0700 (PDT) In-Reply-To: References: From: John Panzer Date: Wed, 7 Apr 2010 09:29:18 -0700 Received: by 10.141.107.5 with SMTP id j5mr4665862rvm.105.1270657778138; Wed, 07 Apr 2010 09:29:38 -0700 (PDT) Message-ID: To: Evan Gilbert Content-Type: multipart/alternative; boundary=000e0cd13b6a7f489e0483a81144 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 16:29:59 -0000 --000e0cd13b6a7f489e0483a81144 Content-Type: text/plain; charset=ISO-8859-1 I'm assuming that tokens need not be bound to a specific user (typically they are, but imagine a secretary granting an app access to his boss's calendar and then leaving the company and therefore being removed from the calendar ACL, but the app still keeping access by virtue of the capability granted by the token). In this case, the proposed wording seems kind of problematic for a MUST. On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert wrote: > > > On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav wrote: > >> What about an attacker changing the username similar to the way a >> callback can be changed? >> > > I don't think there is a danger here. > > We still use all of the safeguards in place from the rest of the flow - > adding this parameter never log you in when omitting the parameter would not > have. It will just create more error responses. > > >> >> EHL >> >> >> >> On 4/6/10 11:14 PM, "Evan Gilbert" wrote: >> >> >> >> On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav >> wrote: >> >> >> >> >> On 4/6/10 5:24 PM, "Evan Gilbert" wrote: >> >> > Proposal: >> > In 2.4.1 & 2.4.2, add the following OPTIONAL parameter >> > username >> > The resource owner's username. The authorization server MUST only send >> back >> > refresh tokens or access tokens for the user identified by username. >> >> What are the security implications? How can the client know that the token >> it got is really for that user? >> >> >> Think the client has to trust the auth server, in the same way as with the >> username + password profile. The auth server can always send back a scope >> for a different user. >> >> Worst case is that there is an identity mismatch between client and the >> identity implicit in the authorization token. This mismatch is already >> possible, and I don't think the username parameter makes the problem worse. >> >> >> EHL >> >> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000e0cd13b6a7f489e0483a81144 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm assuming that tokens need not be bound to a specific user (typicall= y they are, but imagine a secretary granting an app access to his boss'= s calendar and then leaving the company and therefore being removed from th= e calendar ACL, but the app still keeping access by virtue of the capabilit= y granted by the token). =A0In this case, the proposed wording seems kind o= f problematic for a MUST.

On Wed, Apr 7, 2010 at 8:22 AM, Evan Gi= lbert <uidude@goo= gle.com> wrote:


On Wed, Apr 7, 2010 at= 12:08 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<= br>
What about an attacker changing the username similar to the way a cal= lback can be changed?

I don't think there is a danger here.

We still use all of= the safeguards in place from the rest of the flow - adding this parameter = never log you in when omitting the parameter would not have. It will just c= reate more error responses.
=A0

EHL



On 4/6/10 11:14 PM, "Evan Gilbert" <uidude@google.com> wrote:



On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:



On 4/6/10 5:24 PM, "Evan Gilbert" <uidude@google.com> wrote:

> Proposal:
> In 2.4.1 & 2.4.2, add the following OPTIONAL parameter
> username
> =A0=A0The resource owner's username. The authorization server MUST= only send back
> refresh tokens or access tokens for the user identified by username.
What are the security implications? How can the client know that the token<= br> it got is really for that user?

Think the client has to trust the auth server, in the same way as with the = username + password profile. The auth server can always send back a scope f= or a different user.

Worst case is that there is an identity mismatch between client and the ide= ntity implicit in the authorization token. This mismatch is already possibl= e, and I don't think the username parameter makes the problem worse.

EHL





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


--000e0cd13b6a7f489e0483a81144-- From torsten@lodderstedt.net Wed Apr 7 11:35:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4C93A6955 for ; Wed, 7 Apr 2010 11:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.515 X-Spam-Level: X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPWbuJBxDWdC for ; Wed, 7 Apr 2010 11:35:11 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id EC4403A67B3 for ; Wed, 7 Apr 2010 11:34:37 -0700 (PDT) Received: from p4fff3b6a.dip.t-dialin.net ([79.255.59.106] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Nza5C-0003nq-0C; Wed, 07 Apr 2010 20:34:34 +0200 Message-ID: <4BBCD036.3070702@lodderstedt.net> Date: Wed, 07 Apr 2010 20:34:30 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Marius Scurtescu References: <4BBB68BB.4010206@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Access Token Exchange Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 18:35:12 -0000 Hi Marius, Am 07.04.2010 00:39, schrieb Marius Scurtescu: > On Tue, Apr 6, 2010 at 10:00 AM, Torsten Lodderstedt > wrote: > >> Hi all, >> >> here at Deutsche Telekom, we see the need for a flow supporting the exchange >> of access tokens for one service into access tokens for another service. >> >> The scenarios is as follows: In the context of mobile applications, we >> employ multi-layered architectures of personalized web services. The first >> layer typically exposes an API optimized for the flows of a particular >> application. This layer's business logic is built on top of other web >> services and so on. We use self-contained bearer tokens carrying id's, >> attributes and permissions. Each of the web services involed has a trust >> relationship with our authorization server based on shared secrets. Every >> web service requires a different token with different claims (id, >> permissions, attributes) and signature (HMAC). >> >> The flow is as follows: >> >> 1) The client acquires a token for the first service eather by >> username/password authentication or web-based authorization flow. >> >> 2) The client sends a request (including the access token) to the first web >> service. >> >> 3) Access control and some business logic is executed based on the token >> contents. Afterwards, the first service determines that it needs >> to call another services (second web service) on behalf of the user. >> >> 4) It requests the issuance of a new token for the second service from the >> authorization server based on the original token sent by the client. >> >> 5) The authorization server issues a new token carrying the claims need by >> the second web service and digitally signs the token >> with the respective shared secret. It also encrypts the token content in >> order to prevent the first web service from eavesdropping the users data >> intended for the second service only. >> >> 6) The first web service uses the token to invoke the second web service. >> >> ... >> >> Does anyone else see the need for such a flow? >> > I think I suggested something like that on the scope thread: > "Things can get even more complicated. When the user grants access for > the client, the approval page should list all the scopes the client is > requesting. This is the set of scopes needed by the client for *all* > the API calls. Each API will need a subset of this approved, larger > set. > > With that in mind, it would be useful to be able to down-scope access > tokens when using the refresh token, this way the client can send the > smallest set of scopes with each API call." > > The idea of acquiring downsized access tokens is very interesting from a security standpoint. A client could obtain a token with the least privileges set required for the transaction it is about to perform thus reducing the impact if a token gets revealed. > > In your example, instead of having the first service request a new > token for the second service, step 4, I think the client should do > that and pass the second token as an argument in the API call. > You are right, this is an alternative option. We don't go that way because we don't want the clients to know the internal structure of our services. Therefore the first service (or any other service in the call chain) is exchanging the tokens. This token exhange is more a technical "claim transformation" than a scope reduction/transformation. As I described, trust between authz server and service ist based on shared secrets (as in Kerberos) so any piece data intended for a particular service must be encrypted/HMACd with the corresponding secret. Moreover (and most important), the token payload is different. That's why we can't use the same token for the whole call chain. > Basically the client requests a refresh token with largest set of > permissions and then it uses the refresh token flow to get > lower-permission access tokens as needed. > > The first service can ask for a second token only if the set of > permissions is a sub-set of the one it received, otherwise it has not > authority to do that. > That's true. regards, Torsten. > Marius > From eran@hueniverse.com Wed Apr 7 13:51:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766EB3A6847 for ; Wed, 7 Apr 2010 13:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWPwS+xqm9j5 for ; Wed, 7 Apr 2010 13:51:17 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 002AE3A687E for ; Wed, 7 Apr 2010 13:51:07 -0700 (PDT) Received: (qmail 21748 invoked from network); 7 Apr 2010 20:51:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Apr 2010 20:51:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Apr 2010 13:51:03 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 7 Apr 2010 13:51:01 -0700 Thread-Topic: Consistency across access token replies Thread-Index: AcrWlAfthISeW8agEUKBsqlyN5E9gQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Consistency across access token replies X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 20:51:18 -0000 Right now most of the flows return the same parameters (access token, expiration, refresh token). A few do not return a refresh token. When we ad= d signatures, we will need to add token secret and algorithm type. I know there are good reasons why certain flows do not return a refresh token but instead rely on the client repeating the request. However, there is a lot of value in simplicity and consistency in making every request return the same parameters. It will also allow specifying it one time instead of over and over again. Thoughts? EHL From eran@hueniverse.com Wed Apr 7 16:14:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62DAB3A67B2 for ; Wed, 7 Apr 2010 16:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ygycOuooyUU for ; Wed, 7 Apr 2010 16:13:59 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id B8A063A69AA for ; Wed, 7 Apr 2010 16:13:45 -0700 (PDT) Received: (qmail 15556 invoked from network); 7 Apr 2010 23:13:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Apr 2010 23:13:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 7 Apr 2010 16:13:41 -0700 From: Eran Hammer-Lahav To: Paul Walker , Luke Shepard Date: Wed, 7 Apr 2010 16:13:38 -0700 Thread-Topic: [OAUTH-WG] Draft progress update Thread-Index: AcrSCKDXVyKD06baTR6C6iH3OxZkfQEn1N2W Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft progress update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 23:14:00 -0000 Yes, shorter is better, and we'll get to it later. But all the flows use a single endpoint (right now), so each request needs a unique type. EHL On 4/1/10 7:02 PM, "Paul Walker" wrote: > Along those lines, I would suggest renaming the mode values as the terms > "request" and "flow" are kinda superfluous. Perhaps >=20 > mode=3Dweb_callback > mode=3Dweb_client > mode=3Ddevice > mode=3Dcredentials > mode=3Dclient >=20 > I understand that the Web Callback Flow uses two different values, one fo= r the > authorization step and another for the access token, but is this really n= eeded > given that these are different uris? >=20 >=20 > On Mar 31, 2010, at 10:28 PM, Luke Shepard wrote: >=20 >> At first, I had the same first reaction as Marius, but after reading thi= s >> thread, I agree with Eran. Two observations: >>=20 >> 1/ OAuth endpoints are usually already namespaced as "oauth" - if there = are >> other endpoints that accept custom parameters, they can be defined elsew= here. >> For example: >>=20 >> https://www.google.com/accounts/OAuthAuthorizeToken >> https://api.login.yahoo.com/oauth/v2/request_auth >> http://twitter.com/oauth/authorize >>=20 >> 2/ We should fight to keep URLs short and leave out redundant informatio= n >> where possible. We should leave out redundant information where possible= . >>=20 >> Here are two sample URLs. The first is 12% shorter than the second. >>=20 >> http://facebook.com/oauth/authorize?mode=3Dweb_callback_access_request&c= lient_i >> d=3D123456789&callback=3Dhttp://facebook.com/oauth/callback >> http://facebook.com/oauth/authorize?oauth_mode=3Dweb_callback_access_req= uest&oa >> uth_client_id=3D123456789&oauth_callback=3Dhttp://facebook.com/oauth/cal= lback >>=20 >>=20 >>=20 >> On Mar 31, 2010, at 9:17 PM, Eran Hammer-Lahav wrote: >>=20 >>> Hey Marius, >>>=20 >>> On 3/31/10 8:37 PM, "Marius Scurtescu" wrote: >>>=20 >>>> On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav >>>> wrote: >>>>> The only significant change I have made (which is of course open to >>>>> debate) >>>>> is renaming all the authorization flows parameters. I dropped the oau= th_ >>>>> prefix (no real need since these are purely OAuth endpoints, not prot= ected >>>>> resources), and made most of the parameter names shorter. I am not do= ne so >>>>> they are not consistent yet. >>>>=20 >>>> Having a common prefix for all parameters is quite important IMO. It >>>> allows parties >>>> to define and pass additional, non-standard, parameters. >>>=20 >>> Non-standard parameter hurt interoperability. The question is whether t= he >>> right approach is to add a prefix to the protocol parameters or to the >>> extension parameters (such as x_), or none. >>>=20 >>> What prevents a custom parameter to collide with a standard extension n= ot >>> supported by the server or someone else's custom parameter? If we are >>> serious about parameter collision (which I doubt given past sentiments = on >>> registries etc.), we should require all parameters to register unless t= hey >>> have some special custom prefix. >>>=20 >>> In other word, adding the oauth_ prefix to the core parameters doesn't >>> really accomplish much, other than making requests longer. In the past, >>> people wanted to define extension parameters starting with oauth_ and w= e >>> didn't really reach consensus on whether to allow it or not. Then we pl= ayed >>> with xoauth_ for a while, then went back and just allowed oauth_ for >>> extensions. >>>=20 >>> If we keep the oauth_ prefix, do we also require a registry for extensi= ons? >>> Do we define another prefix? Do we create a registry for extension pref= ixes? >>> This gets bad really fast. >>>=20 >>>> Also, quite >>>> often parameters >>>> are added to existing URLs, and a prefix helps prevent collisions. >>>=20 >>> Extension parameters should never conflict with core parameter because = we >>> know all the core parameters before we write custom ones... >>>=20 >>> This is only for the OAuth-specific endpoint (authorization endpoint), = not >>> the protected resource endpoint in which we will still use oauth_token = (the >>> only parameter added to protected resource requests). >>>=20 >>> What do you think? >>>=20 >>> EHL >>>=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 From eran@hueniverse.com Wed Apr 7 16:22:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21CC3A67D7 for ; Wed, 7 Apr 2010 16:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt2WncRQ6Cgx for ; Wed, 7 Apr 2010 16:22:02 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4D95A3A659A for ; Wed, 7 Apr 2010 16:22:01 -0700 (PDT) Received: (qmail 21783 invoked from network); 7 Apr 2010 23:21:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Apr 2010 23:21:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 7 Apr 2010 16:21:58 -0700 From: Eran Hammer-Lahav To: Richard Barnes , Leif Johansson Date: Wed, 7 Apr 2010 16:21:56 -0700 Thread-Topic: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures Thread-Index: AcrWW+u319C0zJ3YTv+OZ50NlYuVGgATTFoi Message-ID: In-Reply-To: <500DAF88-2DA3-479A-9849-F465F74EE753@bbn.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 23:22:06 -0000 We are looking at this all wrong. There are two kinds of protected resources OAuth supports: * http:// * https:// OAuth provides two kinds of token authentication modes: * bearer token * token + signature I don't know how to translate your statement below into text I can put in the draft to answer: When you access/serve an http:// protected resource you do what? When you access/serve an https:// protected resource you do what? It is not about requiring SSL for bearer token. It is about what you can/should do when accessing an http:// resource. EHL On 4/7/10 7:09 AM, "Richard Barnes" wrote: > To re-iterate and clarify Leif's second point, I would be in favor of > making TLS: >=20 > -- REQUIRED for implementations to support (=3D=3D MUST) > -- RECOMMENDED for deployments to use (=3D=3D SHOULD) >=20 > This a pretty universal pattern in IETF protocols. >=20 > --Richard >=20 >=20 > On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote: >=20 >>=20 >>> Go implement whatever you want. But the spec should set the highest >>> practical bar it can, and requiring HTTPS is trivial. >>>=20 >>> As a practical note, if the WG reaches consensus to drop the MUST, >>> I would >>> ask the chairs to ask the security area and IESG to provide >>> guidance whether >>> they would approve such document. The IESG did not approve OAuth >>> 1.0a for >>> publication as an RFC until this was changed to a MUST (for >>> PLAINTEXT) among >>> other comments, and that with a strong warning. >>>=20 >>> There is also an on going effort to improve cookie security. Do we >>> really >>> want OAuth to become the next weakest link? >>=20 >> I emphatically agree. >>=20 >> I suspect that a lot of confusion on this thread is caused by >> confusing implementation requirements with deployment requirements >> btw. >>=20 >> Cheers Leif >> _______________________________________________ >> 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 eran@hueniverse.com Wed Apr 7 16:26:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF383A67D7 for ; Wed, 7 Apr 2010 16:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WAURRhYGkeX for ; Wed, 7 Apr 2010 16:26:19 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D99553A67B2 for ; Wed, 7 Apr 2010 16:26:19 -0700 (PDT) Received: (qmail 5807 invoked from network); 7 Apr 2010 23:26:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Apr 2010 23:26:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Apr 2010 16:26:09 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 7 Apr 2010 16:26:06 -0700 Thread-Topic: Another draft update Thread-Index: AcrWqbIjUlaC4+BgjEOhw966lZewiQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Another draft update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 23:26:21 -0000 Latest is always at: http://github.com/theRazorBlade/draft-ietf-oauth (xml is always up to date. txt and html when I can. Atom feed available) --- I finished going over sections 1-4 which includes the overview, flows, and refresh method. Next is using tokens. By finished I mean those sections are ready to be submitted as a working group draft -00. Unfortunately I am unable (or unwilling) to go back and review comments mad= e to sections I previously ignored. Please review sections 1-4 again and submit any changes needed for a -00 draft. This means focus on critical changes that should be made before the document is considered a starting point for the working group. Open issues: * token size limit * restriction on values characters * specificity of the assertion flow * parameter name prefix * single authorization endpoint * inclusion of both user-agent flow and native application flow * requiring HTTPS for bearer token protected resource requests * username parameter proposal * scope parameter * adding refresh token as optional in all access token requests * limiting signed requests to use the auth header (no query / form body) Once we approve this as -00 I plan to post a weekly draft based on the feedback received and approved by the group. I will no longer make changes to the draft (after -00) without working group consensus. Please (PLEASE) don't reply to this message with feedback but instead send = a separate post for each major issue. Feel free to bunch small comments into one post. This will help facilitate our discussion. The spec is now 50 pages before adding the security consideration and signature workflow. Its big. I would appreciate any feedback you can spare so we can decide next week if it is ready for a -00. Thanks! EHL=20 From dick.hardt@gmail.com Wed Apr 7 17:23:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702733A6842 for ; Wed, 7 Apr 2010 17:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxXDxJ8yz298 for ; Wed, 7 Apr 2010 17:23:20 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 0AE343A67E1 for ; Wed, 7 Apr 2010 17:23:19 -0700 (PDT) Received: by qyk11 with SMTP id 11so965622qyk.13 for ; Wed, 07 Apr 2010 17:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=eWEPfw/P1bvbXVTjLTepTC30SJAlgmuYkL+jC2cuIxo=; b=v0msam3JAFXeQt/QWw/b6QHhInijzvSUBTZ7Vjpj1II9u/eWI7hzzMgB32ljTiejIC FfF8ctKNV5ZHgfHeithKFu1ohh0GElURvQ4exJfzp0AEt1i8oEo6TlYEV+tKmJTjQeTH 4rA3X4tlIOrVoxL+wKObQwHuVAfYpqMo7gSRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=WaL3FUuRNf+v7d4hSQpYN+6Mk3UK4Yld+sxwlCBat1YwnW8n4YOVwJH4EqZ0lAgt0U nzHBenFHu2bYK7NC3dORxCPo7XaqvnpcOufXsZtx/TMJFC6g3+LTUyc5u1j/QvnPEEuJ +pwqCxr0GgzwTroGsJXdCfd2PfVvvi5qOz62I= Received: by 10.229.238.70 with SMTP id kr6mr3543794qcb.49.1270686193551; Wed, 07 Apr 2010 17:23:13 -0700 (PDT) Received: from [10.0.1.8] (c-67-180-195-167.hsd1.ca.comcast.net [67.180.195.167]) by mx.google.com with ESMTPS id v26sm8559549qce.19.2010.04.07.17.23.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Apr 2010 17:23:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Wed, 7 Apr 2010 17:23:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) Cc: OAuth WG Subject: Re: [OAUTH-WG] Another draft update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 00:23:22 -0000 On 2010-04-07, at 4:26 PM, Eran Hammer-Lahav wrote: > Latest is always at: >=20 > http://github.com/theRazorBlade/draft-ietf-oauth >=20 > (xml is always up to date. txt and html when I can. Atom feed = available) >=20 > --- >=20 > I finished going over sections 1-4 which includes the overview, flows, = and > refresh method. Next is using tokens. By finished I mean those = sections are > ready to be submitted as a working group draft -00. >=20 > Unfortunately I am unable (or unwilling) to go back and review = comments made > to sections I previously ignored. Please review sections 1-4 again and > submit any changes needed for a -00 draft. This means focus on = critical > changes that should be made before the document is considered a = starting > point for the working group. >=20 > Open issues: >=20 > * token size limit > * restriction on values characters > * specificity of the assertion flow > * parameter name prefix > * single authorization endpoint > * inclusion of both user-agent flow and native application flow > * requiring HTTPS for bearer token protected resource requests > * username parameter proposal > * scope parameter > * adding refresh token as optional in all access token requests > * limiting signed requests to use the auth header (no query / form = body) Are these issues where you expect to have a consensus vote and you are = only looking for other issues, or are you looking for feedback on these = as separate emails as well? -- Dick From dick.hardt@gmail.com Wed Apr 7 18:25:15 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A473A6842 for ; Wed, 7 Apr 2010 18:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWzxro4WMuK9 for ; Wed, 7 Apr 2010 18:25:09 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id BF1563A6841 for ; Wed, 7 Apr 2010 18:25:08 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so569257qwb.31 for ; Wed, 07 Apr 2010 18:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=OHlJXrIW+TgKbnYF/Q2anfLGwfZDhAsVcIKpCxdFhQM=; b=CgpIttpOZfAEYX3HqRUgvRsicR/966FlwtXMklDjkXbasZeS5uxdpUg7PMhP7iSd3N vZoUAiqwMe1UVwq43NiGuRofpt7uxBipoxELlO6ULHmBfjif7IPmKXgEPLTZifhxKW21 0xTP4zELLHfI+nffsspG0tdn0BRYCbzFp4z3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=xr8mhmqFpZUkhJaAIyExFlqFuebJeI3UzLdTh0ZUVOeJRKzzxGC5TEAKPcznRhpDdf Ta4zyWbCM5MoICvnURBKeIWj+2xTB4STCWqqb/G6THyNmEREaTaJet6SJig4ioI3hQGw G3xT2GtFR3ZSL1wpcz/CpS7gbs+osJ8C4d7+0= Received: by 10.229.181.16 with SMTP id bw16mr432650qcb.0.1270689902899; Wed, 07 Apr 2010 18:25:02 -0700 (PDT) Received: from [10.0.1.8] (c-67-180-195-167.hsd1.ca.comcast.net [67.180.195.167]) by mx.google.com with ESMTPS id w30sm8614664qce.4.2010.04.07.18.25.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Apr 2010 18:25:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Wed, 7 Apr 2010 18:24:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) Cc: OAuth WG Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 01:25:15 -0000 Eran Richard and Lief are describing the same point we had in the past where = Peter surmised the discussion that an *implementation* MUST support TLS = is required for bearer tokens to be compliant, and that TLS is = recommended for *deployment* -- Dick On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote: > We are looking at this all wrong. >=20 > There are two kinds of protected resources OAuth supports: >=20 > * http:// > * https:// >=20 > OAuth provides two kinds of token authentication modes: >=20 > * bearer token > * token + signature >=20 > I don't know how to translate your statement below into text I can put = in > the draft to answer: >=20 > When you access/serve an http:// protected resource you do what? > When you access/serve an https:// protected resource you do what? >=20 > It is not about requiring SSL for bearer token. It is about what you > can/should do when accessing an http:// resource. >=20 > EHL >=20 > On 4/7/10 7:09 AM, "Richard Barnes" wrote: >=20 >> To re-iterate and clarify Leif's second point, I would be in favor of >> making TLS: >>=20 >> -- REQUIRED for implementations to support (=3D=3D MUST) >> -- RECOMMENDED for deployments to use (=3D=3D SHOULD) >>=20 >> This a pretty universal pattern in IETF protocols. >>=20 >> --Richard >>=20 >>=20 >> On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote: >>=20 >>>=20 >>>> Go implement whatever you want. But the spec should set the highest >>>> practical bar it can, and requiring HTTPS is trivial. >>>>=20 >>>> As a practical note, if the WG reaches consensus to drop the MUST, >>>> I would >>>> ask the chairs to ask the security area and IESG to provide >>>> guidance whether >>>> they would approve such document. The IESG did not approve OAuth >>>> 1.0a for >>>> publication as an RFC until this was changed to a MUST (for >>>> PLAINTEXT) among >>>> other comments, and that with a strong warning. >>>>=20 >>>> There is also an on going effort to improve cookie security. Do we >>>> really >>>> want OAuth to become the next weakest link? >>>=20 >>> I emphatically agree. >>>=20 >>> I suspect that a lot of confusion on this thread is caused by >>> confusing implementation requirements with deployment requirements >>> btw. >>>=20 >>> Cheers Leif >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From rbarnes@bbn.com Wed Apr 7 18:42:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B8B3A68F8 for ; Wed, 7 Apr 2010 18:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5qAH3qjDesV for ; Wed, 7 Apr 2010 18:42:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8A5583A6841 for ; Wed, 7 Apr 2010 18:42:48 -0700 (PDT) Received: from [128.89.255.215] (port=59892 helo=[192.168.1.46]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzglX-000FaH-VJ; Wed, 07 Apr 2010 21:42:44 -0400 Message-Id: From: Richard Barnes To: Dick Hardt In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Apr 2010 21:42:40 -0400 References: X-Mailer: Apple Mail (2.936) Cc: OAuth WG Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 01:42:49 -0000 You guys are both right: The recommendation I made before is basically saying that you SHOULD only use tokens without signing on HTTPS resources. --Richard On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote: > Eran > > Richard and Lief are describing the same point we had in the past > where Peter surmised the discussion that an *implementation* MUST > support TLS is required for bearer tokens to be compliant, and that > TLS is recommended for *deployment* > > -- Dick > > On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote: > >> We are looking at this all wrong. >> >> There are two kinds of protected resources OAuth supports: >> >> * http:// >> * https:// >> >> OAuth provides two kinds of token authentication modes: >> >> * bearer token >> * token + signature >> >> I don't know how to translate your statement below into text I can >> put in >> the draft to answer: >> >> When you access/serve an http:// protected resource you do what? >> When you access/serve an https:// protected resource you do what? >> >> It is not about requiring SSL for bearer token. It is about what you >> can/should do when accessing an http:// resource. >> >> EHL >> >> On 4/7/10 7:09 AM, "Richard Barnes" wrote: >> >>> To re-iterate and clarify Leif's second point, I would be in favor >>> of >>> making TLS: >>> >>> -- REQUIRED for implementations to support (== MUST) >>> -- RECOMMENDED for deployments to use (== SHOULD) >>> >>> This a pretty universal pattern in IETF protocols. >>> >>> --Richard >>> >>> >>> On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote: >>> >>>> >>>>> Go implement whatever you want. But the spec should set the >>>>> highest >>>>> practical bar it can, and requiring HTTPS is trivial. >>>>> >>>>> As a practical note, if the WG reaches consensus to drop the MUST, >>>>> I would >>>>> ask the chairs to ask the security area and IESG to provide >>>>> guidance whether >>>>> they would approve such document. The IESG did not approve OAuth >>>>> 1.0a for >>>>> publication as an RFC until this was changed to a MUST (for >>>>> PLAINTEXT) among >>>>> other comments, and that with a strong warning. >>>>> >>>>> There is also an on going effort to improve cookie security. Do we >>>>> really >>>>> want OAuth to become the next weakest link? >>>> >>>> I emphatically agree. >>>> >>>> I suspect that a lot of confusion on this thread is caused by >>>> confusing implementation requirements with deployment requirements >>>> btw. >>>> >>>> Cheers Leif >>>> _______________________________________________ >>>> OAuth mailing 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 dick.hardt@gmail.com Wed Apr 7 20:05:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49FDC3A68E0 for ; Wed, 7 Apr 2010 20:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DArP92yp99NK for ; Wed, 7 Apr 2010 20:05:56 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 114513A688D for ; Wed, 7 Apr 2010 20:05:55 -0700 (PDT) Received: by gyh4 with SMTP id 4so958691gyh.31 for ; Wed, 07 Apr 2010 20:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=1DZ0H6ib2Yhrhfzbb+vQz6AmAEw+bh4D5VVJUgOrjsw=; b=uDliUAgp+9r3y4yg0nSkMI/xGVV5CBUFkiWg3LTiX64D8siyFmDL+2Z6AnP6k0enuF Wz9grVBp4NtyWNz6DlTZfTd2Zl0ng5GeTMOpOsqo9MCVIJ+H2z0pBdid/UktWkVVqb96 e5aT/ZeUUNZZOuxPc2V0wqMZ35YfnbY09XXAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=uJEhvLu1pwRvIRmqC6bbXraO7lGsjKSth1PEeGptyJlxGijE7clluaEHFURND25jDK yd2Y2/bZ4ySOORmEuGCpklCRzJCx3WRjQZ2pt42yGNFOaHxJ2xMQ+LZH/bh88kc+i2yu ZYRr/PpNw8jdGR2p/wvyqvi+Cz+voc/Cm0ySE= Received: by 10.150.193.21 with SMTP id q21mr10528681ybf.44.1270695950230; Wed, 07 Apr 2010 20:05:50 -0700 (PDT) Received: from [10.0.1.4] (c-67-180-195-167.hsd1.ca.comcast.net [67.180.195.167]) by mx.google.com with ESMTPS id 4sm3745841yxd.34.2010.04.07.20.05.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Apr 2010 20:05:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Wed, 7 Apr 2010 20:05:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D47E672-7CA0-43B9-8B8E-56B6669F0ACE@gmail.com> References: To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] Consistency across access token replies X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 03:05:57 -0000 I would envision that the requests from different flows will have a = different mode value, which makes them uniquely different requests for = the AS. I think returning a refresh token when it can't be used will lead to = confusion for Client and AS developers. -- Dick On 2010-04-07, at 1:51 PM, Eran Hammer-Lahav wrote: > Right now most of the flows return the same parameters (access token, > expiration, refresh token). A few do not return a refresh token. When = we add > signatures, we will need to add token secret and algorithm type. >=20 > I know there are good reasons why certain flows do not return a = refresh > token but instead rely on the client repeating the request. However, = there > is a lot of value in simplicity and consistency in making every = request > return the same parameters. >=20 > It will also allow specifying it one time instead of over and over = again. >=20 > Thoughts? >=20 > EHL >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sarahfaulkner3@gmail.com Wed Apr 7 20:23:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165973A6802 for ; Wed, 7 Apr 2010 20:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq3wCkinMdvs for ; Wed, 7 Apr 2010 20:23:30 -0700 (PDT) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id CD36C3A67A5 for ; Wed, 7 Apr 2010 20:23:29 -0700 (PDT) Received: by pzk29 with SMTP id 29so1591709pzk.29 for ; Wed, 07 Apr 2010 20:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=ELUnhLIe7s7BUD7JDTiP53GZxQF4DH3OVPEywyuEJsg=; b=ezY4m0Esw77b5SQmI+pQoZhbeex3CLeJ60bNnTzken4qn0hJM1p7e+LtJwhBQD7eqt +GFAx4jn5BSs0ttTdqiKE/BpjYAG94ot6V/x8mDEKojg/GWOISAIMirRRxpKVUumZXcg Hp6jpbSXovWZDks4YndXqXIL24ww7lKZbzN2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NWg4UN40LkVxqVxoDXp3onYp9lHhGE+ak1cIHzz2Hb6A/Lhlj4Q+mf01g4/q1x1QCO 5/QKxnazOQ9hyeX3fEVLT6i6zuqygLQschI+Dr45KdMzxhue58Bv9xvZL03Ukbrg9Tcf 3cPFZ4bbBDHI2/1g5t6Bu4mY5l9Cz95uaG8BI= MIME-Version: 1.0 Received: by 10.142.73.9 with HTTP; Wed, 7 Apr 2010 20:23:24 -0700 (PDT) In-Reply-To: <4D47E672-7CA0-43B9-8B8E-56B6669F0ACE@gmail.com> References: <4D47E672-7CA0-43B9-8B8E-56B6669F0ACE@gmail.com> Date: Wed, 7 Apr 2010 20:23:24 -0700 Received: by 10.142.209.1 with SMTP id h1mr1925157wfg.269.1270697004231; Wed, 07 Apr 2010 20:23:24 -0700 (PDT) Message-ID: From: Sarah Faulkner To: Dick Hardt Content-Type: multipart/alternative; boundary=000e0cd32c988def0b0483b133c8 Cc: OAuth WG Subject: Re: [OAUTH-WG] Consistency across access token replies X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 03:23:32 -0000 --000e0cd32c988def0b0483b133c8 Content-Type: text/plain; charset=ISO-8859-1 I think it depends on which profiles we end up with. If we have the web and rich client profiles from Dick's WRAP draft plus the JS profile from David's draft, I would want to return the refresh token with the first two profiles but not with the third. Since our refresh tokens are going to be very long lived in most cases (months), I'd like to promote that they are kept server-side. I don't want to return the refresh token to the client in the JS profile and have it sent to the server over HTTP or set in a cookie. At the very least, I would like the refresh token return to be optional if it's not returned in a server-to-server or to a device that has secure storage. This brings up the question of the device profile -- there are some devices (ex. xbox) that have a way to secure the refresh token, there are others that do not. It may be good to either allow the device to self-declare (in the request, specifically ask for the refresh token) or allow the provider to optionally return the refresh token based on what they know about the device. On Wed, Apr 7, 2010 at 8:05 PM, Dick Hardt wrote: > I would envision that the requests from different flows will have a > different mode value, which makes them uniquely different requests for the > AS. > > I think returning a refresh token when it can't be used will lead to > confusion for Client and AS developers. > > -- Dick > > On 2010-04-07, at 1:51 PM, Eran Hammer-Lahav wrote: > > > Right now most of the flows return the same parameters (access token, > > expiration, refresh token). A few do not return a refresh token. When we > add > > signatures, we will need to add token secret and algorithm type. > > > > I know there are good reasons why certain flows do not return a refresh > > token but instead rely on the client repeating the request. However, > there > > is a lot of value in simplicity and consistency in making every request > > return the same parameters. > > > > It will also allow specifying it one time instead of over and over again. > > > > Thoughts? > > > > EHL > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd32c988def0b0483b133c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I think it depends on which profiles we end up with. = If we have the web and rich client profiles from Dick's WRAP draft plus= the JS profile from David's draft, I would want to return the refresh = token with the first two profiles but not with the third. Since our refresh= tokens are going to be very long lived in most cases (months), I'd lik= e to promote that they are kept server-side. I don't want to return the= refresh token to the client in the JS profile and have it sent to the serv= er over HTTP or set in a cookie.

=A0

At the very least, I would like the refresh token ret= urn to be optional if it's not returned in a server-to-server or to a d= evice that has secure storage.

=A0

This brings up the question of the device profile -- = there are some devices (ex. xbox) that have a way to secure the refresh tok= en, there are others that do not. It may be good to either allow the device= to self-declare (in the request, specifically ask for the refresh token) o= r allow the provider to optionally return the refresh token based on what t= hey know about the device.



On Wed, Apr 7, 2010 at 8:05 PM, Dick Hardt <dick.hardt@gmail.c= om> wrote:
I would envision that the reques= ts from different flows will have a different mode value, which makes them = uniquely different requests for the AS.

I think returning a refresh token when it can't be used will lead t= o confusion for Client and AS developers.

--= Dick

On 2010-04-07, at 1:51 PM, Eran Hammer-Lahav wrote:
> Right now most of the flows return the same parameters (access t= oken,
> expiration, refresh token). A few do not return a refresh tok= en. When we add
> signatures, we will need to add token secret and algorithm type.
&g= t;
> I know there are good reasons why certain flows do not return a = refresh
> token but instead rely on the client repeating the request.= However, there
> is a lot of value in simplicity and consistency in making every reques= t
> return the same parameters.
>
> It will also allow sp= ecifying it one time instead of over and over again.
>
> Though= ts?
>
> EHL
>
> __________________________________________= _____
> OAuth mailing list
> = OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing listOAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth

--000e0cd32c988def0b0483b133c8-- From uidude@google.com Wed Apr 7 21:21:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165983A693C for ; Wed, 7 Apr 2010 21:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.543 X-Spam-Level: X-Spam-Status: No, score=-101.543 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u718SfEkD8S6 for ; Wed, 7 Apr 2010 21:21:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1F5573A68D1 for ; Wed, 7 Apr 2010 21:21:39 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [10.3.21.12]) by smtp-out.google.com with ESMTP id o384LWiI028826 for ; Thu, 8 Apr 2010 06:21:32 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270700492; bh=6wzM86NRkPHAcpCtQB/ZRzaTFFs=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=IAkfrr3BQbnTwzeCr/0JDf8fU8FxXXB1Bj/mR4pv2rBYdxN9lxbc6VgnOoXix2D/8 dWfNq2CEcr7Sm2bDZeg3g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type:x-system-of-record; b=J4+2Ng3h7rlUw1KmKULa7ZLKRQ2UeujpLrA4tvzDHJ8VT+W/uVDmg93kwh+8hbDlj sSR09/l3+wK6359sk3FWw== Received: from qw-out-1920.google.com (qwk4.prod.google.com [10.241.195.132]) by hpaq12.eem.corp.google.com with ESMTP id o384LQsI003399 for ; Thu, 8 Apr 2010 06:21:31 +0200 Received: by qw-out-1920.google.com with SMTP id 4so588478qwk.22 for ; Wed, 07 Apr 2010 21:21:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.194 with HTTP; Wed, 7 Apr 2010 21:20:58 -0700 (PDT) From: Evan Gilbert Date: Wed, 7 Apr 2010 21:20:58 -0700 Received: by 10.229.184.130 with SMTP id ck2mr13684862qcb.95.1270700480120; Wed, 07 Apr 2010 21:21:20 -0700 (PDT) Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary=0016362848c2bd26fd0483b20251 X-System-Of-Record: true Subject: [OAUTH-WG] Option to not prompt the user for authorization X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 04:21:47 -0000 --0016362848c2bd26fd0483b20251 Content-Type: text/plain; charset=ISO-8859-1 Authorization servers in the OAuth Web Callback flow and the User Agent flow should have the option to redirect back with access/refresh tokens without prompting the user, if the client has already been granted access to the protected resource. This is already implied by some of the text (3.4.3.1 "After receiving (or establishing via other means) an authorization decision from the resource owner", but is not supported by the example flows. Suggested changes 3.4.1 Web Callback Flow (B) The authorization server authenticates the end user (via the user-agent) and *MAY prompt* the end user to grant or deny the client's access request. (C) *If authorization server determines the client has access to protected resource*, the authorization server redirects the user-agent back to the client to the callback URI provided earlier. The authorization includes a verification code for the client to use to obtain an access token 3.4.3 User Agent Flow (B) The authorization server authenticates the end user (via the user-agent) and *MAY prompt* the end user to grant or deny the client's access request. (C) *If authorization server determines the client has access to protected resource*, the authorization server redirects the user-agent to the redirection URI provided earlier. The redirection URI includes the access token in the URI fragment. Also, in cases where the authorization server doesn't prompt the user, we may want the ability for a client to ask for an immediate decision from the server instead of prompting the user using a parameter. Suggested changes: 3.4.1.1 Web Callback Flow | Client Requests Authorization 3.4.3.1 User Agent Flow | Client Requests Authorization (new parameter) immediate OPTIONAL. The parameter value must be set to "true" or "false" (case sensitive). If set to "true", then the authorization flow MUST check immediately if the client has access to protected resource and redirect back with a successful response or "user_denied" error without prompting the user. Evan --0016362848c2bd26fd0483b20251 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Authorization servers in the OAuth Web Callback flow and the User Agent flo= w should have the option to redirect back with access/refresh tokens withou= t prompting the user, if the client has already been granted access to the = protected resource.

This is already implied by some of the text (3.4.3.1 "After receiv= ing (or establishing via other means) an authorization=A0decision from the = resource owner", but is not supported by the example flows.

Suggested changes

3.4.1 Web Callback Flow
=
=A0=A0 (B) The authorization server authenticates the end user (via the= =A0user-agent) and MAY prompt the end user to grant or deny the=A0cl= ient's access request.
=A0=A0 (C)=A0If authorization server determines the client has access to= protected resource, the authorization server=A0redirects the user-agen= t back to the client to the callback URI=A0provided earlier. The authorizat= ion includes a verification=A0code for the client to use to obtain an acces= s token
3.4.3 User Agent Flow

=A0=A0 (B) The authorization server aut= henticates the end user (via the=A0user-agent) and MAY prompt the en= d user to grant or deny the=A0client's access request.
=A0=A0 (C) If authorization server determines the client has access to protected reso= urce, the authorization server=A0redirects the user-agent to the redire= ction URI provided=A0earlier. The redirection URI includes the access token= in the=A0URI fragment.

Also, in cases where the authorizatio= n server doesn't prompt the user, we may want the ability for a client = to ask for an immediate decision from the server instead of prompting the u= ser using a parameter. Suggested changes:

3.4.1.1 Web Callback Flow | Client Requests Authorizati= on
3.4.3.1 User Agent Flow | Client Requests Authorization
<= div>
(new parameter)
immediate
=A0=A0OPTI= ONAL. The parameter value must be set to "true" or "false&qu= ot; (case sensitive). If set to "true", then the authorization fl= ow MUST check immediately if the client has access to protected resource an= d redirect back with a successful response or "user_denied" error= without prompting the user.

Evan
--0016362848c2bd26fd0483b20251-- From uidude@google.com Wed Apr 7 22:51:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6433A687C for ; Wed, 7 Apr 2010 22:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.651 X-Spam-Level: X-Spam-Status: No, score=-101.651 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e8ycQye7guj for ; Wed, 7 Apr 2010 22:51:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id EFFF03A69F0 for ; Wed, 7 Apr 2010 22:46:57 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [10.3.21.3]) by smtp-out.google.com with ESMTP id o385kmNT014664 for ; Thu, 8 Apr 2010 07:46:48 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270705608; bh=JKofaj4HyH+mzRO1Pk+k+lqSkvI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZSrfEe91SVpdLSzkz2MaCcqttauHbgbvC3hruE8GOAFdYnXGQDmiipX0Oqs9ftG/B KccPJtzMLRRQDKS7ANL2w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=Te3XWl9dr9F8bdtfHIPc1RXC8e9QHdshew4Y0QNbTUEqvLXqQ4dlqikJAntMk9KBp hqvxnc8m24tdO7xZW9PAQ== Received: from qw-out-2122.google.com (qwh8.prod.google.com [10.241.194.200]) by hpaq3.eem.corp.google.com with ESMTP id o385kkOq003167 for ; Thu, 8 Apr 2010 07:46:47 +0200 Received: by qw-out-2122.google.com with SMTP id 8so599197qwh.47 for ; Wed, 07 Apr 2010 22:46:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.194 with HTTP; Wed, 7 Apr 2010 22:46:18 -0700 (PDT) In-Reply-To: References: From: Evan Gilbert Date: Wed, 7 Apr 2010 22:46:18 -0700 Received: by 10.229.217.14 with SMTP id hk14mr894493qcb.89.1270705600351; Wed, 07 Apr 2010 22:46:40 -0700 (PDT) Message-ID: To: John Panzer Content-Type: multipart/alternative; boundary=00163630f7a3ecf50f0483b333fe X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 05:51:33 -0000 --00163630f7a3ecf50f0483b333fe Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 7, 2010 at 9:29 AM, John Panzer wrote: > I'm assuming that tokens need not be bound to a specific user (typically > they are, but imagine a secretary granting an app access to his boss's > calendar and then leaving the company and therefore being removed from the > calendar ACL, but the app still keeping access by virtue of the capability > granted by the token). In this case, the proposed wording seems kind of > problematic for a MUST. Note that the "resource owner" in this case is the secretary, not his boss. Resource owner is "An entity capable of granting access to a protected resource." Since access tokens are bound to the resource owner ("A unique identifier used by the client to make authenticated requests on behalf of the resource owner."), I think in this case the system would have a clear way to revoke access to the document. Updating the wording on the proposal slightly to clarify (also changing format to new parameter formatting) Before: username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username Current: username OPTIONAL. The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens *capable of making requests on behalf of* the user identified by username > > On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert wrote: > >> >> >> On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav wrote: >> >>> What about an attacker changing the username similar to the way a >>> callback can be changed? >>> >> >> I don't think there is a danger here. >> >> We still use all of the safeguards in place from the rest of the flow - >> adding this parameter never log you in when omitting the parameter would not >> have. It will just create more error responses. >> >> >>> >>> EHL >>> >>> >>> >>> On 4/6/10 11:14 PM, "Evan Gilbert" wrote: >>> >>> >>> >>> On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav >>> wrote: >>> >>> >>> >>> >>> On 4/6/10 5:24 PM, "Evan Gilbert" wrote: >>> >>> > Proposal: >>> > In 2.4.1 & 2.4.2, add the following OPTIONAL parameter >>> > username >>> > The resource owner's username. The authorization server MUST only >>> send back >>> > refresh tokens or access tokens for the user identified by username. >>> >>> What are the security implications? How can the client know that the >>> token >>> it got is really for that user? >>> >>> >>> Think the client has to trust the auth server, in the same way as with >>> the username + password profile. The auth server can always send back a >>> scope for a different user. >>> >>> Worst case is that there is an identity mismatch between client and the >>> identity implicit in the authorization token. This mismatch is already >>> possible, and I don't think the username parameter makes the problem worse. >>> >>> >>> EHL >>> >>> >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --00163630f7a3ecf50f0483b333fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Ap= r 7, 2010 at 9:29 AM, John Panzer <jpanzer@google.com> wrote:
I'm assuming that tokens need not be bound to a specific user (typicall= y they are, but imagine a secretary granting an app access to his boss'= s calendar and then leaving the company and therefore being removed from th= e calendar ACL, but the app still keeping access by virtue of the capabilit= y granted by the token). =A0In this case, the proposed wording seems kind o= f problematic for a MUST.

Note that the "resource owner" in this case is the secre= tary, not his boss. Resource owner is "An entity capable of granting a= ccess to a protected resource."

Since access tokens are = bound to the resource owner ("A unique identifier used by the client t= o make authenticated=A0requests on behalf of the resource owner."), I think in this = case the system would have a clear way to revoke access to the document.=A0

Updating the wording on the proposal slightly to clarify (also changi= ng format to new parameter formatting)

Before:username
=A0=A0The resource owner's username. The authorization server MU= ST only send back refresh tokens or access tokens for the user identified b= y username

C= urrent:
username<= div> =A0=A0OPTIONAL= . The resource owner's username. The authorization server MUST only sen= d back refresh tokens or access tokens capable of making requests on beh= alf of the user identified by username
=A0

On We= d, Apr 7, 2010 at 8:22 AM, Evan Gilbert <uidude@google.com> = wrote:


On Wed, Apr 7, 2010 at 12:08 AM, Er= an Hammer-Lahav <eran@hueniverse.com> wrote:
What about an attacker changing the username similar to the way a cal= lback can be changed?

I don't think there is a danger here.

We still use all of= the safeguards in place from the rest of the flow - adding this parameter = never log you in when omitting the parameter would not have. It will just c= reate more error responses.
=A0

EHL



On 4/6/10 11:14 PM, "Evan Gilbert" <uidude@google.com> wrote:



On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:



On 4/6/10 5:24 PM, "Evan Gilbert" <uidude@google.com> wrote:

> Proposal:
> In 2.4.1 & 2.4.2, add the following OPTIONAL parameter
> username
> =A0=A0The resource owner's username. The authorization server MUST= only send back
> refresh tokens or access tokens for the user identified by username.
What are the security implications? How can the client know that the token<= br> it got is really for that user?

Think the client has to trust the auth server, in the same way as with the = username + password profile. The auth server can always send back a scope f= or a different user.

Worst case is that there is an identity mismatch between client and the ide= ntity implicit in the authorization token. This mismatch is already possibl= e, and I don't think the username parameter makes the problem worse.

EHL





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



--00163630f7a3ecf50f0483b333fe-- From eran@hueniverse.com Wed Apr 7 22:58:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07B13A699C for ; Wed, 7 Apr 2010 22:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZZYgwxmflxk for ; Wed, 7 Apr 2010 22:58:02 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D48CB3A6982 for ; Wed, 7 Apr 2010 22:58:01 -0700 (PDT) Received: (qmail 5649 invoked from network); 8 Apr 2010 05:57:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Apr 2010 05:57:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 7 Apr 2010 22:57:57 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Wed, 7 Apr 2010 22:57:54 -0700 Thread-Topic: [OAUTH-WG] Another draft update Thread-Index: AcrWsa4XUk0ewDywQzS5IKf4soShWQALr/q+ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Another draft update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 05:58:02 -0000 On 4/7/10 5:23 PM, "Dick Hardt" wrote: >=20 >=20 > On 2010-04-07, at 4:26 PM, Eran Hammer-Lahav wrote: >=20 >> * token size limit >> * restriction on values characters >> * specificity of the assertion flow >> * parameter name prefix >> * single authorization endpoint >> * inclusion of both user-agent flow and native application flow >> * requiring HTTPS for bearer token protected resource requests >> * username parameter proposal >> * scope parameter >> * adding refresh token as optional in all access token requests >> * limiting signed requests to use the auth header (no query / form body) >=20 > Are these issues where you expect to have a consensus vote and you are on= ly > looking for other issues, or are you looking for feedback on these as sep= arate > emails as well? I just listed all the issues people reported which were not (yet) addressed in the draft. I didn't want to give the impression that by not addressing them, some decision has been made. I expect us to continue to debate them and hope that consensus will emerge or that the chairs will start working more actively to resolve them. So yes, please do provide feedback on these or any other issues you have. As for reaching consensus, I will leave it up to the chairs to decide their favorite method, but what worked well for us in the past is to make a statement that reflects what the majority seems to want with the reasons fo= r and against and then ask if someone has *strong* objections. And this is not limited to the chairs. If you feel a position you agree wit= h has consensus, please do sum it up and ask if people are ok moving forward with that view. The key is that you need to have *strong* objections, not just keep pointing out that something can be slightly better. EHL From eran@hueniverse.com Wed Apr 7 23:06:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FCC3A6888 for ; Wed, 7 Apr 2010 23:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_OBFU_AMP2B=2.555] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu80l-cL95bN for ; Wed, 7 Apr 2010 23:06:30 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 79CC63A6853 for ; Wed, 7 Apr 2010 23:06:30 -0700 (PDT) Received: (qmail 7192 invoked from network); 8 Apr 2010 06:06:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Apr 2010 06:06:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 7 Apr 2010 23:06:26 -0700 From: Eran Hammer-Lahav To: Richard Barnes , Dick Hardt Date: Wed, 7 Apr 2010 23:06:23 -0700 Thread-Topic: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures Thread-Index: AcrWvMoG4vV7aOOBTgC4xD/VrBwIfQAJNNfm Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E2C06F31ED0eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 06:06:32 -0000 --_000_C7E2C06F31ED0eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How about something like this: When accessing resources using the http URI scheme, clients SHOULD NOT use = and servers SHOULD NOT accept bearer token requests (unsigned requests) as = such a request is equal to sending unprotected credentials in the clear. In= stead, clients SHOULD obtain and utilize an access token with a matching se= cret by sending a signed request. Servers MUST accept signed requests for p= rotected resources using the http URI scheme. EHL On 4/7/10 6:42 PM, "Richard Barnes" wrote: You guys are both right: The recommendation I made before is basically saying that you SHOULD only use tokens without signing on HTTPS resources. --Richard On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote: > Eran > > Richard and Lief are describing the same point we had in the past > where Peter surmised the discussion that an *implementation* MUST > support TLS is required for bearer tokens to be compliant, and that > TLS is recommended for *deployment* > > -- Dick > > On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote: > >> We are looking at this all wrong. >> >> There are two kinds of protected resources OAuth supports: >> >> * http:// >> * https:// >> >> OAuth provides two kinds of token authentication modes: >> >> * bearer token >> * token + signature >> >> I don't know how to translate your statement below into text I can >> put in >> the draft to answer: >> >> When you access/serve an http:// protected resource you do what? >> When you access/serve an https:// protected resource you do what? >> >> It is not about requiring SSL for bearer token. It is about what you >> can/should do when accessing an http:// resource. >> >> EHL >> >> On 4/7/10 7:09 AM, "Richard Barnes" wrote: >> >>> To re-iterate and clarify Leif's second point, I would be in favor >>> of >>> making TLS: >>> >>> -- REQUIRED for implementations to support (=3D=3D MUST) >>> -- RECOMMENDED for deployments to use (=3D=3D SHOULD) >>> >>> This a pretty universal pattern in IETF protocols. >>> >>> --Richard >>> >>> >>> On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote: >>> >>>> >>>>> Go implement whatever you want. But the spec should set the >>>>> highest >>>>> practical bar it can, and requiring HTTPS is trivial. >>>>> >>>>> As a practical note, if the WG reaches consensus to drop the MUST, >>>>> I would >>>>> ask the chairs to ask the security area and IESG to provide >>>>> guidance whether >>>>> they would approve such document. The IESG did not approve OAuth >>>>> 1.0a for >>>>> publication as an RFC until this was changed to a MUST (for >>>>> PLAINTEXT) among >>>>> other comments, and that with a strong warning. >>>>> >>>>> There is also an on going effort to improve cookie security. Do we >>>>> really >>>>> want OAuth to become the next weakest link? >>>> >>>> I emphatically agree. >>>> >>>> I suspect that a lot of confusion on this thread is caused by >>>> confusing implementation requirements with deployment requirements >>>> btw. >>>> >>>> Cheers Leif >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --_000_C7E2C06F31ED0eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] HTTPS requirement for using an Access Token without s= ignatures How about something like this:

When accessing resources using the http URI scheme, clients SHOULD NOT use = and servers SHOULD NOT accept bearer token requests (unsigned requests) as = such a request is equal to sending unprotected credentials in the clear. In= stead, clients SHOULD obtain and utilize an access token with a matching se= cret by sending a signed request. Servers MUST accept signed requests for p= rotected resources using the http URI scheme.

EHL

 


On 4/7/10 6:42 PM, "Richard Barnes" <rbarnes@bbn.com> wrote:

You guys are both right: The recommendation= I made before is basically
saying that you SHOULD only use tokens without signing on HTTPS
resources.

--Richard


On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote:

> Eran
>
> Richard and Lief are describing the same point we had in the past
> where Peter surmised the discussion that an *implementation* MUST
> support TLS is required for bearer tokens to be compliant, and that > TLS is recommended for *deployment*
>
> -- Dick
>
> On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote:
>
>> We are looking at this all wrong.
>>
>> There are two kinds of protected resources OAuth supports:
>>
>> * http://
>> * https://
>>
>> OAuth provides two kinds of token authentication modes:
>>
>> * bearer token
>> * token + signature
>>
>> I don't know how to translate your statement below into text I can=
>> put in
>> the draft to answer:
>>
>> When you access/serve an http:// protected= resource you do what?
>> When you access/serve an https:// protect= ed resource you do what?
>>
>> It is not about requiring SSL for bearer token. It is about what y= ou
>> can/should do when accessing an http:// re= source.
>>
>> EHL
>>
>> On 4/7/10 7:09 AM, "Richard Barnes" <rbarnes@bbn.com> wrote:
>>
>>> To re-iterate and clarify Leif's second point, I would be in f= avor
>>> of
>>> making TLS:
>>>
>>> -- REQUIRED for implementations to support (=3D=3D MUST)
>>> -- RECOMMENDED for deployments to use (=3D=3D SHOULD)
>>>
>>> This a pretty universal pattern in IETF protocols.
>>>
>>> --Richard
>>>
>>>
>>> On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote:
>>>
>>>>
>>>>> Go implement whatever you want. But the spec should se= t the
>>>>> highest
>>>>> practical bar it can, and requiring HTTPS is trivial.<= BR> >>>>>
>>>>> As a practical note, if the WG reaches consensus to dr= op the MUST,
>>>>> I would
>>>>> ask the chairs to ask the security area and IESG to pr= ovide
>>>>> guidance whether
>>>>> they would approve such document. The IESG did not app= rove OAuth
>>>>> 1.0a for
>>>>> publication as an RFC until this was changed to a MUST= (for
>>>>> PLAINTEXT) among
>>>>> other comments, and that with a strong warning.
>>>>>
>>>>> There is also an on going effort to improve cookie sec= urity. Do we
>>>>> really
>>>>> want OAuth to become the next weakest link?
>>>>
>>>> I emphatically agree.
>>>>
>>>> I suspect that a lot of confusion on this thread is caused= by
>>>> confusing implementation requirements with deployment requ= irements
>>>> btw.
>>>>
>>>>     Cheers Leif
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> ht= tps://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://ww= w.ietf.org/mailman/listinfo/oauth
>


--_000_C7E2C06F31ED0eranhueniversecom_-- From eran@hueniverse.com Wed Apr 7 23:13:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16AD13A6973 for ; Wed, 7 Apr 2010 23:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaHl2dr16iff for ; Wed, 7 Apr 2010 23:13:19 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B8D033A6919 for ; Wed, 7 Apr 2010 23:13:10 -0700 (PDT) Received: (qmail 8170 invoked from network); 8 Apr 2010 06:13:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Apr 2010 06:13:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 7 Apr 2010 23:13:07 -0700 From: Eran Hammer-Lahav To: Sarah Faulkner , Dick Hardt Date: Wed, 7 Apr 2010 23:13:04 -0700 Thread-Topic: [OAUTH-WG] Consistency across access token replies Thread-Index: AcrWyto2+BjpBfujTaezUGL+5wLSxwAF7IwB Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Consistency across access token replies X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 06:13:25 -0000 My point is simple. *Server* should be allowed to include a refresh token with every access token issued. It is already optional everywhere it is included. What I suggested is to allow it to be optional everywhere. If the server doesn't support refresh tokens for some flows, it should simply not provide one. Its a deployment decision. Nowhere in the spec can the client demand it so this is purely a server deployment decision. If my server supports refresh tokens in the client credentials flow or assertion flow, it should be allowed to issue one. What is the gain from forbidding it? The gain from allowing it (as optional) is consistency and simplicity. What's the gain from not letting servers decide? EHL On 4/7/10 8:23 PM, "Sarah Faulkner" wrote: > I think it depends on which profiles we end up with. If we have the web a= nd > rich client profiles from Dick's WRAP draft plus the JS profile from Davi= d's > draft, I would want to return the refresh token with the first two profil= es > but not with the third. Since our refresh tokens are going to be very lon= g > lived in most cases (months), I'd like to promote that they are kept > server-side. I don't want to return the refresh token to the client in th= e JS > profile and have it sent to the server over HTTP or set in a cookie. > =A0 > At the very least, I would like the refresh token return to be optional i= f > it's not returned in a server-to-server or to a device that has secure > storage.=20 > =A0 > This brings up the question of the device profile -- there are some devic= es > (ex. xbox) that have a way to secure the refresh token, there are others = that > do not. It may be good to either allow the device to self-declare (in the > request, specifically ask for the refresh token) or allow the provider to > optionally return the refresh token based on what they know about the dev= ice. >=20 >=20 > On Wed, Apr 7, 2010 at 8:05 PM, Dick Hardt wrote: >> I would envision that the requests from different flows will have a diff= erent >> mode value, which makes them uniquely different requests for the AS. >>=20 >> I think returning a refresh token when it can't be used will lead to >> confusion for Client and AS developers. >>=20 >> -- Dick >>=20 >> On 2010-04-07, at 1:51 PM, Eran Hammer-Lahav wrote: >>=20 >>> Right now most of the flows return the same parameters (access token, >>> expiration, refresh token). A few do not return a refresh token. When w= e add >>> signatures, we will need to add token secret and algorithm type. >>>=20 >>> I know there are good reasons why certain flows do not return a refresh >>> token but instead rely on the client repeating the request. However, th= ere >>> is a lot of value in simplicity and consistency in making every request >>> return the same parameters. >>>=20 >>> It will also allow specifying it one time instead of over and over agai= n. >>>=20 >>> Thoughts? >>>=20 >>> EHL >>>=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 From eran@hueniverse.com Wed Apr 7 23:22:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7153A69D4 for ; Wed, 7 Apr 2010 23:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Axlie6eNJX1d for ; Wed, 7 Apr 2010 23:22:43 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8BCC13A69C6 for ; Wed, 7 Apr 2010 23:21:30 -0700 (PDT) Received: (qmail 10605 invoked from network); 8 Apr 2010 06:21:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Apr 2010 06:21:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 7 Apr 2010 23:21:26 -0700 From: Eran Hammer-Lahav To: Evan Gilbert , John Panzer Date: Wed, 7 Apr 2010 23:21:24 -0700 Thread-Topic: [OAUTH-WG] Comments on Web Callback & Client Flow Thread-Index: AcrW3uH7GOh84M5qRQ6gDfhBHF+4BgABNRwF Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 06:22:45 -0000 I will leave this to the security folks to decide but it seems to me that i= f the client asks to limit the username of the end user granting access by specifying it in the request, the server must repeat that information when issuing such a token. Otherwise, an attacker can force a user to grant access to another account (for example, if they have both a personal and work accounts on the same server) without the client being able to detect it. In other words, if the client can demand an access token for a specific username, it should be able to have the absolute confidence (assuming it trusts the server) that the access token received has that attribute. EHL On 4/7/10 10:46 PM, "Evan Gilbert" wrote: >=20 >=20 >=20 > On Wed, Apr 7, 2010 at 9:29 AM, John Panzer wrote: >> I'm assuming that tokens need not be bound to a specific user (typically= they >> are, but imagine a secretary granting an app access to his boss's calend= ar >> and then leaving the company and therefore being removed from the calend= ar >> ACL, but the app still keeping access by virtue of the capability grante= d by >> the token). =A0In this case, the proposed wording seems kind of problema= tic for >> a MUST. >=20 > Note that the "resource owner" in this case is the secretary, not his bos= s. > Resource owner is "An entity capable of granting access to a protected > resource." >=20 > Since access tokens are bound to the resource owner ("A unique identifier= used > by the client to make authenticated=A0requests on behalf of the resource > owner."), I think in this case the system would have a clear way to revok= e > access to the document.=A0 >=20 > Updating the wording on the proposal slightly to clarify (also changing f= ormat > to new parameter formatting) >=20 > Before: > username > =A0=A0The resource owner's username. The authorization server MUST only s= end back > refresh tokens or access tokens for the user identified by username >=20 > Current: > username > =A0=A0OPTIONAL. The resource owner's username. The authorization server M= UST only > send back refresh tokens or access tokens capable of making requests on b= ehalf > of the user identified by username > =A0 >>=20 >> On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert wrote: >>>=20 >>>=20 >>> On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav >>> wrote: >>>> What about an attacker changing the username similar to the way a call= back >>>> can be changed? >>>=20 >>> I don't think there is a danger here. >>>=20 >>> We still use all of the safeguards in place from the rest of the flow - >>> adding this parameter never log you in when omitting the parameter woul= d not >>> have. It will just create more error responses. >>> =A0 >>>>=20 >>>> EHL >>>>=20 >>>>=20 >>>>=20 >>>> On 4/6/10 11:14 PM, "Evan Gilbert" >>> > wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav >>>> > wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 4/6/10 5:24 PM, "Evan Gilbert" >>>>> > wrote: >>>>>>=20 >>>>>>> Proposal: >>>>>>> In 2.4.1 & 2.4.2, add the following OPTIONAL parameter >>>>>>> username >>>>>>> =A0=A0The resource owner's username. The authorization server MUST = only send >>>>>>> back >>>>>>> refresh tokens or access tokens for the user identified by username= . >>>>>>=20 >>>>>> What are the security implications? How can the client know that the >>>>>> token >>>>>> it got is really for that user? >>>>>=20 >>>>> Think the client has to trust the auth server, in the same way as wit= h the >>>>> username + password profile. The auth server can always send back a s= cope >>>>> for a different user. >>>>>=20 >>>>> Worst case is that there is an identity mismatch between client and t= he >>>>> identity implicit in the authorization token. This mismatch is alread= y >>>>> possible, and I don't think the username parameter makes the problem >>>>> worse. >>>>>=20 >>>>>>=20 >>>>>> EHL >>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 >=20 From jpanzer@google.com Wed Apr 7 23:41:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1782C3A68DA for ; Wed, 7 Apr 2010 23:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.687 X-Spam-Level: X-Spam-Status: No, score=-104.687 tagged_above=-999 required=5 tests=[AWL=1.289, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWTwK3YDXVn5 for ; Wed, 7 Apr 2010 23:41:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 7115C3A68D4 for ; Wed, 7 Apr 2010 23:41:22 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o386fGJK000544 for ; Wed, 7 Apr 2010 23:41:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270708876; bh=C9AScxswOARqf2YeQyBENt8ZbZo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=HS+zWlABkSfkSRn2tiryNbJnHowgDGr1ulIz1JLnA0XDm5uYbX0tR+9m9RLnG7rrG W9L2bnA83+7YxTua7xQTw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=mpF7uQZrjBqaLubdNQeuEcrvvnsJyhF6d77H5pSjF6aHlkyIjSjiUSHSUR65vPvxa s+iKhC2pTxW5wV7DnWQog== Received: from pzk27 (pzk27.prod.google.com [10.243.19.155]) by kpbe14.cbf.corp.google.com with ESMTP id o386fETx023141 for ; Wed, 7 Apr 2010 23:41:15 -0700 Received: by pzk27 with SMTP id 27so1650245pzk.2 for ; Wed, 07 Apr 2010 23:41:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.14 with HTTP; Wed, 7 Apr 2010 23:40:54 -0700 (PDT) In-Reply-To: References: From: John Panzer Date: Wed, 7 Apr 2010 23:40:54 -0700 Received: by 10.140.255.10 with SMTP id c10mr8395298rvi.289.1270708874293; Wed, 07 Apr 2010 23:41:14 -0700 (PDT) Message-ID: To: Evan Gilbert Content-Type: multipart/alternative; boundary=000e0cd0ebbc10b45b0483b3f747 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on Web Callback & Client Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 06:41:24 -0000 --000e0cd0ebbc10b45b0483b3f747 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 7, 2010 at 10:46 PM, Evan Gilbert wrote: > > > > On Wed, Apr 7, 2010 at 9:29 AM, John Panzer wrote: > >> I'm assuming that tokens need not be bound to a specific user (typically >> they are, but imagine a secretary granting an app access to his boss's >> calendar and then leaving the company and therefore being removed from the >> calendar ACL, but the app still keeping access by virtue of the capability >> granted by the token). In this case, the proposed wording seems kind of >> problematic for a MUST. > > > Note that the "resource owner" in this case is the secretary, not his boss. > Resource owner is "An entity capable of granting access to a protected > resource." > > Since access tokens are bound to the resource owner ("A unique identifier > used by the client to make authenticated requests on behalf of the > resource owner."), I think in this case the system would have a clear way to > revoke access to the document. > Sorry, I was unclear. In the scenario I'm imagining, the boss has delegated calendar access to his secretary, who uses this delegated access to hook up an app to the calendar. The boss is very happy with this situation because now his Zombieville reminders show up on his calendar. If the token is tied to the secretary, and the secretary's account is shut down when the secretary leaves, then the boss no longer sees the Zombieville reminders pop up. He then complains that this sort of thing never happened with password-based access! I can imagine either scenario upon termination of the secretary -- you may want to revoke all the tokens, some of the tokens, or none of the tokens. > > Updating the wording on the proposal slightly to clarify (also changing > format to new parameter formatting) > > Before: > username > The resource owner's username. The authorization server MUST only send > back refresh tokens or access tokens for the user identified by username > > Current: > username > OPTIONAL. The resource owner's username. The authorization server MUST > only send back refresh tokens or access tokens *capable of making requests > on behalf of* the user identified by username > > >> >> On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert wrote: >> >>> >>> >>> On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav wrote: >>> >>>> What about an attacker changing the username similar to the way a >>>> callback can be changed? >>>> >>> >>> I don't think there is a danger here. >>> >>> We still use all of the safeguards in place from the rest of the flow - >>> adding this parameter never log you in when omitting the parameter would not >>> have. It will just create more error responses. >>> >>> >>>> >>>> EHL >>>> >>>> >>>> >>>> On 4/6/10 11:14 PM, "Evan Gilbert" wrote: >>>> >>>> >>>> >>>> On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav >>>> wrote: >>>> >>>> >>>> >>>> >>>> On 4/6/10 5:24 PM, "Evan Gilbert" wrote: >>>> >>>> > Proposal: >>>> > In 2.4.1 & 2.4.2, add the following OPTIONAL parameter >>>> > username >>>> > The resource owner's username. The authorization server MUST only >>>> send back >>>> > refresh tokens or access tokens for the user identified by username. >>>> >>>> What are the security implications? How can the client know that the >>>> token >>>> it got is really for that user? >>>> >>>> >>>> Think the client has to trust the auth server, in the same way as with >>>> the username + password profile. The auth server can always send back a >>>> scope for a different user. >>>> >>>> Worst case is that there is an identity mismatch between client and the >>>> identity implicit in the authorization token. This mismatch is already >>>> possible, and I don't think the username parameter makes the problem worse. >>>> >>>> >>>> EHL >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > --000e0cd0ebbc10b45b0483b3f747 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 7, 2010 at 10:46 PM, Evan Gi= lbert <uidude@goo= gle.com> wrote:



On Wed, Apr 7, 2010 at 9:29 AM, John Panzer <<= a href=3D"mailto:jpanzer@google.com" target=3D"_blank">jpanzer@google.com> wrote:
I'm assuming that tokens need not be bound to a specific user (typicall= y they are, but imagine a secretary granting an app access to his boss'= s calendar and then leaving the company and therefore being removed from th= e calendar ACL, but the app still keeping access by virtue of the capabilit= y granted by the token). =A0In this case, the proposed wording seems kind o= f problematic for a MUST.

Note that the "resource owner" in this case is the= secretary, not his boss. Resource owner is "An entity capable of gran= ting access to a protected resource."

Since access token= s are bound to the resource owner ("A unique identifier used by the cl= ient to make authenticated=A0requests on beh= alf of the resource owner."), I think in this case the system would ha= ve a clear way to revoke access to the document.=A0

Sorry, I was unclear. =A0In th= e scenario I'm imagining, the boss has delegated calendar access to his= secretary, who uses this delegated access to hook up an app to the calenda= r. =A0The boss is very happy with this situation because now his Zombievill= e reminders show up on his calendar. =A0If the token is tied to the secreta= ry, and the secretary's account is shut down when the secretary leaves,= then the boss no longer sees the Zombieville reminders pop up. =A0He then = complains that this sort of thing never happened with password-based access= !

I can imagine either scenario upon termination of the s= ecretary -- you may want to revoke all the tokens, some of the tokens, or n= one of the tokens.
=A0

Updating the wording on = the proposal slightly to clarify (also changing format to new parameter for= matting)

Before:
username
=A0=A0The resource owner's user= name. The authorization server MUST only send back refresh tokens or access= tokens for the user identified by username

Current:
username
=A0=A0OPTIONAL. The resource owner's use= rname. The authorization server MUST only send back refresh tokens or acces= s tokens capable of making requests on behalf of the user identified= by username
<= /span>=A0

On Wed, Apr 7, 201= 0 at 8:22 AM, Evan Gilbert <uidude@google.com> wrote:


On Wed, Apr 7, 2010 at 12:08 AM, Er= an Hammer-Lahav <eran@hueniverse.com> wrote:
What about an attacker changing the username similar to the way a cal= lback can be changed?

I don't think there is a danger here.

We still use all of= the safeguards in place from the rest of the flow - adding this parameter = never log you in when omitting the parameter would not have. It will just c= reate more error responses.
=A0

EHL



On 4/6/10 11:14 PM, "Evan Gilbert" <uidude@google.com> wrote:



On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:



On 4/6/10 5:24 PM, "Evan Gilbert" <uidude@google.com> wrote:

> Proposal:
> In 2.4.1 & 2.4.2, add the following OPTIONAL parameter
> username
> =A0=A0The resource owner's username. The authorization server MUST= only send back
> refresh tokens or access tokens for the user identified by username.
What are the security implications? How can the client know that the token<= br> it got is really for that user?

Think the client has to trust the auth server, in the same way as with the = username + password profile. The auth server can always send back a scope f= or a different user.

Worst case is that there is an identity mismatch between client and the ide= ntity implicit in the authorization token. This mismatch is already possibl= e, and I don't think the username parameter makes the problem worse.

EHL





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




--000e0cd0ebbc10b45b0483b3f747-- From eran@hueniverse.com Thu Apr 8 00:24:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7C028C0F2 for ; Thu, 8 Apr 2010 00:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0U6BfXjo6Fz for ; Thu, 8 Apr 2010 00:24:58 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id AC1613A6A3F for ; Thu, 8 Apr 2010 00:22:32 -0700 (PDT) Received: (qmail 8292 invoked from network); 8 Apr 2010 07:22:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Apr 2010 07:22:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 8 Apr 2010 00:22:28 -0700 From: Eran Hammer-Lahav To: Evan Gilbert , OAuth WG Date: Thu, 8 Apr 2010 00:22:25 -0700 Thread-Topic: [OAUTH-WG] Option to not prompt the user for authorization Thread-Index: AcrW0wN86AZUtHK+ReGfoDhfiyK3ngAGTkQ2 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Option to not prompt the user for authorization X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 07:24:59 -0000 On 4/7/10 9:20 PM, "Evan Gilbert" wrote: > Authorization servers in the OAuth Web Callback flow and the User Agent f= low > should have the option to redirect back with access/refresh tokens withou= t > prompting the user, if the client has already been granted access to the > protected resource. >=20 > This is already implied by some of the text (3.4.3.1 "After receiving (or > establishing via other means) an authorization=A0decision from the resour= ce > owner", but is not supported by the example flows. >=20 > Suggested changes >=20 > 3.4.1 Web Callback Flow >=20 > =A0=A0 (B) The authorization server authenticates the end user (via > the=A0user-agent) and MAY prompt the end user to grant or deny the=A0clie= nt's > access request. How about instead: (B) The authorization server authenticates the end user (via the user-agent= ) and establishes whether the end user grants or denies the client's access request. > =A0=A0 (C)=A0If authorization server determines the client has access to = protected > resource, the authorization server=A0redirects the user-agent back to the= client > to the callback URI=A0provided earlier. The authorization includes a > verification=A0code for the client to use to obtain an access token I don't think this is needed. The question is whether the user granted access. My proposed change removes the need to 'prompt' the user, which makes it possible to establish end user intent without asking again. But as some point you user must have granted access. =20 > 3.4.3 User Agent Flow >=20 > =A0=A0 (B) The authorization server authenticates the end user (via > the=A0user-agent) and MAY prompt the end user to grant or deny the=A0clie= nt's > access request. > =A0=A0 (C) If authorization server determines the client has access to pr= otected > resource, the authorization server=A0redirects the user-agent to the redi= rection > URI provided=A0earlier. The redirection URI includes the access token in = the=A0URI > fragment. Same. > Also, in cases where the authorization server doesn't prompt the user, we= may > want the ability for a client to ask for an immediate decision from the s= erver > instead of prompting the user using a parameter. Suggested changes: >=20 > 3.4.1.1 Web Callback Flow | Client Requests Authorization > 3.4.3.1 User Agent Flow | Client Requests Authorization >=20 > (new parameter) > immediate > =A0=A0OPTIONAL. The parameter value must be set to "true" or "false" (cas= e > sensitive). If set to "true", then the authorization flow MUST check > immediately if the client has access to protected resource and redirect b= ack > with a successful response or "user_denied" error without prompting the u= ser. How about: immediate: OPTIONAL. The parameter value must be set to 'true' or 'false' (case sensitive). If set to 'true', the authorization server MUST NOT prompt the end user to authenticate or approve access. Instead, the authorization server attempts to establish the end user's identity via other means (e.g. Browser cookies) and checks if the end user has previously approved an identical access request by the same client and if that access grant is still active. If the authorization server does not support an immediate check or if it is unable to establish the end user's identity or approval status, it MUST deny the request without prompting the end user. Defaults t= o 'no' is omitted. Also, is it safe to add to the user-agent flow since the client isn't the same entity as a web server, but another installation? I think it is but want to ask before I add it there. EHL From torsten@lodderstedt.net Thu Apr 8 01:55:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FCA3A6A15 for ; Thu, 8 Apr 2010 01:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qak-GPdurFK6 for ; Thu, 8 Apr 2010 01:55:03 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id EBF5F3A67CF for ; Thu, 8 Apr 2010 01:54:52 -0700 (PDT) Received: from [80.67.16.112] (helo=localhost) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NznVg-0001vU-Bm; Thu, 08 Apr 2010 10:54:48 +0200 Received: from proxy1.t-online.net (proxy1.t-online.net [195.243.113.249]) by webmail.df.eu (Horde Framework) with HTTP; Thu, 08 Apr 2010 10:54:48 +0200 Message-ID: <20100408105448.74772jb2mqega0o4@webmail.df.eu> Date: Thu, 08 Apr 2010 10:54:48 +0200 From: Torsten Lodderstedt To: eran@hueniverse.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.2) X-Originating-IP: 195.243.113.249 X-Df-Sender: 141509 Cc: oauth@ietf.org Subject: [OAUTH-WG] Comments on sections 5-7 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 08:55:07 -0000 Hi Eran, since you are re-working sections 5-7 now, I want to address some general issues I see there. - What is the benefit of including "URI Query Parameter" and "Form-Encoded Body Parameter" in the standard? I see OAuth as an HTTP authentication scheme similar to BASIC or SPNEGO. All of these schemes exclusively use Authorization headers for sending credentials from clients to servers. That way, authorization is kept orthogonal from the servers API. Advantages: + APIs can be combined with different authentication schemes + Libraries can be plugged in and easily add authorization data + no name clashes with API parameters + can be combined with any HTTP method It's ok with me if someone wants to send tokens as Query/Body Parameters. But then the token parameter becomes a part of the resource servers API. Why standardizing that? From a security standpoint, sending tokens as query parameter is problematic since their are many ways to leak them. Servers typically log target URLs in default configurations, GET request URLs are stored in browser caches and proxies. And what about Referer-Headers? When we adopted OAuth 1.0a, the fact that OAuth 1.0a supported three different ways of sending tokens caused a lot of confusion. What type is supported by what resource server? Do we need to support all of them or a sub set? e.t.c. So IMHO removing 5.1.2 and 5.1.3 would make the standard much simpler and easier to understand/implement/use. Moreover, it should save at least 2 pages. - I would like to suggest to change section ordering (5-7) in order to facilitate readability. From my point of view, the major contribution of the OAuth HTTP authentication scheme is the definition of the Authorization headers syntax (and semantics). Why not putting this in front? Further on, the natural counter part of the Authorization header is the WWW-Authenticate header since it is used to advertise important properties of the authentication scheme to clients. So I would suggest to describe it afterwards. Based on this considerations, I would suggest the following structure (just a sketch): 4 (was 7) Authorization Header description of both variants token only token + signature 5.2.1 Computing the signature security considerations e.g. implementations MUST support bearer tokens w/ HTTPS, resource servers and clients SHOULD use it 5 (was 6) WWW-Authenticate Header I'm willed to contribute a more elaborated proposal if you and the WG agree with the direction I proposed. What do you think? regards, Torsten. From greg@blinkbox.com Thu Apr 8 07:03:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7279A3A6A39 for ; Thu, 8 Apr 2010 07:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpVtQvvtUiEx for ; Thu, 8 Apr 2010 07:03:55 -0700 (PDT) Received: from blinkbox.com (mail.blinkbox.com [80.169.194.210]) by core3.amsl.com (Postfix) with ESMTP id 194463A67EF for ; Thu, 8 Apr 2010 07:03:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2010 15:03:35 +0100 Message-ID: <9D8B012531C07B45913FFB083D82BF53015937B6@rpc.blinkbox.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Error in example in section 3.4.1.1 of draft-hammer-oauth-10 thread-index: AcrWPb9ae0yI2aMURvyBSMlmv5iszwAAcN+uAAooRiA= References: <9D8B012531C07B45913FFB083D82BF530150BE98@rpc.blinkbox.com> From: "Greg Beech" To: "Eran Hammer-Lahav" , "OAuth WG" Subject: Re: [OAUTH-WG] Error in example in section 3.4.1.1 of draft-hammer-oauth-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:03:56 -0000 Apologies, I had not realised that this was intended to be a = form-encoded body, and thought it was a typo. However, according to RFC = 2616 the body of a GET request has no semantic meaning and should be = ignored by an origin server (summarised well in the following quotation = from Roy Fielding): "Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request. The requirements on parsing are separate from the requirements on method semantics." Source: http://tech.groups.yahoo.com/group/rest-discuss/message/9962 = As such, I would have thought that when computing the signature base = string the form body should similarly be ignored here. Is the OAuth = specification stating that we should consider the form body even when it = has no semantic meaning? From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: 07 April 2010 11:46 To: Greg Beech; OAuth WG Subject: Re: [OAUTH-WG] Error in example in section 3.4.1.1 of = draft-hammer-oauth-10 While odd, this is a perfectly legal GET request with a form-encoded = body. EHL On 4/7/10 3:33 AM, "Greg Beech" wrote: Hi I noticed that there is an error in the example for section 3.4.1.1 in the latest OAuth draft. The example of building a signature base string uses the following request as an example (note the extraneous query parameters at the bottom): GET /request?b5=3D%3D%253D&a3=3Da&c%40=3D&a2=3Dr%20b HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Authorization: OAuth realm=3D"Example", oauth_consumer_key=3D"9djdj82h48djs9d2", oauth_token=3D"kkk9d7dh3k39sjv7", oauth_signature_method=3D"HMAC-SHA1", oauth_timestamp=3D"137131201", oauth_nonce=3D"7d8f3e4a", oauth_signature=3D"djosJKDKJSD8743243%2Fjdk33klY%3D" c2&a3=3D2+q I believe that this should be as follows, which will cause the documented signature base string to be constructed: GET /request?b5=3D%3D%253D&a3=3Da&c%40=3D&a2=3Dr%20b&c2=3D&a3=3D2+q = HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Authorization: OAuth realm=3D"Example", oauth_consumer_key=3D"9djdj82h48djs9d2", oauth_token=3D"kkk9d7dh3k39sjv7", oauth_signature_method=3D"HMAC-SHA1", oauth_timestamp=3D"137131201", oauth_nonce=3D"7d8f3e4a", oauth_signature=3D"djosJKDKJSD8743243%2Fjdk33klY%3D" Apologies if this is a duplicate comment; I searched the archives but could not find any reference to this issue. -- Greg Blinkbox Entertainment Ltd - The best movies & TV online | Greg Beech | Senior Development Engineer Lead | +44 20 7092 8700 | +44 = 7970 480901 =20 Blinkbox Entertainment Ltd - The best movies & TV online | Greg Beech | Senior Development Engineer Lead | +44 20 7092 8700 | +44 = 7970 480901 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From gffletch@aol.com Thu Apr 8 07:09:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710D63A68C1 for ; Thu, 8 Apr 2010 07:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCwPFpCOxDPa for ; Thu, 8 Apr 2010 07:09:10 -0700 (PDT) Received: from imr-da06.mx.aol.com (imr-da06.mx.aol.com [205.188.169.203]) by core3.amsl.com (Postfix) with ESMTP id 463913A6837 for ; Thu, 8 Apr 2010 07:09:01 -0700 (PDT) Received: from mtaout-db05.r1000.mx.aol.com (mtaout-db05.r1000.mx.aol.com [172.29.51.197]) by imr-da06.mx.aol.com (8.14.1/8.14.1) with ESMTP id o38E8VMQ006465; Thu, 8 Apr 2010 10:08:32 -0400 Received: from palantir.local (unknown [10.172.3.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 5FFE0E003583; Thu, 8 Apr 2010 10:08:32 -0400 (EDT) Message-ID: <4BBDE35F.4000102@aol.com> Date: Thu, 08 Apr 2010 10:08:31 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: OAuth WG References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080805080609090703020904" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:485123904:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33c54bbde36049bf X-AOL-IP: 10.172.3.77 Cc: "Moore, Jonathan" Subject: Re: [OAUTH-WG] Limiting signed requests to use the Authorization request header X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:09:14 -0000 This is a multi-part message in MIME format. --------------080805080609090703020904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Another use case is where a rich client wants to bootstrap a web session with the same identity (rich client to web SSO). Assuming that the web session will be established via OAuth with signatures, there is no way to fire up the browser with a "signed URL" if the OAuth parameters and signature need to be in a header. As Jon mentions, the concept of allowing a service to create a signed URL and then pass it back to JS running in the browser, or invoking a browser directly is something that we leverage a lot across our rich clients and web applications. I realize that these sorts of use cases are trivial if establishment of the SSO session switches from a signed mechanism to the OAuth WRAP bearer token model. The one nice feature of the signed URL is that it is one time use where the bearer token can be replayed multiple times. Thanks, George Real world use case. Login into the latest AIM client. Click the mail icon/link. On 3/31/10 7:25 AM, Moore, Jonathan wrote: > What about a use case where the signature will be generated by one component but the request will be redeemed by another? > > For example, suppose there is a cross-domain JSONP call that requires authorization; in this case, I might have my client side code hit *my* origin server, obtain a signed URL, and then redeem it by hitting the JSONP resource. This has scaling advantages over having my origin proxy an OAuth request, and doesn't require me to have keys located on the client; I can keep them safely in my data centers. > > In this case, sending a "ready to redeem" signed request using the query parameter mechanism simplifies the client-side code. Furthermore, in this use case (cross-domain script inclusion), the client doesn't have the means to set the Authorization header (it can only include a